Enterprises should use memory-safe languages or risk being open to vulnerabilities, tech experts and consumer advocates have warned.
Consumer Reports, a product testing nonprofit, published a report this month on memory safety that supports the argument for enterprises to shift from languages such as C and C++ to memory-safe programming languages such as Rust.
Memory safety means programming languages prevent certain types of memory-related errors, such as buffer overflows, null pointer references and use-after-free errors, which can lead to crashes, data corruption and security vulnerabilities.
For example, with a buffer overflow attack, an attacker could, with crafty insertion of bad data, take control of a program and rewrite it on the fly to do something nefarious, said Andrew Cornwall, an analyst at Forrester Research.
"Memory safety has always been a persistent source of defects in the software industry," he said.
C/C++ programmers traditionally believed development could be memory-safe or fast, but not both, Cornwall said. Languages such as Java and Python run on virtual machines that manage memory for the programmer, but they introduce runtime overhead.
"Recently, though, we're starting to see some new techniques that make it easier to isolate unsafe code," Cornwall said. "Rust has demonstrated that you can have static memory safety, imposed by the compiler itself."
Memory safety momentum builds
Panelists at the Usenix Enigma 2023 conference this week, including representatives from Consumer Reports and the nonprofit Internet Security Research Group (ISRG), further discussed the topic of reducing memory safety vulnerabilities. The ISRG is perhaps best known for Let's Encrypt, a project that became the catalyst for widespread adoption of Transport Layer Security certificates.
In 2020, ISRG launched a project dedicated to improving memory safety. The idea of memory safety had also been simmering at Consumer Reports for some time, said Yael Grauer, product manager for Consumer Reports Security Planner, which provides advice on how to be safe online, including the recent memory safety report.
"We'd been talking about memory safety internally since at least May 2021," Grauer said.
The topic's recent jump into the public spotlight is the culmination of years of effort from various organizations and individuals, she said.
Josh AasCo-founder and executive director, Internet Security Research Group
For example, last month's Congress appropriations bill included a provision that required the national cyber director to investigate memory safety in the government. In the same month, Google released Android 13 -- the first Android release where a majority of new code was in a memory-safe language. In addition, the 6.1 LTS version of the Linux kernel, which includes initial support for Rust, became available for general use. Meanwhile, in November, the National Security Agency recommended developers make a strategic shift away from C and C++, Grauer said.
A major driver for the momentum is that memory safety vulnerabilities can open systems up to risk, which can lead to serious consequences such as financial loss and identify theft, said Josh Aas, co-founder and executive director at ISRG.
"It's a huge problem," he said. "When hospital systems or public services are shut down, and people have to wait to get care or services, whether it's through malware attacks or something like that, memory safety is often the reason."
Memory-safe language proponents favor Rust
Much of the tech industry's foundational software is written in either C or C++. Up until the development of Rust, there was no viable alternative to C/C++, Aas said.
"We're at a point now where we have at least one good option, Rust, where we can get safety without sacrificing performance," he said.
"There isn't another memory-safe language that's going to give the Linux kernel great performance and the modern features that are needed," Aas said.
The first step to memory safety is to write new modules and programs in memory-safe languages, Aas said. Developers should start with the most security-critical modules.
"If you have data about where your memory safety vulnerabilities have come up in the past, you can start by looking at past vulnerability data and looking at where those things happened," Aas said.
Developers without that type of data available can look at components within network boundaries, such as those that send or receive data on the network. That is where the most serious vulnerabilities tend to come in. But developers can also look at software that straddles or manages a privilege boundary with authentication, he said.
The bottom line is that C and C++ are not safe languages, so developers need to move away from them, Aas said.
"They're going to be around for a long time because there's no future in which we get rid of all that code anytime soon," he said. "But we need to start the process of taking it out."