After two years of being beaten down with memory-safety warnings, the C++ community has published a proposal to help developers write less vulnerable code. The Safe C++ Extensions proposal addresses the vulnerable programming language's Achilles' heel, ensuring that code is free of memory safety bugs. "This is a revolutionary proposal that adds memory safety features to the C++ programming language," said the president and executive director of the C++ Alliance last week. "This collaboration marks a significant milestone in the C++ ecosystem, as the need for safe code has never been more pressing."
It has never been more pressing because, for the past two years, private and public sector organizations have been pushing programmers to write new applications and rewrite old ones in memory-safe languages such as C#, Go, Java, Python, and Swift, but particularly Rust. After all, it's a performant low-level systems language.[1]
Software engineer Alex Gaynor raised the issue in 2019, noting that most severe vulnerabilities in large codebases come from memory safety flaws such as buffer overflows and use-after-free. "The data bears out, over and over again, that when projects use memory unsafe languages like C and C++, they are burdened by an avalanche of resulting security vulnerabilities," he wrote.
Memory safety subsequently became a common subject of discussion in academic papers and at technical conferences. By September 2022, Microsoft Azure CTO Mark Russinovich called for deprecating C and C++ and adopting Rust. A few months later, the NSA took a similar position. By 2023, memory safety had become a mainstream topic covered by Consumer Reports.
Those involved with C++ became defensive. Two years ago, in response to Russinovich's call to dump C/C++, C++ creator Bjarne Stroustrup said, "We can now achieve guaranteed perfect type and memory safety in ISO C++." Yet that claim was met with some skepticism. The co-founder and executive director of the Internet Security Research Group (ISRG), which oversees a memory safety initiative called Prossimo, last year reported that while it's theoretically possible to write memory-safe C++, that's not happening in real-world scenarios because C++ was not designed from the ground up for memory safety.
The Safe C++ Extensions proposal addresses that criticism and responds to public sector demand for memory safety from the NSA and the other Five Eyes intelligence agencies, the US Cybersecurity and Infrastructure Agency (CISA), the White House, and the DARPA.
In August, Gaynor revisited the topic of memory safety by noting that while it makes sense to try to make C++ safer, he doubts the extent to which that's possible. "It is clear, I think, that there are substantial safety improvements possible for C++," he wrote. "In particular, entirely solving spatial safety appears to be within reach. Alas, I think it is equally clear that making C++ as safe as Swift or Go or Rust is not something we know how to do, nor does it appear likely that we’ll be able to find a simple solution."
Nonetheless, the Safe C++ Extensions proposal aims to have a go. Acknowledging the now shouts of calls to adopt memory-safe programming languages, developers like Sean Baxter, creator of the Circle compiler, and Christian Mazakas, from the C++ Alliance, argue that while Rust is the only popular systems-level programming language without garbage collection that provides rigorous memory safety, migrating C++ code to Rust poses problems. "Rust lacks function overloading, templates, inheritance, and exceptions," the proposal explains. "C++ lacks traits, relocation, and borrow checking. These discrepancies are responsible for an impedance mismatch when interfacing the two languages. Most code generators for inter-language bindings aren’t able to represent features of one language in terms of the features of another."
Though DARPA is trying to develop better automated C++ to Rust conversion tools, Baxter and Mazakas argue telling veteran C++ developers to learn Rust isn't an answer, a point that a C-focused Linux kernel maintainer made recently. "The foreignness of Rust for career C++ developers combined with the friction of interop tools makes hardening C++ applications by rewriting critical sections in Rust difficult," they contend. "Why is there no in-language solution to memory safety? Why not a Safe C++?"
Baxter continued that while generating provably correct programs has been a matter of interest among computer scientists for decades, the issue has been elevated to a national priority. "Recent government warnings about memory safety have made this a focus for the whole tech industry," he said. "I studied the theory and saw an opportunity, using new tooling, to help C++ engineers write more correct programs and eliminate the class of software defects most implicated in security vulnerabilities."
The Safe C++ project adds new technology to ensure memory safety, Baxter explained, and it isn't just a reiteration of best practices. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety," Baxter said, saying that rewriting a project in a different programming language is costly. Hence, the aim is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. "With Safe C++, existing code continues to work as always," he explained. "Stakeholders have more control for incrementally opting into safety."
The next step, Baxter said, involves greater participation from industry to help realize the Safe C++ project. "The foundations are in. We have fantastic borrow checking and initialization analysis which underpin the soundness guarantees," he said. "The next step is to comprehensively visit all of C++'s features and specify their memory-safe versions. It's a big effort, but given the importance of reducing C++ security vulnerabilities, it's worth making."
This article is shared at no charge and is for educational and informational purposes only.
Red Sky Alliance provides Cyber Threat Analysis and Intelligence Services for our clients. We provide valuable indicators of compromised information via a notification service (RedXray) or an analysis service (CTAC). For questions, comments, or assistance, please get in touch with the office directly at 1-844-492-7225 or feedback@redskyalliance.com
- Reporting: https://www.redskyalliance.org/
- Website: https://www.redskyalliance.com/
- LinkedIn: https://www.linkedin.com/company/64265941
Weekly Cyber Intelligence Briefings:
REDSHORTS - Weekly Cyber Intelligence Briefings
https://register.gotowebinar.com/register/5378972949933166424
[1] https://www.theregister.com/2024/09/16/safe_c_plusplus/?td=rt-3a
Comments