Chrome: 70% of all security bugs are memory safety issues

May 23, 2020 TH Author

Image: Google

Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week.

Half of the 70% are use-after-free vulnerabilities, a type of security issue that arises from incorrect management of memory pointers (addresses), leaving doors open for attackers to attack Chrome’s inner components.

The percentage was compiled after Google engineers analyzed 912 security bugs fixed in the Chrome stable branch since 2015, bugs that had a “high” or “critical” severity rating.

The number is identical to stats shared by Microsoft. Speaking at a security conference in February 2019, Microsoft engineers said that for the past 12 years, around 70% of all security updates for Microsoft products addressed memory safety vulnerabilities.

The never-ending problem of memory management

Both companies are basically dealing with the same problem, namely that C and C++, the two predominant programming languages in their codebases, are “unsafe” languages.

They are old programming tools created decades ago when security exploitation and cyber-attacks were not a relevant threat model and far from the mind of most early software developers.

As a result, both C and C++ let programmers have full control over how they manage an app’s memory pointers (addresses) and don’t come with restrictions or warnings to prevent or alert developers when they’re making basic memory management errors.

These early coding errors result in memory management vulnerabilities being introduced in applications. This includes vulnerabilities like use-after-free, buffer overflow, race conditions, double free, wild pointers, and others.

These memory management vulnerabilities are the most sought-after bugs that attackers try to find and exploit, as they can grant them the ability to plant code inside a device’s memory and have it executed by the victim application (browser, server, OS, etc.).

In a ranking released at the start of the year, the MITRE Corporation, the organization that manages the US government’s vulnerability database, ranked buffer overflow as the most dangerous vulnerability, with two other memory management-related issues also ranked in the top 10 (out-of-bounds read on #5 and use-after-free on #7).

As software engineering has advanced in recent years, developers have been getting better at rooting out most security flaws and adding security protections in place.

But not for memory management vulnerabilities.

Google to look into addressing Chrome’s memory bugs

Google says that since March 2019, 125 of the 130 Chrome vulnerabilities with a “critical” severity rating were memory corruption-related issues, showing that despite advances in fixing other bug classes, memory management is still a problem.

The problem of memory management bugs has been such a big issue at Google that Chrome engineers now have to follow “The Rule of 2.”

According to this rule, whenever engineers write a new Chrome feature, their code must not break more than two of the following conditions:

The code handles untrustworthy inputs
The code runs with no sandbox
The code is written in an unsafe programming language (C/C++)

Image: Google

While software companies have tried before to fix C and C++’s memory management problems, Mozilla has been the one who made a breakthrough by sponsoring, promoting and heavily adopting the Rust programming language in Firefox.

Today, Rust is considered one of the safest programming languages, and an ideal replacement for C and C++, primarily due to Mozilla’s early efforts.

But Mozilla has not been the only organization that has had enough of dealing with bug-prone C and C++ code.

Microsoft is also heavily investing in exploring C and C++ alternatives. From its early Checked C project, the company is now experimenting with Rust, and is also building its own Rust-like “safe” programming language (part of the secretive Project Verona).

Speaking at the Build virtual conference this week, Microsoft said these two efforts have been successful, and the company re-dedicated itself to adopting a safe programming language in the future.

But this week, Google also announced similar plans as well. The company said it also plans to look into “tackling the memory unsafety problem” for Chrome, today’s most popular web browser, used by almost 70% of internet users.

Chrome has reached peak sandboxing

Until today, Google engineers have been ardent supporters of the sandbox approach in Chrome. They isolated tens of processes into their own sandbox, and have recently rolled out Site Isolation, a feature that puts each site’s resources into its own sandboxed process as well.

However, Google engineers say that their approach to sandboxing Chrome’s components has reached its maximum benefits when taking performance into account, and that the company must now look to new approaches.

Going forward, Google says it plans to look into developing custom C++ libraries to use with Chrome’s codebase, libraries that have better protections against memory-related bugs.

The browser maker is also exploring the MiraclePtr project, which aims to turn “exploitable use-after-free bugs into non-security crashes with acceptable performance, memory, binary size and minimal stability impact.”

And last, but not least, Google also said it plans to explore using “safe” languages, where possible. Candidates include Rust, Swift, JavaScript, Kotlin, and Java.