C++ and memory safety

Question

At my tiny org, the core engine is C++ due to a compute heavy workload. I need to internally react to NSA's recommendation about replacing C++ with a memory safe language.

They're highlighting the fact that C++ (or C) allows the code to read from or write to any memory address (i.e. pointers). That can lead to bugs like read / write out of bounds, or read / write after delete (dangling pointers). These bugs can then be exploited in production by malicious actors.

I don't think my org can afford to rewrite the codebase in another language in near to medium term, and I am not even sure we need to. As long as we do the following in our codebase, can we claim memory safety? (for the purpose of this question, I want to ignore any other kinds of safety or good coding practices).

• No heap allocation ourselves. No new / delete
• No char* for string variables, only std::string
• Replace static arrays with std::array, dynamic arrays with std::vector
• No pointers. Pass objects by reference where needed

Anything else?

Edits based on comments received

6/14/24: The code is not running in a highly resource constrained environment like an embedded system. Nor is it super sensitive where failure could harm someone's health or well being

6/14/24: We use Visual Studio and GCC as our compilers. To the extent the compilers would catch something, I don't want to repeat it in our internal guidelines

6/17/24: Safety seems to mean different things to different people. In the context of this question (and NSA's paper), a bug introduced by lack of memory safety is harmful because it can be exploited by malicious actors. Think heart bleed or Morris worm where buffer overflow had a role to play. A program crashing is not the same thing as a program being tricked to do something it wasn't supposed to do (using heart bleed as an example, I would rather have it crash than leak credentials)

6/17/24: The fact that this question is about memory safety, doesn't mean that we don't care about other kinds of safety

6/17/24: Google's Safer Usage of C++ comes quite close to describing both the problems and potential solutions that I am grappling with.

Answer 1

Whether statements like "our C++ codebase is memory safe" are useful is a discussion for itself. Independent of that, your measures to make C++ memory safe are far from sufficient. Many out-of-bound accesses are hard to prevent by simple rules.

For a std container like a vector or a string v, v[i] may refer to pretty arbitrary memory if i is out of bounds. Such accesses cannot be avoided easily. Is the following code safe?

for (auto& x : v)
{
  foo();
  bar(x);
}

It is not, because foo may access a reference of v and resize it such that it moves in memory. Then, using x afterwards is not safe anymore.

You could route all memory accesses through custom containers where each operation includes a bounds check. Even then, you are not safe if you need to account for multithreading and race conditions. Adding locks everywhere may help with that, but it's probably not worth the cost. It may then be cheaper to switch languages. C++ has many strengths, but they come at a price.

You may want to ask yourself (and the stakeholders) whether 100% memory safety is actually necessary. There are more kinds of attacks that can achieve bad results, so focussing on memory safety is a little bit narrow-sighted.

If you want to stick with C++, I'd recommend to follow best practices and coding guidelines like, for example, the CppCoreGuidelines. Additionally, make use of sanitizers and static code analyzers and add a good test suite. Most importantly, educate your team.

Answer 2

Before you go in deep, look at what “memory safe” in other languages means. A[i] = 0 with out of range i can overwrite a random memory location. Or it can instantly crash your software. Or it can throw an exception that you can catch (and then how are you going to handle that?). The “badness” of what happens is different, but in either case the assignment should have never happened, and the real problem is the assignment.

Comments: Amon seems to be missing the point. Some code is unacceptable. And in a “memory safe” language most of it is just as unacceptable. Discussing which is worse is pointless when it is unacceptable either way.

Answer 3

changing the language to make execution "safer" is probably starting in the wrong place.

(Dumbo the elephant held a feather in his trunk and could fly. What if the Ringmaster got feathers for all the big elephants so they could fly too? Wouldn't work.)

the team should agree on a common understanding of what "safety" is for their environment and product, and make a plan to provide the safety. that plan could say that programs have to work differently, and programmers have to pay attention to certain failure modes, and maybe use an existing language differently, or use a new language. then the team can start evaluating how to implement the plan.

Answer 4

Memory safety in C++

You can easily write memory safe code in C++ if using some recommended practices such as:

• avoiding raw arrays and prefering vectors
• avoid raw pointers and prefer smart pointers
• if using const and const references whenever possible
• and a few more, like the enforcement of the rule of 3.

The NSA's prudent position is that nothing would prevent someone from using a rogue pointer, or use a reference to an object that lifetime has passed away (for example using it in some lambda, or threaded code). But good and simple coding standards, such as the C++ core guidelines, prevent most of issues here.

Safety is made by people and requires some discipline

My whole point here is that languages are only a part of the system safety. Of course, they can facilitate some practices or give visibility to insecure constructs. But ultimately, people are at the core of safety, and some discipline is required.

For example, there are several standards to strengthen further code written by large teams when developing mission critical systems in C++, such as:

• Google's safer usage of C++
• Lockheed's Martin's the JSF-AV Joint Strike Fighter - Air Vehicle C++ Coding Standards (from 2005, i.e. predates modern C++11) (probably used for the development of the F-35's software which largely relies on a C/C++ code base)
• Autosar's Guidelines for the use of the C++14 language in critical and safety-related systems very popular in the automotive industry (google for it)
• or Carnegie Mellon's SEI CERT C++ Coding Standard.

As a counter example, the nicest languages are not exempt of vulnerabilities in the language implementation or from supply-chain attacks via vulnerable popular components that hide insecure features:

• Carnegie Mellon's SEI blog: Recent Rust Vulnerabilities