Google has been integrating code written in the Rust programming language into its Android operating system since 2019 and its efforts have paid off in the form of fewer vulnerabilities.
Memory safety bugs – like out of bounds read and write or use after free – account for more than 65 percent of vulnerabilities of high or critical severity bugs in Chrome and Android, and the figures are similar in software from other vendors. These flaws degrade security and increase the cost of software development when not caught early.
But after four years in which Android has been collecting bits of Rust, that figure has declined.
“From 2019 to 2022 the annual number of memory safety vulnerabilities dropped from 223 down to 85,” said Android security engineer Jeffrey Vander Stoep in a blog post.
Vander Stoep says the decline coincides with efforts to move away from memory unsafe programming languages, by which he means C/C++ – a language that does not guarantee memory safety but can support it.
Starting with Android 12 last year, Rust became an Android platform language. And now in Android 13, says Vander Stoep, the majority of new code added to the release was written in a memory safe language – Rust, Java, or Kotlin.
With less memory-unsafe code entering Android, memory safety flaws have gone from 76 percent of Android vulnerabilities in 2019 to 35 percent in 2022 – the first year for which memory safety bugs do not represent the majority of vulnerabilities.
Other vulnerabilities have remained steady over time, appearing at a rate of about 20 per month over the past four years. Because memory safety flaws accounted for most of the critical issues, the vulnerabilities that have surfaced have proven to be less severe.
Google is not the only large tech company to recognize the benefits of memory safe code. Meta has voiced its appreciation of Rust. Several months ago, Microsoft CTO Mark Russinovich declared that C/C++ should no longer be used to start new projects and that Rust should be deployed where a language without garbage collection is required.
At the time, Bjarne Stroustrup, creator of C++, challenged Russinovich’s guidance by pointing out that type and memory safety can be had in ISO standard C++, enforced by a static analysis. As Stroustrup sees it, helping C++ evolve makes more sense than deprecating the language and leaving unsafe code untended.
Google, says Vander Stoep, continues to invest in tools to write safer C/C++ code, pointing to the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on Android devices. And he says Google has increased its use of fuzzing. But while such measures have contributed to the decline in memory safety bugs, he argues that most of the vulnerability reduction should be attributed to the transition toward memory safe languages.
In Android 13, roughly 21 percent of new native code is written in Rust. This includes about 1.5 million lines of Rust code in the Android Open Source Project (AOSP), consisting of components like Keystore2, the new Ultra-wideband (UWB) stack, and DNS-over-HTTP3 that in prior years would have been written in C++.
And so far, Rust has delivered. “To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code,” said Vander Stoep, who wisely admitted that this probably won’t be the case forever.
“Rust’s combination of speed and memory safety makes it a great choice for a wide range of projects,” said Rebecca Rumbul, executive director and CEO of the Rust Foundation, in an email to The Register. “It’s no surprise to see Rust being increasingly integrated into existing projects and products, and Google’s recent blog discussing Rust in Android really highlights its security benefits.”
Rumbul added, “Those security benefits are also being recognized by policymakers around the world, with governments in Europe and North America recognizing Rust as a solution to some of the security issues experienced in the past.”
The US National Security Agency recently observed that while languages like C++ can provide a lot of flexibility, they rely on the programmer to provide the necessary memory reference checks.
“Software analysis tools can detect many instances of memory management issues and operating environment options can also provide some protection, but inherent protections offered by memory safe software languages can prevent or mitigate most memory management issues,” the agency said in guidance [PDF] issued last month. “NSA recommends using a memory safe language when possible.” ®