Android’s Rusty new code shakes off huge number of memory-safe vulnerabilities
Google has dramatically reduced the number of serious memory safety vulnerabilities in Android by shifting to memory-safe languages.
In a recent security blog, Google offered an update on its effort to eliminate memory safety vulnerabilities from its Android smartphone operating system.
If you ever read our posts describing security vulnerabilities, you will see a lot of phrases like “buffer overflow”, “failure to release memory”, “use after free”, “memory corruption”, and “memory leak”. These are all memory management issues—an incredibly serious class of security issues that are as old as dirt. Memory flaws are important because they are usually more severe, more likely to be remotely reachable, more versatile, and more likely to be exploited than other kinds of vulnerability.
In theory, the best way to prevent memory management issues is to use a memory-safe language, which manages memory automatically instead of relying on a programmer to code things correctly.
Google has been putting that theory to the test with a secure-by-design approach that prioritizes transitioning to memory-safe languages like Rust.
The Google security team looked at the vulnerabilities reported in the Android security bulletin, which includes critical and high severity vulnerabilities reported through its vulnerability rewards program, and vulnerabilities reported internally. It noticed that the number of memory safety vulnerabilities has shown a year-on-year decline each year since 2019. In 2019 there were 223. In 2022 there were 85.
Now Google reports that the percentage of memory safety vulnerabilities in Android has dropped from 76% to 24% over six years. For comparison, when Google looks at the Chromium project, which is only just starting the transition to memory-safe code, it finds that 70% of the serious security bugs are memory safety problems.
Decline of the number of memory related vulnerabilities over the years
Surprisingly, this decline has happened despite a growth in the number of lines of memory unsafe code that have been added to Android.
Google explains that vulnerabilities decay exponentially, meaning that old code matures and gets safer with time, so the best bang for buck comes from focussing on making new code memory safe.
The vast majority of vulnerabilities reside in new or recently modified code
The shift to coding in memory safe languages is more than just a replacement of technology—it enhances the idea of coding with security in mind, and it comes with a bonus as modern memory-safe languages (especially Rust) extend these principles beyond memory safety to other bug classes.
In the end, it tends to be cheaper to create code without flaws than to engage in an arms race with attackers as both sides comb the codebase trying to be the first to find vulnerabilities. Safe Coding affordably reduces vulnerability density across the board, it seems.
Importantly, Google is also showing that you don’t need to throw away or rewrite your existing memory-unsafe code—you can get to a much safer place by simply switching how you write new code.
We don’t just report on vulnerabilities—we identify them, and prioritize action.
Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in check by using ThreatDown’s Vulnerability Assessment and Patch Management solutions.