The National Security Agency (NSA) is urging developers to shift to memory safe languages – such as C#, Go, Java, Ruby, Rust, and Swift – to protect their code from remote code execution or other hacker attacks.
Of the languages mentioned above, Java is the most widely used across enterprise and Android app development, while Swift is a top 10 language, thanks in part to iOS app development. And there’s growing interest in Rust as a replacement for C and C++ in systems programming.
“NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby, and Swift,” the NSA said.
The spy agency cites recent research from Google and Microsoft that 70% of their security issues, respectively in Chrome and Windows, were memory-related and many of them were the result of using C and C++, which are more prone to memory-based vulnerabilities.
Also: Cybersecurity, cloud and coding: Why these three skills will lead demand in 2023
“Malicious cyber actors can exploit these vulnerabilities for remote code execution or other adverse effects, which can often compromise a device and be the first step in large-scale network intrusions,” the NSA notes in the “Software Memory Safety” Cybersecurity Information Sheet.
“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.”
So, the agency recommends using a memory safe language where possible, whether its for application development or systems programming.
“NSA recommends using a memory safe language when possible,” it notes.
While most infosec professionals are familiar with this debate over memory safe languages, perhaps not all developers are. Though, perhaps they should be, given it’s a decades-old problem, as Java creator James Gosling recently pointed out in a discussion about how and why Java was created.
If anything, the NSA document offers developers a clear, plain-language explanation of the technical reasons behind moving towards memory safe languages. Probably the most discussed language in terms of memory safety has been Rust, which is the main candidate as a ‘replacement’ for C and C++.
The Linux kernel recently introduced Rust as the second language to C, following the Android Open Source Project. These projects won’t replace old C/C++ code, but will prefer Rust for new code. Also, Microsoft Azure CTO Mark Russinovich recently called on all developers to use Rust over C and C++ for all new projects.
“By exploiting these types of memory issues, malicious actors – who are not bound by normal expectations of software use – may find that they can enter unusual inputs into the program, causing memory to be accessed, written, allocated, or deallocated in unexpected ways,” the NSA explains.
But – as experts have noted in debates over Rust and C/C++ – the NSA warns that simply using a memory safe language doesn’t by default preclude introducing memory bugs to software. Additionally, languages often allow libraries that aren’t written in memory safe languages.
“Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks. As a result, classes or functions are available that are recognized as non-memory safe and allow the programmer to perform a potentially unsafe memory management task,” the NSA said.
“Some languages require anything memory unsafe to be explicitly annotated as such to make the programmer and any reviewers of the program aware that it is unsafe. Memory safe languages can also use libraries written in non-memory safe languages and thus can contain unsafe memory functionality. Although these ways of including memory unsafe mechanisms subvert the inherent memory safety, they help to localize where memory problems could exist, allowing for extra scrutiny on those sections of code.”
Also: Cybersecurity: These are the new things to worry about in 2023
The NSA notes that some memory safe languages can come at a performance cost, which requires developers to learn a new language. It also points out there are measures developers can take to harden non-memory safe languages. Google’s Chrome team, for example, is exploring multiple methods to harden C++, but these approaches also come with performance overheads. C++ will remain in Chrome’s codebase for the foreseeable future.
The NSA recommends static and dynamic application security testing to spot memory issues. It also recommends exploring memory hardening methods, such as Control Flow Guard (CFG), which will place restrictions on where code can be executed. Similarly, Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are recommended.
