It’s just under two weeks since Google rushed out a Chrome patch for the then-current version 107 to seal off a bug that was already being used in real-life attacks.
The company said nothing more about that bug than to describe it as a “heap buffer overflow in GPU” [sic], and to report that it was already being used in real-world attacks.
Google left all of the following questions unanswered:
- How might the bug might be triggered? Was merely viewing a booby-trapped web page enough?
- Could it be abused for remote code execution? Could the crooks end up installing malware without any visible warning?
- Who was using it? Were they state-sponsored attackers, or some other sort of cybercriminals?
- What they were after? Were they into data stealing, ransomware attacks, unlawful surveillance, or all of those things?
To be clear, many, if not most, memory bugs never quite end up getting turned into remote code execution (RCE) attacks.
Altough a buffer overflow often makes it easy to crash a program, thus causing it to stop responding, it isn’t always easy to figure out how trigger the bug with sufficient precision to grab control over the app itself.
(Often, the misbehaviour provoked by the bug will be detected as some sort of access violation by the operating system, which will kill off the program before it can be tricked into going rogue.)
In this case, of course, the bug was already actively being exploited, which implied that an RCE exploit had indeed been found, and that the attackers knew how to do much worse than merely to crash your browser.
More Chrome updates
Shortly after the GPU heap overflow patch, a new Chrome version, numbered 108, came out with no fewer than 28 security fixes, including patches for numerous of memory mismanagement flaws, at least some of which we assume could ultimately have been wrangled into RCE exploits.
Fortunately, none of those 28 bugs were known to be “in the wild”, meaning that they seem to have been found and reported by responsible cybersecurity researchers before any cybercriminals or state-sponsored hacking teams figured them out.
Unfortunately, Google has already needed to publish a follow-up security update for its ninth zero-day of the year 2022, bringing Chrome to version 108.0.5359.94 for Mac and Linux, and to 108.0.5359.94 or 108.0.5359.95 for Windows.
Once again, the security report is ultra-terse, this time noting only that:
- CVE-2022-4262 is the official bug designation.
- Type confusion in V8 is the basis of the bug.
- An exploit already exists and is being abused in the wild.
For example, mixing up a 64-bit unsigned integer and a 64-bit floating point number will typically throw your calculation off horrendously, because the internal layouts of the two number formats are incompatible.
But treating, say, a 64-bit unsigned integer that can safely contain any numerical value you like, such as an encoded date and time, as a memory pointer that specifies a program subroutine to be called next…
… could lead to deliberate deviation of the code flow in the program.
You won’t just get incorrect results; you’ll end up with RCE: a local program under malicious remote control because it was tricked into running untrusted code that was sent in from outside.
What to do?
Even if you’ve checked your Chrome version in the past few days, we recommend checking again by opening Chrome’s Three-dot menu (⋮) and then choosing Help > About Chrome.
As mentioned above, you are looking for version 108.0.5359.94 for Mac and Linux, and for version 108.0.5359.94 or 108.0.5359.95 for Windows.
(By the time you read this, there may have been further updates, so consider the above version numbers to be the minimum you want.)
Microsoft has now confirmed that the latest Edge build, which is version 108.0.1462.42 at the time of updating this article [2022-12-05T21:42Z], includes a patch for this bug.
In Edge, you can force an update check from the Three-dot menu by choosing Help and feedback > About Microsoft Edge.