7 ms·

Security vulnerabilities fixed in Firefox 72.0.1 and ESR 68.4.1

124 points by rahuldottech 7y ago

sp332 7y ago
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 7y ago
  Given it affects the ESR release, I suspect it's been around a while. More details would be indeed be nice!
- lmkg 7y ago
  > 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 7y ago
    Is there a reason why an organization would continue to use CVE numbers from last year?
    - callmejonas 7y ago
      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.
brobot182 7y ago
Guess they haven't rewritten the whole thing in Rust yet
mushufasa 7y ago
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)
- looperhacks 7y ago
  I don't know exactly how this works, but it got a 2019 CVE number, so I guess it's older than yesterday?
  - lmkg 7y ago
    CVE numbers can be reserved in blocks. Don't know if Mozilla does that, but if so, a new vulnerability could get an older-looking number.
    - looperhacks 7y ago
      So you could still use older years numbers?
- discreditable 7y ago
  ESR is affected, so it's possibly as old as July 2019. Maybe older.
  - dmix 7y ago
    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.
svnpenn 7y ago
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 7y ago
  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.
  - nvr219 7y ago
    I love updates so much I run Nightly!
  - ydnaclementine 7y ago
    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 7y ago
      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 7y ago
        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.
inetknght 7y ago
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 7y ago
  Why would you run Firefox in a Docker container?
  - Kye 7y ago
    Possibly for generating previews remotely or with different configurations.
  - inetknght 7y ago
    Theoretically, so that Firefox doesn't have trivial access to other files available to my user.
    - xorcist 7y ago
      Running it as a different user should suffice. Anyway, the problem alluded to is probably X11. Any GUI application will be able to do things like sniffing your keyboard and clipboard data. It's hard to do right (but of course isn't reason to not run untrusted applications with low privileges) and one of the things Wayland set out to improve.
      - aidenn0 7y ago
        You can run it in a separate vnc session as well to get isolation from X11, but that's a PITA.
    - minimalist 7y ago
      Use firejail instead. They use similar features (namespaces, seccomp, etc.)
    - 7y ago
ve55 7y ago
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 7y ago
  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 7y ago
    What does that even leave? The baseline interpreter?
    - fbender 7y ago
      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-faster-js-interpreter-in-firefox-70/ https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a...
      - deleted 7y ago
        [deleted]
sat_nam 7y ago
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-multiple-zero-day-vulnerabilities-in-mozilla-firefox-exploited-in https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-m...

124 points by rahuldottech 7y ago

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 7y ago
Given it affects the ESR release, I suspect it's been around a while. More details would be indeed be nice!
lmkg 7y ago
> 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 7y ago
  Is there a reason why an organization would continue to use CVE numbers from last year?
  - callmejonas 7y ago
    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.

brobot182 7y ago

Guess they haven't rewritten the whole thing in Rust yet

mushufasa 7y ago

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)

looperhacks 7y ago
I don't know exactly how this works, but it got a 2019 CVE number, so I guess it's older than yesterday?
- lmkg 7y ago
  CVE numbers can be reserved in blocks. Don't know if Mozilla does that, but if so, a new vulnerability could get an older-looking number.
  - looperhacks 7y ago
    So you could still use older years numbers?
discreditable 7y ago
ESR is affected, so it's possibly as old as July 2019. Maybe older.
- dmix 7y ago
  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.

svnpenn 7y ago

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 7y ago
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.
- nvr219 7y ago
  I love updates so much I run Nightly!
- ydnaclementine 7y ago
  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 7y ago
    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 7y ago
      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.

inetknght 7y ago

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 7y ago
Why would you run Firefox in a Docker container?
- Kye 7y ago
  Possibly for generating previews remotely or with different configurations.
- inetknght 7y ago
  Theoretically, so that Firefox doesn't have trivial access to other files available to my user.
  - xorcist 7y ago
    Running it as a different user should suffice. Anyway, the problem alluded to is probably X11. Any GUI application will be able to do things like sniffing your keyboard and clipboard data. It's hard to do right (but of course isn't reason to not run untrusted applications with low privileges) and one of the things Wayland set out to improve.
    - aidenn0 7y ago
      You can run it in a separate vnc session as well to get isolation from X11, but that's a PITA.
  - minimalist 7y ago
    Use firejail instead. They use similar features (namespaces, seccomp, etc.)
  - 7y ago

ve55 7y ago

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 7y ago
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 7y ago
  What does that even leave? The baseline interpreter?
  - fbender 7y ago
    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-faster-js-interpreter-in-firefox-70/ https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a...
    - deleted 7y ago
      [deleted]

sat_nam 7y ago

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-multiple-zero-day-vulnerabilities-in-mozilla-firefox-exploited-in https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-m...