The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities.
The agency explained that memory issues in software make up a large portion of exploitable vulnerabilities. Due to this concern, the authority has advised developers to consider moving from programming languages with little or no memory protection, like C and C++, to a memory safe language.
Memory-safe languages provide various degrees of memory usage protections, and the agency recommended using code hardening defences, like tool analysis or operating system configurations, as well. By doing this, many memory vulnerabilities can be prevented, mitigated, or made harder for cyber actors to take advantage of.
The US security agency underlined that exploitable software vulnerabilities are still frequently based on memory issues. This includes overflowing a memory buffer or leveraging issues with how software allocates and deallocates memory.
Popular languages, like C or C++, provide a lot of freedom and flexibility when it comes to memory management, said the NSA. Here, the programmer must perform the checks on memory references and if they make a mistake, it can lead to exploitable memory-based vulnerabilities.
“While the use of added protections to non-memory safe languages and the use of memory safe languages do not provide absolute protection against exploitable memory issues, they do provide considerable protection,” stated the NSA. “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 utilising memory safe languages.”
The NSA did say software analysis tools are able to detect instances of memory management issues, while operating environment options can provide protection too. However, it underlined the protection offered by memory safe software languages can prevent or mitigate most memory management issues.
Despite the warning, however, transitioning to memory safe languages, for many businesses, is not practical. “There are trillions of lines of code being used today written in C/C++ making it impossible to consider rewriting it all into a memory safe language,” said professor John Goodacre, director of the UKRI’s Digital Security by Design (DSbD) challenge and professor of computer architectures at the University of Manchester.
“Even when new code uses such languages, it's inevitable that it will be relying on code written in an unsafe language through its use of libraries or an operating system. Further, many of the higher-level languages are sandboxes by their runtime making them unsuitable for many classes of applications.”
IBM FlashSystem 5000 and 5200 for mid-market enterprises
Manage rapid data growth within limited IT budgets
Goodacre explained that in DBsD, an initiative supported by the British government, a new approach known as CHERI has been applied to both Arm and Risc-V prototype chips. He said this makes the hardware itself memory safe and brings memory safety to existing software and offers resilience and security features for new code.
“The risk from memory unsafe code is significant with around 70% of ongoing reported vulnerabilities rooted in such issues,” said Goodacre. “Moving to CHERI enabled hardware will not only block exploitation of these memory safety vulnerabilities, but it also offers developers new capabilities that reduce the risk that bugs find their way into production, increasing developer productivity.”
