Memory safety is the new black, fashionable and fit for any occasion

Calls to avoid C/C++ and embrace Rust grow louder

Memory safety, a longstanding concern among serious software developers, has finally met with mainstream stardom.

Consumer Reports, an 87-year-old nonprofit focused on product testing, this week published a report on memory safety. The publication acknowledged its unexpected coverage of the topic by explaining how it came to explore this highly technical concern after internal conversations about the limitations of its consumer-focused guide to online security.

The topic came up on Wednesday at the USENIX Enigma 2023 conference, where panelists Yael Grauer (deputy content editor, Consumer Reports Digital Lab), Amira Dhalla (associate director of mobilizations, community engagement, and operations at Consumer Reports), Alex Gaynor (software security engineer and founder of Fish in a Barrel), and Josh Aas (co-founder and executive director of the non-profit Internet Security Research Group) chatted about what can be done to reduce memory safety vulnerabilities.

Memory errors occur when computer code tries to access an area of memory that's undefined, meaning it hasn't been specifically allocated or set aside as part of the heap, stack, or declared data.

Memory safety is a complex topic, explored in research papers [PDF] and debated among the technically inclined. But it has the potential to affect anyone who deals with digital technology through bugs in the software or firmware running on electronic devices. It's estimated that at least 65 percent of security vulnerabilities are the result of memory errors.

Memory safety is primarily an issue in programming languages with manual memory management, like C/C++. Improperly managed memory can lead to out of bounds reads and writes and use after free errors. When flaws of this sort can be exploited, attackers may be able to take control of affected devices or steal data. It's enough of a problem to concern the US National Security Agency, which published a paper [PDF] on memory safety last November.

More modern programming languages that incorporate garbage collection to manage memory – like Java, Python, JavaScript, and Go, among others – help programmers avoid memory-related flaws.

Then there's Rust, a relatively recent programming language, which relies on the concept of ownership to make memory safety guarantees while avoiding the performance cost of automated garbage collection.

The possibility of writing code that's both memory safe and fast has made Rust something of a cause célèbre in certain circles. Last September, Microsoft Azure CTO Mark Russinovich went so far as to suggest that new software projects that might have been started in C/C++ use Rust instead.

Endorsing Russinovich's mandate, security firm Chainguard on Wednesday said Wolfi, a memory safe Linux "undistro" – designed for producing secure container images – has incorporated the memory safe Rustls TLS library and HTTP via the Rust-based Hyper library in the curl network request tool.

The Internet Security Research Group (ISRG), best known for developing Let's Encrypt, helped bring memory safe TLS and HTTP to Wolfi through a project called Prossimo, which is focused on rewriting critical open source code (e.g. NTP, DNS, TLS) to make it memory safe.

Josh Aas from ISRG told The Register in a phone interview that he believes the conversation around memory safety follows from a confluence of events.

"I think there's more focus on security than ever and more understanding that memory safety is one of the biggest issues there is," he said. "There's also the recent maturing of tools that help us to address memory safety – the tools we have available to us today are much better than tools we had five years ago and certainly 10 or 20 years ago.

"When it comes to Consumer Reports [exploring the topic]… memory safety may be a somewhat esoteric aspect of software engineering, but the problems caused by a lack of memory safety are so serious that it is a real consumer-level issue."

Aas made it clear that he doesn't believe Rust alone is the answer to memory safety.

"The reason that you hear Rust a lot in this conversation is because Rust gives you memory safety with performance that is comparable to, or better than C," he said. "But if you're not highly performance sensitive in the ways that Rust addresses, then you have lots of choices."

Asked about C++ creator Bjarne Stroustrup's assertion that ISO standard C++ can be memory safe when rules are enforced with static analysis, Aas expressed skepticism.

"In a very theoretical sense that ignores the practicalities of the real world, that might be true," he said. "It might very theoretically be practically possible to write memory safe C++. But it's just not how things work in our world. There are just better ways to do that. C++ was not designed from the ground up to offer memory safety."

In an ISRG blog post planned for Thursday that was previewed by The Register, Aas offered some advice to software developers and open source maintainers who may be thinking about the transition to memory safe code.

First, he advises that developers stop creating more unsafe code by writing new projects in memory unsafe languages – which is what Microsoft's Russinovich said.

Second, he says, not everything needs to be rewritten at once. Focus first on security-critical modules.

Third, he says, open source maintainers don't necessarily need to learn Rust to help with the memory safety transition because many Rust-based modules come with C APIs.

Finally, he argues that the open source community should understand that the current status quo – an endless parade of memory errors – does not have to continue.

"Three years ago, the conversation was about should we do this," said Aas. "And now I think we're past the 'should' and we're on the 'how'." ®