In the past few days, both Apple and Adobe have published software updates to close off zero-day security holes that were already being exploited by attackers.
Remember that a zero-day exploit is a security bypass (typically, one that allows Bad Guys to break in and run or implant software of their own choosing) that was discovered and abused by the attackers before the Good Guys found and fixed it.
In other words, no matter how quickly you update against a zero-day once the patch is announced, you know that someone – and you have to hope that it wasn’t you! – has already been attacked and pwned, even if they’re accustomed to patching promptly themselves.
Loosely put, the zero part of the jargon reminds you that there were zero days during which you could have been patched proactively, no matter how hard you tried, because the attackers got there first.
Annoyingly, but perhaps understandingly, both Apple and Adobe made only the briefest of admissions about the zero-days they fixed.
Apple said simply that it was “aware of a report that [CVE-2022-22620] may have been actively exploited”:
Abobe was slighly more forthcoming, admitting that it was “aware that CVE-2022-24086 has been exploited in the wild in very limited attacks”:
No hints about how or where the attacks were carried out, what the attackers were after, what the attackers made off with, what indicators of compromise (IoC) you could look for in your own logs, how to evalualate your risk, or whether there are any workarounds or mitigations you could apply until you’re sure everything’s been patched.
Now it’s Google’s turn to wave its hand at a just-patched zero-day bug: the company has pushed out the latest Chrome update, using an underwhelmingly Apple-esque remark that it is “aware of reports that an exploit for CVE-2022-0609 exists in the wild”.
Use-after-free bugs galore
Intriguingly, CVE-2022-0609 was only one of five use-after-free coding bugs fixed in this update.
A use-after-free bug happens when one part of a program requests a block of memory to be reserved for its own exclusive access, uses that memory for a while, then relinquishes its claim on that memory block…
…only to carry on accessing that memory anyway, even after it’s been reallocated to some other part of the program, or perhaps even to another program entirely.
Imagine that you’re in the middle of a PowerPoint presentation that you’ve checked carefully and rehearsed plentifully, but just before you click through from slide 4 to slide 5, someone who thinks they’re updating slide 5 of their presentation manages to write their new data into your presentation instead. You’d end up blithely presenting someone else’s content as your own, with no inkling of the impending disaster. Even if that sort of thing happened entirely by accident, due to a genuine mistake by a trustworthy colleague, the outcome would probably be annoying, and might even be embarrassing. But if the other person knew perfectly well what they were doing, and how to orchestrate it, and if they timed their “intervention” deliberately and maliciously, the outcome could be disastrous, and perhaps even career limiting. That’s an analogy of the content crisis that use-after-free bugs can cause, often with malware implantation being the unexpected and unwanted side-effect of an exploitable use-after-free hole.
Why browser zero-days matter
Zero-days triggered by memory mismanagement while the browser is rendering a page are always worrying.
That’s because remote code execution (RCE) holes in a browser often lead to so-called drive-by downloads, where merely looking at a booby-trapped web page could leave you with malware implanted on your computer or your phone.
You will also hear this sort of infection called a zero-click attack, because the attackers don’t need to convince you (or your computer) to do anything more than to view their content – something that’s generally supposed to be safe because it happens entirely inside your browser window.
Most phishing attacks, for example, need to persuade you to fill in and submit a dishonest web form, to open a malicious attachment, or to agree to download and launch a file you weren’t expecting and didn’t ask for.
That gives well-informed users a good chance to avoid the attack, because it generally can’t happen by default, or by mistake.
But a zero-click or drive-by attack can happen “by default”, without giving even the best-equipped user a chance to to say, “No!” and head off the malevolence.
What to do?
Check that you have Chrome (or Chromium) 98.0.4758.102 or later, up from the previous official build number of 98.0.4758.80.
You can list the version number by visiting the special URL chrome://version in your Chrome (or Chromium-based) browser: the four-part version number should appear on the first line of the output, like this:
We can’t tell you whether Edge, probably the next-most-widely-used Chromium-based browser out there, is affected by this bug, and Edge version numbers don’t align with Chrome’s numbering after the initial pair of “major/minor” numbers (in this case, 98.0).
The stable version of Edge doesn’t have an update out yet [2022-02-15T16:10Z], at least in its official Linux repository, where we update from, but we suspect there will be one out soon.
To check whether you’re already running the latest version in both Chrome and Edge, click DotDotDot (the More menu) in the top right, then use Help and About to access the version-plus-update dialog.
Update. The Edge repository linked to above was updated on 2022-02-16 with Edge 98.0.1108.55. The URL edge://version (or, for that matter, chrome://version) will report the four-part version number you’re using.