2

Firstly, a quote from a good article about the importance of memory safety by memorysafety.org:

How common are memory safety vulnerabilities? Extremely. A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues.

...

These vulnerabilities and exploits, and many others, are made possible because C and C++ are not memory safe. Organizations which write large amounts of C and C++ inevitably produce large numbers of vulnerabilities that can be directly attributed to a lack of memory safety. These vulnerabilities are exploited, to the peril of hospitals, human rights dissidents, and health policy experts. Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers.

I couldn't agree more and would urge every developer to switch to a more memory safe (by-default) programming language, like Rust whenever possible. Yes, you can (in some cases) make other programming languages more memorysafe as well, by implementing best practices, however considering a layered-security approach (defense-in-depth) it's better to use a programming language that is memorysafe by default.

I can imagine that for many developers switching a programming language, is a sensitive subject. Considering the time spend mastering it. Perhaps giving an opinion about this subject at all, as a penetration tester might lean towards being out-of-scope or perceived as unasked advice. However, for important or relevant code I am considering to report 'an informational note' in future penetration test reports something like the following:

The following code or software isn't written in a programming language that is memorysafe by default. Using the currently used programming language requires a strict, and consistent implementation of best practices to reduce potential memory issues that could result in vulnerabilities. Consider using a programming languages that is memory-safe by-design instead.

Can and should a penetration test report include an informational note about not having used a (by-design) memory-safe programming language?

Lastly, this issue in my opinion needs to be on the agenda of more developers. It's great that for example even the White House recently published about this in 'Fact Sheet: ONCD Report Calls for Adoption of Memory Safe Programming Languages and Addressing the Hard Research Problem of Software Measurability'.

2
  • 1
    "Should" comes down to the scope of the test and report... Pentest reports are not for the tester to promote their own agendas/hobby-horses. Is the language use part of the scope? Were you able to demonstrate a problem/vulnerability? If yes, then include this note. If no, add a short note in an appendix for "further consideration". The problem could be that the integrity of your process could be called into question. If I read a personal agenda in a pentest report, I question the entire tester's approach and I find it hard to take the recommendations seriously.
    – schroeder
    Mar 4 at 13:50
  • The term "memory-safe" is giving people a false sense of security. You can't say any language is immune to stack overflows.... buffer overflows, etc... There are ALWAYS bugs/vulnerabilities. Manual memory management is often much more efficient. It may require more care when coding, and careful testing, but it has its upsides. Mar 4 at 22:16

2 Answers 2

4

Broadly, yes, but with a lot of caveats.

  • If you found a memory safety vulnerability, it makes excellent sense to include as a long-term fix a recommendation to move to a memory-safe language, and to include that recommendation in the executive summary. However, it's important to make your recommendations actionable in the short term, and changing the entire programming language a product is written in is at minimum a massive long-term project and in most cases is completely non-viable; at best you can recommend what future products should use. As such, I wouldn't even make this the only long-term recommendation; that would be something like recommending tooling or practices to avoid memory safety issues in their current language.
  • If you haven't found any memory safety issues, I would not create an entire finding for this unless the project is still in the design phase. Once code has been written, any recommendation to change programming language is tantamount to "throw it out and start over", and that's never a recommendation you should make without a very strong reason. It is in fact possible to write memory-safe C/C++/etc., and if the developers are successfully doing so already, it will be seen as impractical at best, insulting at worst, to suggest throwing away that work and wasting that expertise.
  • Findings and recommendations always need to take into consideration the context of the review target. If this target depends on a library written in a memory-unsafe language, and there isn't a suitable memory-safe replacement library, you can maybe convince people to switch but you need to be very sure they can do so without breaking compatibility. If the project is a library, that's even more true; it's often much easier to make calls from a safe language into an unsafe one than vice versa, and the needs of the library's users will be the determining factor. Making a recommendation that is completely impractical to the needs of the project is as pointless as making one that is outside the resources of the company, and either way you'll just look like a fool.
  • Be very careful about recommending any specific tool/language. In addition to the risk of being seen as a zealot making recommendations from prejudice rather than reason, consulting is about finding the solution that fits the client's needs, not the solution that would have been adopted in an ideal world. For example, as of early 2024, Rust is fast, but it has a high learning curve, is relatively little-known, and tooling around it is pretty immature still. In many cases, it might make more sense to switch to a managed runtime language, such as C#, Java, Python, or JS; each has its tradeoffs, but lots of things don't need the execution speed of Rust and instead need developer speed, or really extensive and mature libraries + tools, or simply to be a language most of your developers already know. If you do recommend a specific language, be clear about why.
  • Be cautious about pitching memory-safe languages as the solution to all memory-safety problems. Quite a few nominally memory-safe languages - Rust very much included - can lose much or all of their memory safety when they interact with external code (such as libraries). Quite a few crates are simply Rust wrappers around C/C++ libraries, and the wrappers don't even always perform any additional checks before handing off the call data to potentially memory-unsafe code. Similarly, many safe-by-default languages include the ability to write "unsafe" code, either for compatibility with existing codebases or for performance reasons where the compiler can't guarantee correctness of the fastest implementation; obviously one should avoid such "unsafe" code whenever possible, but merely recommending "use a memory-safe language" isn't sufficient for that unless you use one that doesn't support unsafe behavior at all.
3

As long as it is relevant to the scope of your test (i.e, you're testing an application that's not written in a memory safe language) then I don't see a problem with including a note or observation about this - but it needs some thought and care.

I couldn't agree more and would urge every developer to switch to a more memory safe (by-default) programming language, like Rust whenever possible.

As soon as you point to a specific language like this, you risk being see as a zealot trying to push their own favourite language. Rather than trying to advocate for any specific solution, it would be better to speak in more general terms.

You also shouldn't assume that the audience of your report have ever heard of memory safe languages, or even really understand why it's a problem - so pointing to a reputable (in your sector) and impartial source would be a good idea.

You also need to have a good enough understanding of this area yourself to be able to deal with challenges from a client, especially "If it's so unsafe to use this language, why didn't you find any vulnerabilities in our application?"

I can imagine that for many developers switching a programming language, is a sensitive subject. Considering the time spend mastering it.

In many cases it's not about the developers being "sensitive", it's about the business not seeing a justification for this. Switching the language of an existing project is almost never going to happen, but even trying to implement a new project in a different language is hugely expensive, as it requires retraining staff, changing your tooling, rewriting any shared libraries or components, etc, etc. And as as a pentester, most of the time you'll be getting paid by the businesses, not the developers.

So if you're going to recommend that they make a large and expensive change like that, you need to be able to explain to them in business terms why it's beneficial to them. And if you've just done a test that's failed to find vulnerabilities in their non-memory safe code, that's going to be a much harder argument to make.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .