Google: After using Rust, we slashed Android memory safety vulnerabilities

December 2, 2022 TH Author

Google’s decision to use Rust for new code in Android in order to reduce memory-related flaws appears to be paying off. Memory safety vulnerabilities in Android have been more than halved — a milestone that coincides with Google’s switch from C and C++ to the memory-safe programming language, Rust.

This is the first year that memory safety vulnerabilities are not the biggest category of security flaws, and comes a year after Google made Rust the default for new code in the Android Open Source Project (AOSP).

Other memory-safe languages Google has used for Android include Java and Java-compatible Kotlin. C and C++ are still dominant languages in AOSP, but Android 13 is the first version where most of the new code is from memory-safe languages. After Google adopted it for AOSP in April 2021, Rust now accounts for about 21% of new code. The Linux kernel project this year adopted Rust as the new official second language to C.

Android version 10 from 2019 had 223 memory safety bugs, while Android 13 has 85 known memory safety issues.

Over that period, memory safety vulnerabilities have dropped from 76% down to 35% of Android’s total vulnerabilities, notes Android security software engineer Jeffrey Vander Stoep. With this drop in memory safety vulnerabilities, Google is also seeing a decline in critical and remotely exploitable flaws.

Vander Stoep notes that this change was not driven by “heroics” — just developers using the best tools for the job. The Android team plans to step up usage of Rust, although there are no plans to get rid of C and C++ for its systems programming.

“If I had to identify a single characteristic that makes this possible, I would say ‘humility’. There’s a willingness within all levels of the Android team to say ‘How can we do better?’ along with the fortitude to follow through and make changes, including systemic changes,” he noted in a tweet.

“Humility needs to go both ways though. Rust doesn’t solve all problems, and there are areas where C/C++ will continue to be the most practical option for development, at least for a while. That’s OK.

“We’ll work on reducing that over time while continuing to scale up our Rust usage and continuing to invest-in and deploy improvements to C/C++.”

Correlation doesn’t equate to causation, Vander Stoep notes, but the percentage of memory safety security bugs — which dominate high severity bugs — does closely match the languages used for new code.

Security tools like fuzzing have also made a big impact on memory safety bugs, says Google.

“We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor,” writes Vander Stoep.

He goes on to note that in Android 13 there are 1.5 million total lines of Rust code, representing about 21% of all new code. To date, Google has seen not a single memory safety vulnerability in Android’s Rust code.

“It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production,” Vander Stoep notes.

Google sees the move away from C/C++ as challenging, but is pressing ahead with the project for Android. However, it is not moving to Rust for Chrome.

For Android, though, Google is implementing userspace hardware abstraction layers (HALs) in Rust and adding support for Rust in Trusted Applications. It has also migrated virtual machine firmware in the Android Virtualization Framework to Rust. And with support for Rust in the Linux kernel version 6.1, Google is bringing memory-safety to the kernel, starting with kernel drivers.