Security vulnerabilities fixed in Firefox 72.0.1 and ESR 68.4.1

[sat_nam]

In the advisory, Mozilla states it was being used as part of targeted attacks. Qihoo 360 ATA is credited with discovering the vulnerability and the in-the-wild exploitation of the flaw. Catalin Cimpanu says Qihoo 360 deleted a tweet connecting this bug to an undisclosed Internet Explorer zero-day [1] so it remains to be seen if there is another bug out there that remains unpatched. Mozilla also patched a pair of vulnerabilities that were used in targeted attacks last year [2]

[1] https://twitter.com/campuscodi/status/1215020566656299011

[2] https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-m...

[sp332]

Was this bug introduced in a recent version or is it old? I tried clicking through to see the bug, but I'm "not authorized".

Edit2: never mind the old edit, lmkg has a good point about the age of the CVE.

[hannibalhorn]

Given it affects the ESR release, I suspect it's been around a while. More details would be indeed be nice!

[lmkg]

> The CVE was created last September, so it was known about at least that long

Mozilla could have reserved CVE numbers in blocks, and still be allocating from that batch.

[ve55]

For anyone who is unable or unwilling to update, setting the following two values to 'false' in about:config should patch this:

javascript.options.baselinejit

javascript.options.ion

I cannot 100% confirm this as I haven't found a PoC in the wild yet, however.

[fbender]

Be aware that this will disable two tiers of JS acceleration (JITting): The lowest level (BaselineJIT, introduced only recently) and the highest level (IonJIT for very hot code).

[mushufasa]

Anyone quickly know if this fixes a bug introduced yesterday by 72, or if this is a longstanding bug?

(e.g. Canonical seems to still be on firefox 71 via standard ppa)

[discreditable]

ESR is affected, so it's possibly as old as July 2019. Maybe older.

[looperhacks]

I don't know exactly how this works, but it got a 2019 CVE number, so I guess it's older than yesterday?

[inetknght]

Running Firefox in an Alpine-based Docker container. What could go wrong?

Well, for starters: Alpine's ESR appears to be on 68.3.0esr.

Is there perhaps a better way to run Firefox in a Docker container?

[yjftsjthsd-h]

> Is there perhaps a better way to run Firefox in a Docker container?

You could always build your container from a glibc distro and then just download and use the official binaries from Mozilla.

[sadfklsjlkjwt]

Why would you run Firefox in a Docker container?

[Jonnax]

Is it possible to get it working with GUI or are you using it for automation?

[kdmccormick]

Honest question: Does it matter? Wouldn't the containerization protect you from the vulnerability?

[svnpenn]

Dont forget that if you manually update, Firefox destroys your update settings:

https://bugzilla.mozilla.org/show_bug.cgi?id=1576400

[prophesi]

When you try to manually update via the installer, make sure to pass the /RemoveDistributionDir=false flag, then you're good to go. If you're a power user who understands the security implications of not having automatic updates, this shouldn't be too hard.

[thenewnewguy]

There's a flag mentioned in that issue you can pass to the installer to disable that behavior.

Also, are there seriously people running FF with updates disabled? I personally see almost no scenario under which I'd ever not want to update.

[gpm]

The normal way to manually trigger an update is help -> about firefox -> update... which doesn't appear to destroy any settings.

[TwoNineFive]

> "If you choose not to use [automatic updates], then you must accept that you are stepping into an edge case" WTF Molly Howell.