According to the “Software Memory Safety” Cybersecurity Information Sheet, malicious cyber actors can exploit poor memory management issues to access sensitive data and perform illegal code execution, among others.
NSA’s cybersecurity technical director, Neal Ziring, stated that memory management issues have been exploited for decades and are still common today. “We have to consistently use memory-safe languages and other protections when developing software to eliminate these weaknesses from malicious cyber actors,” he added.
Tech giants Microsoft and Google attribute 70% of some of their product vulnerabilities to software memory safety issues.
Too much freedom and flexibility in memory management
The NSA blamed exploitable memory issues on the freedom and flexibility in some commonly-used programming languages.
“Commonly used languages, such as C and C++, provide a lot of freedom and flexibility in memory management while relying heavily on the programmer to perform the needed checks on memory references.”
If the programmer fails to perform proper checks, this flexibility could lead to exploitable memory-based vulnerabilities. Examples of exploitable memory issues include buffer overflows and memory allocation and deallocation mishaps. Other unintended consequences of dynamic memory management include incorrect program results, degradation of performance, program crashes, and race conditions.
Although developers could attempt to address memory issues using external tools, logical errors could cause the program to behave unexpectedly, for example, by accessing freed memory. Additionally, adept digital transgressors can break from the normal program execution flow to trigger memory issues to their advantage, for example, by providing specially crafted input.
Fuzzing, a method of discovering problematic inputs, has advanced by leaps and bounds, with special tools currently available in the market. This technique could allow a threat actor to access certain memory locations, allocate memory during program execution, or take over the whole system.
NSA’s list of memory-safe languages
NSA recommends memory-safe programming languages such as C#, Go, Java, Ruby, Rust, and Swift.
However, switching from one programming language to another is costly and lengthy and could take decades at best. Additionally, the volume of C/C++ code out in the wild is staggering.
“Shifting development languages can be a daunting challenge. There are still applications out there written in Cobol after all. Though in many cases, the programming languages the NSA is recommending come with other advantages, and the pool of skilled programmers is growing,” said Mike Parkin, Senior Technical Engineer at Vulcan Cyber.
Memory-safe languages that could replace C/C++, such as Go and Rust, either have steep learning curves or fewer users, although the numbers have recently increased. However, the NSA recognizes that a memory-safe language could bolster security through “code-hardening defenses” such as operating system configurations and compiler and tool options.
According to the NSA, compile and runtime protections offered by memory-safe languages could prevent most issues.
“With this guidance, the NSA is one of the many voices claiming it’s time to move away from C/C++ (and assembly, in some cases) to other languages that are more memory safe,” said Sammy Migues, Principal Scientist at Synopsys Software Integrity Group. “Various studies have suggested that memory-unsafe languages account for a disproportionately large amount of software issues.”
Nevertheless, memory-safe languages are not the silver bullet to memory management issues because programs occasionally need to unsafely access memory to complete specific tasks.
Some memory-safe languages, like C#, also allow dynamic memory allocation when the programmer needs such functionality. However, dynamic memory allocation is rare and only affects limited parts of the program, unlike when it is the default behavior in C/C++. Thus, adopting memory-safe languages is the most appropriate step to address memory-based vulnerabilities responsible for many severe bugs across industries.
“Therefore, the overarching software community across the private sector, academia, and the US Government have begun initiatives to drive the culture of software development towards utilizing memory-safe languages,” NSA wrote.
However, Migues warns that “refactoring the millions-perhaps even trillions-of lines of C/C++ code used in literally billions of deployed devices to a new language is not a reasonable request.”
John Bambenek, Principal Threat Hunter at Netenrich, suggested that the directive from the Feds creates a sense of urgency and originates from “knowledge they have and we don’t.”
“While the National Security Agency (NSA) has a well-earned reputation for secrecy and other things, they also have a reputation for making solid security recommendations when national interests are at stake. Given the recommendation here, it is sound, though it may be challenging to implement in practice,” Parkin concluded.