Google just patched Chrome’s eighth zero-day gap of the year so far.
Zero-days are bugs for which there were zero days you could have proactively updated…
…because cybercriminals not only found the bug first, but also discovered 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 dots menu (⋮), choose Help out > About Chromeand check your version 107.0.5304.121 or later.
Exposing Zero Days
Twenty years ago, zero-day often became widely known very quickly, usually for one (or both) of two reasons:
- A self-propagating virus or worm has been released to exploit the bug. This tended not only to draw attention to the vulnerability and how it was being exploited, but also to ensure that self-contained, working copies of the malicious code were spread far and wide for researchers to analyze.
- A bug hunter not motivated by making money released sample code and bragged about it. Paradoxically, this may have simultaneously harmed security by giving a “free gift” to cybercriminals to use right away in attacks, and helped attract security researchers and vendors to quickly fix it or come up with a workaround.
Today, the zero-day game is quite different, as modern defenses tend to make software vulnerabilities harder to exploit.
Today’s defensive layers include: additional protections built into the operating systems themselves; more secure software development tools; more secure programming languages and coding styles; and more powerful cyber threat prevention tools.
For example, in the early 2000s – the era of super-fast spread of viruses such as Code red and SQL Slammer – almost any stack buffer overflow, and many if not most heap buffer overflows, can be turned from theoretical vulnerabilities into practical exploits in a short period of time.
In other words, finding exploits and “dropping” 0-days was sometimes almost as easy as finding the underlying bug.
And with many users who work with it Administrator While they always had privileges, whether at work or at home, attackers rarely had to find ways to chain exploits together to completely take over an infected computer.
But in the 2020s, workable remote code execution exploits – bugs (or chains of bugs) that an attacker can reliably use to implant malware into your computer, for example by tricking you into viewing a single page on a booby-trapped website – are generally much harder to find and therefore worth a lot more money in the cyberunderground.
Simply put, those who get their hands on zero-day exploits these days tend not to brag about them anymore.
They also tend not to use them in attacks that would reveal the “how and why” of the intrusion, or result in working samples of the exploit code becoming readily available for analysis and investigation.
As a result, zero-days today are often only noticed after a threat team has been called in to investigate an attack that has already succeeded, but where common intrusion methods (e.g., phishing passwords, missing patches, or forgotten servers) don’t seem to work. have been the cause.
Buffer overflow visible
In this case now officially designated CVE-2022-4135the beast was reported by Google’s own Threat Analysis Group, but was not proactively found, as Google admits it is “I am aware that it is an exploit […] exists in the wild.”
The vulnerability is given a High seriousness, and is simply described as: Heap buffer overflow in GPU.
Buffer overflows generally mean that code from one part of a program writes outside of the blocks of memory officially allocated to it, trapping data that is later trusted (and will therefore be implicitly trusted) by another part of the program.
As you can imagine, a lot can go wrong if a buffer overflow can be triggered in a devious way to avoid an immediate program crash.
For example, the overflow can be used to poison a filename that will use another part of the program, causing it to write data where it shouldn’t; or to change the destination of a network connection; or even to change the location in memory from which the program will next execute code.
Google doesn’t explicitly say how this bug can be (or has been) exploited, but it’s wise to assume that some sort of remote code execution, largely synonymous with “stealth malware implantation”, is possible, since the bug involves mismanagement of memory.
What must we do?
Chrome and Chromium will be 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 make sure you have version numbers equal to or more recent than that.
To check your Chrome version and force an update if you’re behind, visit the Three dots menu (⋮) and choose Help out > 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 reported this bug (and hasn’t had an update that explicitly all security fixes are listed as of 11/10/2022).
So we can’t tell you if Edge is affected, or if you should expect an update for this bug, but we recommend that you keep an eye on Microsoft updates official release notes in case that.
