Memory-Safe Code Adoption Has Made Android Safer

The number of memory-related vulnerabilities in Android has dropped sharply over the past five years, thanks to Google’s use of a secure-by-design approach that emphasizes the use of memory-safe languages like Rust for most new code.

Memory safety issues like buffer overflows and use-after-free bugs now account for just 24% of all Android vulnerabilities, compared to 76% in 2019. Numbers so far this year suggest a total of 36 Android memory-related vulnerabilities for all of 2024, or roughly half the number as last year and a far cry from 223 flaws in 2019.

Secure-by Design Approach Pays Off

In a Sept. 25 blog post, researchers from Google’s Android and security teams credited the progress to Safe Coding, a secure-by-design approach at the company that prioritizes memory-safe languages like Rust for new code development. “Based on what we’ve learned, it’s become clear that we do not need to throw away or rewrite all our existing memory-unsafe code,” the researchers wrote. “Instead, Android is focusing on making interoperability safe and convenient as a primary capability in our memory safety journey.”

Memory safety vulnerabilities have traditionally accounted for, and continue to account for, more than 60% of all application software vulnerabilities. They have also been disproportionately severe when compared to other flaws. For instance, in 2022, memory-related bugs made up only 36% of all identified Android vulnerabilities but accounted for 86% of the most severe flaws in the operating system and 78% of confirmed exploited Android bugs.

Much of this has to do with how widely used programming languages such as C and C++ allow software developers to directly manipulate memory, leaving the door open for errors to creep in. In contrast, memory-safe languages like Rust, Go, and C# feature automatic memory management and built-in safety checks against common memory-related bugs. Numerous security stakeholders including the US Cybersecurity and Infrastructure Security Agency (CISA) and even the White House have raised concerns over heightened security exposure associated with using memory-unsafe languages and the substantial costs involved in addressing them. While the shift to memory-safe languages has been slowly gaining momentum, many expect it will take years and possibly decades to move existing code bases entirely to memory-safe code.

A Gradual Transition

Google’s approach to the problem has been to use memory-safe languages like Rust for new Android features while leaving existing code largely untouched except to make bug fixes. The result is that over the past few years there has been a gradual slowdown in new development activity involving memory-unsafe languages matched by an increase in memory-safe development activity, the two Google researchers said.

Google began the transition with support for Rust in Android 12 and has been gradually increasing use of the programming language within the Android Open Source Project. Android 13 marked the first time that most of the new code in the operating system was in a memory-safe language. At the time, Google emphasized that its goal was not to convert all C and C++ code to Rust, but instead to gradually transition to the new programming language over time.

In a blog post earlier this year, members of Google’s security engineering team noted that they saw “no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees.” But rather than walking away from it all at once, Google will continue to invest in tools to improve memory safety in C and C++ to support the company’s existing codebases written in these languages.

Significantly, Google found that memory-related bugs as a percentage of all Android vulnerabilities declined not just because of the company’s growing use of a memory-safe language like Rust but also because older vulnerabilities decayed with time. The researchers found that the number of vulnerabilities in a given amount of code — often referred to as vulnerability density — was lower in five-year-old Android code compared to brand new code.

“The problem is overwhelmingly with new code, necessitating a fundamental change in how we develop code,” the researchers said.