The National Security Agency (NSA) is urging developers to move to memory-safe languages — such as C#, Go, Java, Ruby, Rust and Swift — to protect their code from remote code execution or other hacking attacks. Of the aforementioned languages, Java is the most widely used in enterprise and Android app development, while Swift is a top 10 language, thanks in part to iOS app development. And there is growing interest in Rust as an alternative to C and C++ in systems programming.
“The NSA recommends that companies consider moving to memory-safe languages, where possible, from programming languages that offer little or no inherent memory protection, such as C/C++. Some examples of memory-safe languages are C#, Go, Java, Ruby and Swift,” the NSA said.
The agency cited recent research by Google and Microsoft that 70 percent of their security issues in Chrome and Windows, respectively, were memory-related, many of which were the result of using C and C++, two languages more prone to memory-based vulnerabilities.
“Malicious cyber actors can exploit these vulnerabilities for remote code execution or other adverse effects, which can often compromise a device and become the first step in a large-scale network intrusion,” the NSA noted in its “Software Memory Security” cybersecurity information sheet. Commonly used languages, such as C and C++, offer a great deal of freedom and flexibility in memory management while relying heavily on programmers to perform the necessary checks on memory references.”
As a result, the agency recommends using memory-safe languages whenever possible, whether for application development or system programming.
While most information security professionals are familiar with the debate about memory-safe languages, perhaps not all developers are. Perhaps they should be familiar, however, because this is an issue that has existed for decades, as Java creator James Gosling recently pointed out in a discussion of how and why Java was created.
If anything, the NSA’s document provides developers with a clear, layman’s explanation of the technical reasons behind the shift to memory-safe languages. Probably the most discussed language in terms of memory safety is Rust, which is a leading candidate as a “replacement” for C and C++.
The Linux kernel has recently introduced Rust as a second language to C, following the Android open source project. In addition, Microsoft Azure CTO Mark Russinovich recently called on all developers to use Rust over C and C++ in all new projects.
“By exploiting these types of memory issues, malicious actors – who are not bound by the normal expectations of software usage – may find that they can enter unusual inputs into programs that cause memory to be accessed, written, allocated or deleted in unexpected ways,” the NSA explained.
But – as experts have pointed out in the debate over Rust and C/C++ – the NSA warns that simply using a memory-safe language does not preclude the introduction of memory errors into software by default. In addition, languages often allow the use of libraries that are not written in memory-safe languages.
“Even when using memory-safe languages, memory management is not entirely memory-safe. Most memory-safe languages recognize that software sometimes needs to perform unsafe memory management functions to accomplish certain tasks. As a result, there are classes or functions that are considered non-memory-safe and allow programmers to perform memory management tasks that may not be safe,” the NSA said.
“Some languages require that anything memory unsafe be explicitly annotated as memory unsafe so that the programmer and any reviewers of the program are aware that it is unsafe. Memory-safe languages can also use libraries written in non-memory-safe languages, and therefore can contain memory-unsafe features. Although these ways of including memory-unsafe mechanisms subvert inherent memory safety, they help locate where memory problems may exist and allow additional review of those portions of code.”
The NSA notes that the conversion to some memory-safe languages may come at a performance cost, which requires developers to learn a new language. It also notes that there are steps developers can take to harden non-memory-safe languages. For example, Google’s Chrome team is exploring a variety of ways to harden C++, but these methods also come with a performance overhead. C++ will remain in Chrome’s code base for the foreseeable future.
The NSA recommends static and dynamic application security testing to detect 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, the use of Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are recommended.
