NSA urges orgs to use memory-safe programming languages
C/C++ on the bench, as US snoop HQ puts its trust in Rust, C#, Go, Java, Ruby, Swift
The NSA has released guidance encouraging organizations to shift programming languages from the likes of C and C++ to memory-safe alternatives – namely C#, Rust, Go, Java, Ruby or Swift.
"NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as compiler options, tool options, and operating system configurations," advised the agency.
The org's main concern is that miscreants may exploit vulnerabilities in code that poorly manages memory, which occurs more frequently in the languages that give more options and flexibility to the programmer.
The NSA gives the examples of a threat actor finding their way into a system through a buffer overflow or by leveraging software memory allocation shortcomings.
Meanwhile, memory-safe languages use a combination of compile time and runtime checks to automatically block off vulnerabilities caused by programmers' mistakes. Not all mistakes, mind, but every little helps. Bugs involving unsafe use of memory pointers or races between concurrent threads can be caught by these languages, for instance.
"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," said [PDF] the NSA.
Well, obviously that is best avoided.
- Rust in peace: Memory bugs in C and C++ code cause security issues so Microsoft is considering alternatives once again
- Linux luminaries discuss efforts to bring Rust to the kernel
- In Rust We Trust: Microsoft Azure CTO shuns C and C++
- Hive ransomware gang rapidly evolves with complex encryption, Rust code
NSA cybersecurity technical director Neal Ziring said consistent use of memory safe language and other protections was necessary when developing software to eliminate such vulnerabilities.
However, the NSA did recognize that "memory safe" is a bit of a misnomer and the concept exists on a spectrum.
Being memory safe also comes with its own challenges. For instance, additional levels of inherent protection may slow down development at first, as memory-unsafe code will not be built by certain toolchains, though the pay off of fewer bugs and more maintainable code down the line is arguably worth it. Shifting from one language to another can be a right old pain in the ASCII, if even possible at times. Rust, while powerful, has a fairly steep learning curve, for example.
While the languages are ubiquitous, the NSA's assertion that C and C++ are particularly problematic is a popular opinion. Microsoft Azure CTO Mark Russinovich laid out his case in September that it's time to halt any new projects in the two time-tested languages.
The CTO did acknowledge that although he'll bias new tools towards Rust, there exists an "enormous amount of C/C++ that will be maintained and evolved for decades (or longer.)" Russinovich himself had added to his already 85,000 lines of Sysinternals C/C++ code just the night prior to his tweet.
"I think NSA is doing the right thing," CISO of cybersecurity firm Acronis, Kevin Reed, told The Register.
"Mitigations like address space layout randomization (ASLR) and stack guard are kind of a band-aid, not a full solution; moving to a memory-safe language is a much better one," added Reed, before echoing Russinovich's sentiments.
"I doubt we'll see immediate effects because the amount of C and C++ code written over the years is immense and even if we all start using Rust and Go tomorrow, it'll take decades before we clean up this mess," said Reed. ®