Google’s decision to use Rust to write new Android code to reduce memory-related flaws seems to be paying off. Memory security vulnerabilities in Android have been reduced by more than half – a milestone that coincides with Google’s move from C and C++ to the Rust programming language.
This is the first year that memory security vulnerabilities have not been the largest category of security flaws. And that finding comes a year after Google made Rust the default language for new Android Open Source Project (AOSP) code.
Other memory-safe languages used by Google for Android include Java and Kotlin, a Java-compatible language. C and C++ remain the dominant languages in AOSP, but Android 13 is the first release where most new code comes from memory-safe languages. After Google adopted it for AOSP in April 2021, Rust now accounts for around 21% of new code. This year, the Linux kernel project adopted Rust as the new second official language after C.
Memory security vulnerabilities reduced from 76% to 35% of total Android vulnerabilities
Android version 10, from 2019, had 223 memory-related security vulnerabilities, while Android 13 has 85 known memory security issues.
During that time, memory security vulnerabilities fell from 76 percent to 35 percent of total Android vulnerabilities, notes Jeffrey Vander Stoep, a software engineer specializing in Android security. With this decrease in memory security vulnerabilities, Google is also seeing a decrease in critical and remotely exploitable flaws.
The engineer notes that this change is not due to “heroic deeds”, but simply because the developers are using the best tools for their work. The Android team plans to ramp up the use of Rust, although there are no plans to get rid of C and C++ for programming their systems.
Rust and humility
“If I had to identify a single characteristic that makes this possible, I would say humility. There is a will at all levels of the Android team to say “How can we do better?”, and the fortitude to go all the way and make change, including systemic change. », he notes in a tweet.
“Humility has to go both ways though. Rust doesn’t solve all problems, and in some areas C/C++ will remain the most practical option for development, at least for a while. It’s not serious. »
“We will strive to reduce this aspect over time, while continuing to develop the use of Rust and to invest and deploy improvements for C/C++. »
Correlation is not synonymous with causation, points out Jeffrey Vander Stoep, but the percentage of security flaws related to memory security – which dominate high-severity vulnerabilities – correlates closely with the languages used for new code.
According to Google, security tools such as fuzzing have also had a big impact on memory security vulnerabilities.
Android 13: 1.5 million lines of Rust code, or 21% of new code
“We continue to invest in tools to improve the security of our C/C++. In recent releases, we introduced Scudo, HWASAN, GWP-ASAN, and KFENCE to production Android devices. We also increased our fuzzing coverage on our existing code base. The vulnerabilities discovered using these tools helped both prevent vulnerabilities in new code and vulnerabilities discovered in old code. These are important tools, and critically important to our C/C++ code. However, they alone do not explain the large change in vulnerabilities we observe, and other projects that have deployed these technologies have not seen a major change in the composition of their vulnerabilities. We believe that Android’s continued shift from memory-insecure to memory-safe languages is a significant factor,” writes Jeffrey Vander Stoep.
He goes on to say that in Android 13 there are 1.5 million lines of Rust code in total, which is about 21% of all new code. To date, Google has not found a single memory security vulnerability in Android’s Rust code.
“This demonstrates that Rust is fulfilling its purpose of preventing Android’s most common source of vulnerability. The historical vulnerability density is greater than 1/kLOC (1 vulnerability per 1,000 lines of code) in many C/C++ components of Android (eg: media, Bluetooth, NFC). Based on this historical vulnerability density, it’s likely that the use of Rust has already prevented hundreds of vulnerabilities from reaching production,” the engineer notes.
No Rust for Chrome
Google considers abandoning C/C++ a challenge, but is continuing the project for Android. On the other hand, it does not switch to Rust for Chrome.
For Android, however, Google is implementing hardware abstraction layers (HAL) in Rust and adding support for Rust in trusted apps. He also migrated firmware for virtual machines as part of Android’s virtualization to Rust. And with support for Rust in version 6.1 of the Linux kernel, Google is bringing memory security to the kernel, starting with kernel drivers.
To dig deeper into the growth of Rust usage