Recently, Google engineers analyzed 912 security bugs that have been fixed in the Chrome Stables branch since 2015. It was also found that approximately 70 percent of all security vulnerabilities marked as “high” or “severe” were memory management and security issues. Half of this is the use-after-free vulnerability. This security issue is caused by the mismanagement of memory pointers (addresses), which opens the door for attackers to attack Chrome’s internal components.
This data coincides with Microsoft’s previous research: The Microsoft Security Response Center (MSRC) classified all reported Microsoft security vulnerabilities since 2004, and about 70 percent of all Microsoft’s annual patches are for memory security fixes.
The Microsoft Security Response Center has explained this because most of their products are written in C and C, two programming languages that fall under the category of “memory-unsafe.” A vulnerability in the developer code that manages memory execution can result in a series of memory security errors.
Google faces a similar situation. Memory management remains a major problem, with 125 of the 130 Chrome vulnerabilities rated Critical associated with memory corruption since March 2019 alone.
To do this, Google engineers must follow the “Rule of 2”. That is, whenever an engineer writes a new Chrome feature, its code must not break more than two conditions:
The code handles untrustworthy input
Code runs without sandbox
Code is written in an insecure programming language (C/C?
So far, Google has been experimenting with sandboxing in Chrome. They isolated dozens of processes into their own sandboxes, and recently introduced the Site Isolation feature, which puts resources from each site into their own sandbox processes. But Google engineers say they have achieved maximum revenue by using sandboxed Chrome components, given performance issues, and must now look for new ones.
As a result, Google plans to research and develop custom Libraries for Use with Chrome’s Code Libraries, which better protect against memory-related errors.
At the same time, Google is exploring the MiraclePtr project, which aims to transform “use-after-free bugs into non-secure crashes with acceptable performance, memory, binary size, and minimal stability impact.”