The software industry is making headway against a group of pernicious vulnerabilities that are responsible for the vast majority of critical, remotely exploitable, and in-the-wild attacks, software-security experts said this week.
The class of vulnerabilities — so-called memory-safety issues — include buffer overflows and use-after-free errors and have accounted for the majority of application security issues disclosed by software companies. Now, the latest data show that the increasing use of memory-safe languages — such as Java, C#, and more recently, Rust — has resulted in a rapid decline of the entire class of vulnerabilities.
Last week, for example, Google revealed that the latest version of the Android operating system has more new code written in memory-safe programing languages — such as Java, Rust, and Kotlin — than memory-unsafe languages such as C and C++, resulting in a drop in memory-safety vulnerabilities from 223 to 85 over the past three years.
“We are continuing to focus on eliminating entire classes of vulnerabilities, focusing on the most severe first,” says Jeffrey Vander Stoep, a software engineer at Google. “As memory safety vulnerabilities become more scarce, we anticipate the research community to focus their vulnerability-findings efforts on other classes of vulnerabilities.”
Buffer Overflows and Wormable Flaws
The ease with which programmers can create flawed code has become a major problem for large software companies. Microsoft, for example, found that, up until 2018, memory-safety issues accounted for 70% of the vulnerabilities discovered in the company’s software. Overall, memory safety issues have accounted for 60% to 70% of all vulnerabilities across a wide variety of ecosystems, according to 2020 research by software resilience engineer Alex Gaynor.
And because the flaws can easily be exploited to attack applications, they are the root causes behind a significant number of compromises, says Chris Wysopal, chief technology officer of Veracode.
“Memory corruption issues are amongst the highest severity flaws as they often allow attackers to exploit with code execution which allows them to take complete control of the application,” he says. “In the worst case scenario this allows the creation of a worm exploit which can go on to attack other instances of the vulnerability.”
In its recent blog post on its shift to memory-safe languages for Android development, Google noted that while memory-safety vulnerabilities now only account for 36% of issues disclosed in Android, they account for 86% of the critical security vulnerabilities and 89% of remotely exploitable issues.
Making the Switch to Safe Languages
For that reason, Google and others have urged developers to adopt memory-safe languages.
In Google’s case, C and C++ now account for just less than half of all new code. In fact, Android 13, the latest version, is the first where the majority of code has been written in memory-safe languages, with Rust replacing C and C++ for many developers. Rust is an efficient programming language focused on creating secure code.
Even the National Security Agency is urging companies to adopt memory-safe programming languages.
Switching to a memory-safe language is not sufficient, however. While the languages do make it harder for programmers to write insecure code, every language has a different level of protection. For that reason, the NSA has also recommended that developers use a variety of application-security tools — from compiler options to static scanners to runtime analysis — to harden applications as much as possible.
“Software analysis tools can detect many instances of memory management issues and operating environment options can also provide some protection, but inherent protections offered by memory safe software languages can prevent or mitigate most memory management issues,” the NSA’s report stated.
In the end, while memory-safe programming languages are not a standalone solution to the problem of software vulnerabilities, they give guidance to developers who can then avoid some of the most severe programming errors, says Veracode’s Wysopal.
“It’s hard to generalize and say that there is a lower volume of vulnerabilities in memory safe languages since the way they are used is different,” he says. “But if you were using two different languages to accomplish the exact same task, and one was memory safe, you’d expect fewer vulnerabilities in that one and typically less critical vulnerabilities.”