Google’s Transition to Rust Programming Reduces Android Memory Vulnerabilities by Over 50%
According to Google, the adoption of memory-safe languages like Rust as part of its secure-by-design philosophy has significantly decreased the proportion of memory vulnerabilities detected in Android, from 76% to 24% in a six-year timeframe.
The focus on Safe Coding for introducing new functionalities not only lowers the overall security risks of a codebase but also streamlines the transition to be more “scalable and cost-efficient.”
This shift results in a reduction in memory safety vulnerabilities as the pace of new memory-unsafe development slows down after a specific period, allowing memory-safe development to take precedence, as explained by Google’s Jeff Vander Stoep and Alex Rebert in a post shared with The Hacker News.
Interestingly, the count of memory safety vulnerabilities could drop even with an uptick in the volume of fresh memory-unsafe code.
The discrepancy is attributed to vulnerabilities decaying exponentially, with investigations indicating that many vulnerabilities are usually found in new or recently altered code.
“The main issue lies with newly written code, prompting a fundamental shift in our code development practices,” highlighted Vander Stoep and Rebert. “Code matures and becomes more secure over time, following an exponential trend, leading to diminishing returns on endeavors like rewrites as code ages.”
Google, which officially declared its intention to integrate the Rust language into Android back in April 2021, specified that it commenced prioritizing the shift to memory-safe languages for new development around 2019.
Consequently, the count of memory safety vulnerabilities unearthed in the system decreased from 223 in 2019 to under 50 in 2024.
A significant portion of the decrease in these flaws can be credited to advances in strategies to combat them, shifting from reactive patching to proactive mitigation and proactive identification of vulnerabilities using tools like Clang sanitizers.
Google also emphasized that memory safety tactics should evolve further to emphasize “high-assurance prevention” by integrating secure-by-design principles embedding security in the very core of the codebase.
“Instead of concentrating on the adopted interventions (mitigations, fuzzing) or relying on historical performance to predict future security, Safe Coding empowers us to make robust assertions about the code’s attributes and feasible outcomes based on those attributes,” added Vander Stoep and Rebert.
Furthermore, Google is dedicated to promoting compatibility between Rust, C++, and Kotlin instead of opting for code rewrites as a “pragmatic and incremental” means of adopting memory-safe languages and ultimately eradicating entire vulnerability categories.
“Implementing Safe Coding in new code introduces a paradigm shift, enabling us to leverage the natural decline of vulnerabilities to our advantage, even in extensive existing systems,” they elaborated.
“The concept is simple: once we halt the influx of new vulnerabilities, their count reduces exponentially, rendering all of our code more secure, enhancing security design effectiveness, and mitigating scalability issues linked with existing memory safety strategies so they can be targeted more efficiently.”
This development aligns with Google’s increased collaboration with Arm’s product security and graphics processing unit (GPU) engineering teams to identify numerous deficiencies and enhance the overall security of the GPU software/firmware stack throughout the Android ecosystem.
This effort includes identifying two memory flaws in Pixel’s customized driver code (CVE-2023-48409 and CVE-2023-48421) and another in Arm Valhall GPU firmware and 5th Gen GPU architecture firmware (CVE-2024-0153).
“Proactive testing is a prudent practice as it can preemptively identify and resolve new vulnerabilities before they are exploited,” mentioned Google and Arm in a statement.
About Author
