Chrome is releasing an urgent zero-day patch – update now! – Bare Security

Google released a bunch of security patches for Chrome and Chromium browser code earlier this week…

…only to receive a vulnerability report from researchers at cybersecurity firm Avast the same day.

Google’s response was to push another update ASAP: A single bug fix CVE-2022-3723, described with usual Google legalism: we can neither confirm nor deny:

Google is aware of reports that an exploit for CVE-2022-3723 exists in the wild.

(Apple also regularly uses a similar disengaged flavor of OMG-everyone-a-0-day-ago notification, using words to the effect that it “is aware of a report that [an] problem may have been actively exploited”.)

This Chrome update means you are now looking for a version number of 107.0.5304.87 or later.

Confusingly this is the version number to expect on Mac or Linux, while Windows users may get 107.0.5304.87 Where 107.0.5304.88and, no, we don’t know why there are two different numbers here.

For what it’s worth, the cause of this security flaw has been described as “type confusion in V8”which is jargon for “there was an exploitable bug in the JavaScript engine that could be triggered by untrusted code and untrusted data that seemingly innocently came from outside”.

Basically, that means it’s almost certain that just visiting and viewing a booby-trapped website – something that isn’t supposed to endanger you on its own – could be enough to launch malicious code and to plant malware on your device, without any pop-ups. or other download warnings.

This is called in cybercrime slang a installation in car.

“Aware of reports”

We assume, given that a cybersecurity company reported this vulnerability, and given the almost immediate release of a bug update, that the flaw was discovered during an active investigation of a intrusion into a customer’s computer or network.

After an unexpected or unusual break-in, where the obvious entry paths simply don’t show up in the logs, threat hunters typically turn to the grainy details of the detection and response logs available to them, trying to piece together the system. details about what happened.

Since browser remote code execution (RCE) exploits often involve executing untrusted code from an untrusted source in an unexpected way, and launched a new thread of execution that would not normally appear not in the newspapers…

…access to sufficiently detailed “threat response” forensic data can not only reveal how criminals got in, but also exactly where and how in the system they were able to bypass security protections that would normally be in place. square.

Simply put, working backwards in an environment where you can replay an attack over and over and watch as it unfolds will often reveal the location, if not the exact workings, of an exploitable vulnerability.

And, as you can imagine, safely removing a needle from a haystack is much, much easier if you have a map of all the sharp metal objects in the haystack to begin with.

In short, what we mean is that when Google says “it is aware of reports” of an attack being launched exploiting Chrome in real life, we’re willing to assume you can translate that to “the bug is real, and it really is exploitable, but because we haven’t actually investigated the real-life hacked system ourselves, we’re still on safe ground if we don’t directly say, ” Hey, everyone, it’s day zero.”

The good news about bug discoveries like this is that they probably happened that way because the attackers wanted to keep both the vulnerability and the tricks needed to exploit it secret, knowing that to brag about the technique or using it too widely would speed up its discovery and thus shorten its value in targeted attacks.

RCE exploits in today’s browsers can be extremely complex to discover and expensive to acquire, given the efforts of organizations such as Mozilla, Microsoft, Apple, and Google to harden their browsers against code execution tricks. unwanted.

In other words, Google’s quick update time and the fact that most users will receive the update quickly and automatically (or at least semi-automatically), means the rest of us can now not only catch up with the crooks, but come back ahead of them.

What to do?

Even though Chrome will likely update, we still recommend checking anyway.

As mentioned above, you are looking for 107.0.5304.87 (Mac and Linux), or one of 107.0.5304.87 and 107.0.5304.88 (The Windows).

Use After > To help > About Google Chrome > Update Google Chrome.

The open-source Chromium flavor of the browser, at least on Linux, is also currently at the release. 107.0.5304.87.

(If you’re using Chromium on Linux or any of the BSDs, you may need to check with your distro manufacturer for the latest version.)

We don’t know if the Android version of Chrome is affected, and if so, what version number to look for.

You can watch for upcoming Android update announcements on Google Chrome trims Blog.

We assume that Chrome-based browsers on iOS and iPadOS are unaffected, as all browsers in Apple’s App Store are forced to use Apple’s WebKit browser subsystem, which does not use Google’s V8 JavaScript engine.

Interestingly, at the time of writing [2022-10-29T14:00:00Z]Microsoft’s release notes for Edge described an update dated 2022-10-27 (two days after this bug was reported by researchers), but did not list CVE-2022-3723 as one of the security patches of this version, which was numbered 107.0.1418.24.

So we assume that looking for an Edge version higher than this will indicate that Microsoft has released an update against this hole.

You can keep tabs on Edge patches through Microsoft Edge security updates page.


Comments are closed.