Google experts estimated that approximately 70% of the security vulnerabilities in the Chrome codebase are related to memory management. Now the company is trying to figure out best solution to this problem.
In total, Google engineers studied 912 errors (“high” or “critical” severity) that were fixed in the stable Chrome branch since 2015.As it turned out, more than 70% are use-after-free vulnerabilities that arise due to incorrect management of memory pointers, which ultimately opens up the internal components of Chrome for attacks”, — said Google’s researchers.
Interestingly, the conclusions of Google experts match with the Microsoft statistics, which last year came to a similar conclusion: over the past 12 years, 70% of patches for the company’s products were released for memory security problems.
In fact, both companies suffer from the same thing: the use of the C and C ++ languages, which are considered “unsafe.” The fact is that these are very old tools created decades ago, at good old times when cyberattacks and exploitation of vulnerabilities did not pose such a threat as now, and most software developers simply did not think about such nuances.
So, dealing with C and C++, developers have full control over the management of memory pointers in the application. There are no restrictions or warnings to warn developers if they make basic mistakes in memory management issues. As a result, many vulnerabilities arise in applications related to buffer overflows, use-after-free, race conditions, double free, and so on.
Such vulnerabilities are very popular among attackers, because such bugs can be used to inject code into the device’s memory and then run this code in the target application (browser, server, OS, and so on).
Between March 2019 and May 2020, in Chrome were fixed 130 critical vulnerabilities. Among them 125 were related to the violation of the integrity of information in memory. That is, despite the achievements of developers in the field of error correction of other classes, memory management is still a problem”, – write Google engineers.
All this has become such a big problem for Google that Chrome engineers are now required to follow the Rule of Two.
According to this rule, when Chrome developers write a new function, their code can violate no more than two of the following conditions:
- the code processes untrusted input;
- the code works without a sandbox;
- the code is written in an unsafe programming language (C/C++).
Until recently, Google engineers were main proponents of using the sandbox in Chrome. So, they isolated dozens of processes in their own software environment and deployed Site Isolation (puts the resources of each site in their own isolated processes in the sandbox). However, now the company is forced to look for other approaches, noting that the use of sandboxes has now reached its maximum with regard to performance.
In the future, Google plans to develop custom C++ libraries with better protection against memory errors. These libraries will be used with the Chrome codebase. The company’s engineers are also exploring the possibility of using the MiraclePtr project, and its goal is to turn use-after-free vulnerabilities into non-security-related crashes that will have a minimal impact on the performance, stability, memory and size of the binaries.
In addition, Google says that it intends to explore the use of more “secure” programming languages wherever possible. These are Rust, Swift, JavaScript, Kotlin, and Java.
Recall that only recently the browser turned out to be vulnerable to a critical error in crypt32.dll, but quickly received a patch.
