I won’t lie, the fact that Google continues to roll out security updates to the world’s most popular web browser, with an estimated 3.8 billion users, on a weekly basis is something we should all be happy about. I am less happy, however, that week-after-week memory vulnerabilities in the Chromium code top the patched list both in terms of criticality and volume. Having just dropped an update with 13 use-after-free memory flaws confirmed, following one with 110 such issues, the latest Chrome patch fixes only 15 vulnerabilities in all, but 10 of them are memory-related problems. Obviously, you should ensure that your browser is updated, which Chrome does automatically, but have you ever wondered what the difference between use-after-free, heap buffer overflow and uninitialized use vulnerabilities is? I’m here to help explain what they are and why they are all so commonplace.
Google Chrome 150.0.7871.124/.125 Security Patch
Google has quickly confirmed the reasons for the July 14 Chrome update, which is unusual as it tends to be a day or two before the security issues are confirmed. What isn’t unusual, however, is that two-thirds of the 15 vulnerabilities disclosed are of the memory variety. The 150.0.7871.124/.125 update, available now across Windows, Mac, Linux and Android platforms, with iOS escaping the vulnerabilities as usual, “will roll out over the coming days/weeks,” according to Google technical program manager Daniel Yip.
Google has been less forthcoming as to the technical details of the vulnerabilities that are being patched in this update, as Yip said that such access is restricted “until a majority of users are updated with a fix.” The good news is that it is quite likely that the fix has already arrived; if you are asked to relaunch your browser, then it has. If not, you can use the three-dot Chrome menu to manually start the update search, download and installation process.
Google Chrome Memory Vulnerabilities Explained
The list of security vulnerabilities addressed by the most recent Google Chrome update is available here. In the meantime, however, let’s take a closer look at the vulnerabilities related to use-after-free, heap buffer overflow and uninitialized memory usage.
I have previously explained how the Open Worldwide Application Security Project defines a use-after-free condition as something that happens when a program references heap-allocated memory after it has already been freed or deleted, which can result in data corruption and even arbitrary code execution. I recommend reading that explanation rather than covering old ground again here.
Let’s look at the differences between a use-after-free and heap buffer overflow and uninitialized use vulnerabilities. All three have one thing in common, and that’s that they are all critical memory security issues. The differences are all about location, location, location. While use-after-free issues occur when a program, Chrome in this case, accesses memory after it has been discarded, uninitialized use is the opposite: a program accesses memory before data has been written to it. As the name implies, heap buffer overflows occur when a program writes more data into memory than the allocated, fixed space can hold.
An uninitialized use vulnerability, if exploited, can lead to remote code execution, privilege escalation, information leaks and crashes. A heap buffer overflow, on the other hand, can allow a program, such as the Google Chrome browser, to read and/or write data controlled by an attacker, with all that implies. None of which, of course, is good. You know what to do: ensure that the update is downloaded and activated as soon as possible.
