CISA looked at C/C++ projects and found a lot of C/C++ code. Wanna redo any of it in Rust?

June 28, 2024 TH Author

The US government’s Cybersecurity and Infrastructure Security Agency (CISA) has analyzed 172 critical open source projects and found that more than half contain code written in languages like C and C++ that are not naturally memory safe.

What’s more, projects written in memory-safe languages may still be exposed to memory vulnerabilities through unsafe dependencies. The agency’s finding is detailed in a report titled, “Exploring Memory Safety in Critical Open Source Projects.”

Issued this week by CISA, in conjunction with the FBI, the Australian Signals Directorate’s Australian Cyber Security Center, and the Canadian Cyber Security Center, the report backs a drive by Five Eyes nations to get public and private sector organizations to reduce the number of software vulnerabilities arising from memory safety bugs.

“Memory-unsafe languages require developers to properly manage memory use and allocation,” the report finds. “Mistakes, which inevitably occur, can result in memory-safety vulnerabilities such as buffer overflows and use after free. Successful exploitation of these types of vulnerabilities can allow adversaries to take control of software, systems, and data.”

Memory-safe languages, like C#, Go, Java, Python, Rust, and Swift, handle memory management for the developer, reducing the opportunity to make memory errors.

In December 2023, CISA, with the help of the NSA, FBI, and the cyber security authorities of Australia, Canada, the UK, and New Zealand published a paper entitled “The Case for Memory Safety Roadmaps.” CISA’s open source project report follows that roadmap and aligns with America’s 2023 National Cybersecurity Strategy.

Memory safety errors, such as buffer overflows, use of uninitialized memory, type confusion, and use-after-free flaws, have been a matter of concern in the technical community for years. They’re commonly the result of programming errors in C/C++ code and account for the majority of the vulnerabilities in large codebases.

The 2015 stable release of Rust, a language with strong memory-safety guarantees, gave tech firms a non-aligned systems language they could use to avoid the problems with memory-unsafe code. The competitive implications of adopting languages with strong corporate associations, like C# (Microsoft), Go (Google), Swift (Apple), or Java (Oracle) may have helped make Rust more appealing. But it took a few years for Rust to mature and catch on.

Microsoft has been contemplating the virtues of Rust since at least 2019. But the programming language really took off in 2021, with the formation of the Rust Foundation, backed by founding members AWS, Huawei, Google, Microsoft, and Mozilla.

The C++ community, in response to the fuss about memory-safe languages like Rust, is trying to allow developers to write safer code through C++ profiles, which provide safety guarantees at compile time. Not everyone agrees C++ is up to the challenge.

Whatever the case, Google and Microsoft have made a show of moving toward memory-safe languages, initially for new projects and lately for application rewrites. Google, for example, earlier this year said its Rust development teams are twice as productive as its C++ teams.

At the same time, developers working with the Prossimo project have been rewriting critical open source libraries in Rust to reduce the risk of a memory flaws in legacy code. Just this week, Let’s Encrypt said it has deployed ntpd-rs, Prossimo’s Rust rewrite of the Network Time Protocol (NTP) daemon. But, as the CISA report shows, there’s a lot of work left to do.

The CISA report looked at 172 case studies on a list of critical projects compiled by the Open Source Security Foundation. It found:

52 percent of the projects contain code written in a memory-unsafe language.
55 percent of the total lines of code (LoC) for all projects were written in a memory-unsafe language.
The largest projects are disproportionately written in memory-unsafe languages. Of the ten largest projects by total lines of code, each has a proportion of memory unsafe LoC above 26 percent. The median proportion using memory-unsafe languages across the ten projects is 62.5 percent and four of the ten project proportions exceed 94 percent.
Dependency analysis of three projects written in memory-safe languages demonstrated that each one depended on other components written in memory-unsafe languages.

The projects evaluated include: Chromium, Gecko, KVM, Linux, LLVM, GCC, JDK, Node, and many others.

The Linux kernel, among the largest projects, “predominantly use memory-unsafe languages,” the report says. “Some other large projects (Chromium and Gecko web browser frameworks) use memory-unsafe languages for roughly half of their code.”

Linux began incorporating Rust code as of December 2022.

And while CISA conceded in its report that even projects in memory-safe languages can be vulnerable to memory safety bugs, primarily through dependencies, it concluded by urging people to consider rewriting their critical non-safe code:

Gunnar Braun, technical manager at the Synopsys Software Integrity Group, told The Register that it’s important to raise awareness of memory safety as a means to make software more secure.

“Memory safety should be one of the key considerations when deciding on a programming language,” said Braun. “The report and its preceding ‘Case for Memory Safe Roadmaps’ bring this to C-level executives – where it belongs. Software security and safety are no longer a purely technical concern.”

Braun said that the report observes that many of these open source programs run in embedded systems with strict resource constraints. If it’s not possible to change programming languages, he said, then that makes it all the more important to employ static code analysis and fuzzing tools to mitigate memory-safety risks.

“Some memory-safe languages, such as Rust or Go, are already making their way into embedded systems, so I’m optimistic that C/C++ will be largely replaced one day – but not today, and not tomorrow,” he said. “Until we get there, static code analysis and fuzzing tools will be as important as they always were, if not more.” ®