Mozilla just pushed out an update for its Firefox browser to patch a security hole that was already being exploited in the wild.
If you’re on the regular version of Firefox, you’re looking to upgrade from 74.0 to 74.0.1 and if you’re using the Extended Support Release (ESR), you should upgrade from ESR 68.6.0 to ESR 68.6.1.
Given that the bug needed patching in both the latest and the ESR versions, we can assume either that the vulnerability has been in the Firefox codebase at least since version 68 first appeared, which was back in July 2019, or that it was introduced as a side effect of a security fix that came out after version 68.0 showed up.
(If you have ESR version X.Y.0, you essentially remain on the feature set of Firefox X.0, but with all the security fixes that have come out up to and including Firefox (X+Y).0, so the ESR is popular with IT departments who want to avoid frequent feature updates that might require changes in company workflow, but don’t want to lag behind on security patches.)
What we can’t tell you yet are any details about exactly how long ago the bug was found by the attackers, how they are exploiting it, what they’re doing with it, or who’s been attacked so far.
Right now, Mozilla is saying no more than this:
CVE-2020-6819: Use-after-free while running the nsDocShell destructor Under certain conditions, when running the nsDocShell destructor, a race condition can cause a use-after-free. We are aware of targeted attacks in the wild abusing this flaw. CVE-2020-6820: Use-after-free when handling a ReadableStream Under certain conditions, when handling a ReadableStream, a race condition can cause a use-after-free. We are aware of targeted attacks in the wild abusing this flaw.
The bug details in Mozilla’s bug database aren’t open for public viewing yet [2020-04-04T14:30Z], presumably because the Mozilla coders who fixed the flaw have, of necessity, described and discussed it in sufficient detail to make additional exploits very much easier to create.
What does use-after-free mean?
A use-after-free is a class of bug caused by incautious use of memory blocks by a program.
Usually, a program returns blocks of memory to the operating system after it has finished with them, allowing the memory to be used again for something else.
Returning memory when you are done with it stops your program from hogging more and more RAM the longer it runs until the whole system bogs down.
The function call by which memory is returned to be used again is called free(), and once you’ve freed the memory, you rather obviously shouldn’t access it again.
Most importantly, if you read and trust data that now belongs to another part of the program – for example, memory that just got re-allocated as a place to store untrusted content that was downloaded from a web page or generated by JavaScript fetched from outside – then you may inadvertently put your code at the mercy of data that was carefully crafted by a crook and served up to trick you on purpose.
Not all use-after-free bugs are exploitable, and not all exploits are made equal – for example, an attacker might only be able to change the content of an icon or a message you are about to display, which could be used to deceive users (for example by giving positive feedback when something actually failed), but not to implant malware directly.
But in some cases, use-after-free bugs can allow an attacker to change the flow of control inside your program, including diverting the CPU to run untrusted code that the attacker just poked into memory from outside, thereby sidestepping any of the browser’s usual security checks or “are you sure” dialogs.
That’s the most serious sort of exploit, known in the jargon as RCE, short for remote code execution, which means just what it says – that a crook can run code on your computer remotely, without warning, even if they’re on the other side of the world.
We’re assuming, because these bugs are dubbed critical, that they involve RCE.
What to do?
What one team of crooks has already found, others might find in turn, especially now they have at least a vague idea of where to start looking.
So, as always, patch early, patch often!
Most Firefox users should get the update automatically, but you might as well check to make sure it’s there – because the act of checking will itself trigger an update if you haven’t got it yet.
Click the three-bar icon (hamburger menu) icon at the top right, then choose Help > About Firefox.
Right. Click on About to bring up the version dialog and check for updates.
