Google has just patched Chrome’s eighth zero-day hole of the year so far.
Zero-days are bugs for which there were zero days you could have updated proactively…
…because cybercriminals not only found the bug first, but also figured out how to exploit it for nefarious purposes before a patch was prepared and published.
So, the quick version of this article is: go to Chrome’s Three-dot menu (⋮), choose Help > About Chrome, and check that you have version 107.0.5304.121 or later.
Uncovering zero-days
Two decades ago, zero-days often became widely known very quickly, typically for one (or both) of two reasons:
- A self-spreading virus or worm was released to exploit the bug. This tended not only to draw attention to the security hole and how it was being abused, but also to ensure that self-contained, working copies of the malicious code were blasted far and wide for researchers to analyse.
- A bug-hunter not motivated by making money released sample code and bragged about it. Paradoxically, perhaps, this simultaneously harmed security by handing a “free gift” to cybercriminals to use in attacks right away, and helped security by attracting researchers and vendors to fix it, or come up with a workaround, quickly.
These days, the zero-day game is rather different, because contemporary defences tend to make software vulnerabilities harder to exploit.
Today’s defensive layers include: additional protections built into operating systems themselves; safer software development tools; more secure programming languages and coding styles; and more powerful cyberthreat prevention tools.
In the early 2000s, for instance – the era of super-fast-spreading viruses such as Code Red and SQL Slammer – almost any stack buffer overflow, and many if not most heap buffer overflows, could be turned from theoretical vulnerabilities into practicable exploits in quick order.
In other words, finding exploits and “dropping” 0-days was sometimes almost as simple as finding the underlying bug in the first place.
And with many users running with Administrator privileges all the time, both at work and at home, attackers rarely needed to find ways to chain exploits together to take over an infected computer completely.
But in the 2020s, workable remote code execution exploits – bugs (or chains of bugs) that an attacker can reliably use to implant malware on your computer merely by luring you to view a single page on a booby-trapped website, for example – are generally much harder to find, and worth a lot more money in the cyberunderground as a result.
Simply put, those who get hold of zero-day exploits these days tend not to brag about them any more.
They also tend not to use them in attacks that would make the “how and why” of the intrusion obvious, or that would lead to working samples of the exploit code becoming readily available for analysis and research.
As a result, zero-days often get noticed these days only after a threat response team is called into investigate an attack that’s already succeeded, but where common intrusion methods (e.g. phished passwords, missing patches, or forgotten servers) don’t seem to have been the cause.
Buffer overflow exposed
In this case, now officially designated CVE-2022-4135, the bug was reported by Google’s own Threat Analysis Group, but wasn’t found proactively, given that Google admits that it is “aware that an exploit […] exists in the wild.”
The vulnerability has been given a High severity, and is described simply as: Heap buffer overflow in GPU.
Buffer overflows generally mean that code from one part of a program writes outside the memory blocks officially allocated to it, and tramples on data that will later be relied upon (and will therefore implicitly be trusted) by some other part of the program.
As you can imagine, there’s a lot that can go wrong if a buffer overflow can be triggered in a devious way that avoids an immediate program crash.
The overflow could be used, for example, to poison a filename that some other part of the program is about to use, causing it to write data where it shouldn’t; or to alter the destination of a network connection; or even to change the location in memory from which the program will execute code next.
Google doesn’t explicitly say how this bug could be (or has been) exploited, but it’s wise to assume that some sort of remote code execution, which is largely synonymous with “surreptitious implantation of malware”, is possible, given that the bug involves mismanagment of memory.
What to do?
Chrome and Chromium get updated to 107.0.5304.121 on Mac and Linux, and to 107.0.5304.121 or 107.0.5304.122 on Windows (no, we don’t know why there are two different versions), so be sure to check that you have version numbers equal to or more recent than those.
To check your Chrome version, and force an update if you’re behind, go to the Three-dot menu (⋮) and choose Help > About Chrome.
Microsoft Edge, as you probably know, is based on the Chromium code (the open-source core of Chrome), but hasn’t had an official update since the day before Google’s threat researchers logged this bug (and hasn’t had an update that explicitly lists any security fixes since 2022-11-10).
So, we can’t tell you whether Edge is affected, or whether you should expect an update for this bug, but we recommend keeping an eye on Microsoft’s official release notes just in case.
