
Security vulnerabilities fixed in Firefox 72.0.1 and ESR 68.4.1 - rahuldottech
https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/
======
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](https://twitter.com/campuscodi/status/1215020566656299011)

[2]
[https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-m...](https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-multiple-
zero-day-vulnerabilities-in-mozilla-firefox-exploited-in)

------
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.

~~~
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.

~~~
gruez
Is there a reason why an organization would continue to use CVE numbers from
last year?

~~~
callmejonas
CVE are assigned from the year the vulnerability was found. Not when it was
announced.

However, a CNA like Firefox does not allocate CVE as they need them. They
first ask Mitre for a block of X CVE to use as they need. They probably got a
new block in September.

------
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).

~~~
saagarjha
What does that even leave? The baseline interpreter?

~~~
fbender
Sorry, I had it partially wrong. There‘s the C++ Interpreter and the baseline
interpreter (that one was added only recently[1]), and then the two JITs
(BaselineJIT and IonMonkey). I understand that IonMonkey itself has two levels
chosen depending on code hotness.

I.e. these settings will kill all JITs (so the highest 2-3 tiers) and leave
the two interpreters.

[1] [https://hacks.mozilla.org/2019/08/the-baseline-
interpreter-a...](https://hacks.mozilla.org/2019/08/the-baseline-interpreter-
a-faster-js-interpreter-in-firefox-70/)

------
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.

~~~
dmix
The vuln is via IonMonkey JIT parsing. It might be as old as that project, I
hope we find out how far back it goes.

------
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?

~~~
sadfklsjlkjwt
Why would you run Firefox in a Docker container?

~~~
inetknght
Theoretically, so that Firefox doesn't have trivial access to other files
available to my user.

~~~
Scarbutt
You can run GUI apps from docker?

~~~
aidenn0
You can run GUI apps across a network, so why not?

~~~
Scarbutt
ah duh, forgot about how X11 works for a moment.

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

[https://bugzilla.mozilla.org/show_bug.cgi?id=1576400](https://bugzilla.mozilla.org/show_bug.cgi?id=1576400)

~~~
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.

~~~
ydnaclementine
Perhaps they disable FF updates to let their package managers handle it? (I'm
thinking in arch linux land for example)

Not sure how that conflict is resolved

~~~
thenewnewguy
I'm not even sure if the linux version of FF has an auto-updater. And even if
it does every distro I've ever used (Debian, Ubuntu, Fedora, and currently
Arch Linux) must disable it, because I've never had FF try to auto update on
linux.

~~~
gpm
Automatic updates don't play nicely with package managers that install things
as root, so it is disabled during the build process. It does exist though, and
is enabled on Linux if you download firefox from [https://www.mozilla.org/en-
US/firefox/new](https://www.mozilla.org/en-US/firefox/new).

OP in this thread seems to be using that installer with automatic updates, and
then disabling it by hand, since when updating via a package manager you don't
run into this issue.

