The SafeLogic Blog

On February 26, 2024, the Office of the National Cyber Director (ONCD) issued a report titled “Back to the Building Blocks:  A Path Toward Secure and Measurable Software.”  In this report, ONCD argues that software vendors should adopt memory safe programming languages to eradicate and prevent whole classes of software security weaknesses related to insecure memory management.

As a long-time software security practitioner, I was really moved by this edict from the executive branch. First, I must admit that there’s just something cool about reading a report from the highest levels of our government that gets into the nitty gritty details of why programming securely in a language like C is hard and diving into the differences between temporal and spatial memory safety issues.   Second, ONCD is spot on in what they are saying on this topic. 

I originally got into the software security space over two decades ago. During that time, I’ve been involved in numerous consulting projects where we’ve performed code reviews on millions of lines of code written in languages that lack memory safety, like C and C++. These reviews were performed using various techniques, including tool-based (e.g., static analysis) and manual code reviews.

One thing held constant. Given a sufficiently large and complex code base written in a memory unsafe language, memory-related software security weaknesses would be present that could provide a skilled attacker a way to exploit the software. Interestingly, these issues can creep in even if developers have been trained adequately in software security, even if they use the best static analysis tools, etc. Getting memory management right in languages that give developers complete control of memory is fundamentally difficult.

Correspondingly, the ONCD report correctly stated that a high percentage of CVEs we hear about in the wild could have been prevented if memory safe languages were used. One way to think about it is not giving developers rope they can accidentally hang themselves with. In the past, choosing a memory safe language often involved a tradeoff between security and performance, as memory safe language can be slower. But nowadays, with the advent of performant memory safe languages like Rust, that tradeoff is far less relevant.

So, is it a no-brainer to develop in a memory safe language to eradicate whole classes of security bugs? For new software development, it can be a straightforward choice. Not in every situation, of course, but in many situations.   The problem is, what do we do with all the existing code bases written in languages like C and C++?   It is a well-known fact that much code lives for a very long time because rewriting it is just too difficult and expensive. What can be done is to look for opportunities to do so when change needs to happen for other reasons. For instance, if your polybutylene pipe has been leaking water under your yard and you need to fix it, you might as well replace it with a copper pipe to avoid future leaks.

In the world of cryptography, we now have a fantastic opportunity to start transitioning to implementations in memory safe programming languages because we already have to work on transitioning to post quantum cryptography (PQC).   Much of today’s cryptography is implemented in languages that are not memory safe, and that has caused its share of grief for the world. For instance, the ONCD report mentions the Heartbleed CVE from 2014, which could allow remote attackers to expose sensitive data, such as authentication credentials and secret keys.

The root cause of it, you guessed it, was incorrect memory handling in the TLS heartbeat extension. That is just one example of many. So, suppose we have to rip out much of our cryptography to replace it with different cryptography that will resist cryptanalysis on future quantum computers. In that case, we might as well replace that cryptography with PQC algorithm and protocol implementations written in memory safe languages.

Migration to PQC represents perhaps once in a 50 to 100-year opportunity to do three things. First, of course, it is an opportunity to replace quantum-vulnerable cryptographic infrastructure with post-quantum cryptography. Second, it is an opportunity to build in crypto agility so that future algorithm transitions (which we know will be needed) can happen in a streamlined way. Third, PQC migration represents a phenomenal opportunity to adopt memory safe implementations in both cryptographic primitives and the protocols that use them. If we need to replace all the piping, not only in our front yard but across our entire digital ecosystem, let us choose to go with pipes made from better material to help us prevent future leaks.