Recently we wrote about why the NSA wants you to shift to memory safe programming languages. The short version is: 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. And 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.
Hot on the heels of the NSA, Google has just published an article on its security blog that provides some numbers to support agency's point of view. Google reports that it's seeing a significant drop in memory safety vulnerabilities in the Android operating system as the use of memory safe programming languages increases.
The numbers
I’ve always been a stickler for statistics, but you have to consider the source, the population, and the boundaries for each category, before you know what they are telling you. And unless the publisher is trying to manipulate you into a conclusion by using pseudoscientific claims not based on the presented data, statistics allow you to demonstrate the correlation between cause and effect.
Effect
The Google security team looked at the vulnerabilities reported in the Android security bulletin, which includes critical/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.
Cause
This drop in memory safety vulnerabilities coincides with a shift in programming languages. With the introduction of memory-safe languages like Kotlin, Java, and Rust in the development of the Android operating system, the contributions to the software that ties everything together in the background coded in C and C++ have gone down considerably.
Other possible causes
So, we can see a clear correlation between writing in memory-safe languages and the number of memory related vulnerabilities that were reported. But correlation does not always mean there is an actual causality. There could be other factors at play.
Software bugs are found and fixed over time, so we can expect the number of bugs in mature code that is being maintained but not actively developed to go down over time.
To demonstrate this is not the reason for the correlation, the Google team looked at new low-level components that require a systems language which would previously have been implemented in C++, but were coded in Rust. The result was impressive:
To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
There are approximately 1.5 million lines of Rust code in the Android Open Source Project (AOSP) across new functionality. According to Google, historically the vulnerability density is greater than one vulnerability per thousand lines of code. If Rust had followed that example, it would have rendered hundreds, if not thousands of vulnerabilities.
Side effects
To doublecheck the causality, the Google team also looked at vulnerabilities that were not memory related. The total number of vulnerabilities has stayed somewhat steady over the past four years at around 20 per month, even though the number of memory safety vulnerabilities has gone down significantly.
Because of the difference in severity between memory-related bugs and others, the overall severity of the found vulnerabilities has gone down, along with the number of memory safety vulnerabilities. Memory safety vulnerabilities are usually much more valuable to an attacker because of the impact they can have. Exploiting a code execution vulnerability in a process grants access not just to a specific resource, but everything that that process has access to, including attack surface to other processes.
Some tasks require or work better with manual memory management, so memory-unsafe classes or functions exist that allow the programmer more freedom in exchange for the increased risk. In practice, this means that memory safe languages need an escape hatch. Rust for example, has the unsafe{} escape hatch which allows interacting with system resources and non-Rust code.
Where these “unsafe” escapes are used, Google pays extra attention to the code in order to rule out any situations that may lead to vulnerabilities.
Increasing the security around unsafe code often means adding more code, such as additional sandboxing, sanitizers, runtime mitigations, and hardware protections. These all negatively impact code size, memory, and performance.
To be continued
Migrating away from C/C++ is challenging, but the Android developers are making progress. The aim is to use Rust anywhere in the codebase where native code is required. And with support for Rust landing in Linux 6.1, Google says it expects to bring memory safety to the kernel, starting with kernel drivers.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.