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

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.

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

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

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

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.

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.

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

What does that even leave? The baseline interpreter?

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

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)

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

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.

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

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.

So you could still use older years numbers?

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?

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

Why would you run Firefox in a Docker container?

Possibly for generating previews remotely or with different configurations.

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

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.

You can run it in a separate vnc session as well to get isolation from X11, but that's a PITA.

You can run GUI apps from docker?

jessfraz has a great collection of Dockerfiles for various applications: https://github.com/jessfraz/dockerfiles

x11docker provides tooling: https://github.com/mviereck/x11docker

It takes a little configuration to allow X11 access, but yeah. https://github.com/woahbase/alpine-firefox

Heck, Qubes OS https://www.qubes-os.org/ even runs GUI apps from separate Xen VMs.

Yes. See also my other reply to basically the same question: https://news.ycombinator.com/item?id=21998987

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

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

Have you looked at firejail?

I have not. How does it compare, particularly for applications that need X11 to usefully function?

Way easier to use. For X: https://firejail.wordpress.com/documentation-2/x11-guide/

EDIT: also, https://wiki.archlinux.org/index.php/Firejail#Firejail_with_...

Automated Acceptance Tests is one use of Firefox inside docker.

We do that both for Chrome and Firefox.

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

    git clone https://github.com/inetknght/docker-firefox
    cd docker-firefox
    docker build --tag inetknght-firefox:latest $(pwd)
    docker run --rm -ti -v /tmp/.X11-unix:/tmp/.X11-unix --user $(id -u):$(id -g) inetknght-firefox:latest

Remember though that forwarding your X11 session is basically handing over keys to the kingdom. If something breaks out of the javascript sandbox and utilizes the exposed X11 socket it'll be as if it wasn't inside of a container anyway. On the other hand, that would be a problem anyway outside of a container so I don't see any increased risk compared to running Firefox directly on the host.

I do this to reset Firefox settings on every startup of the container and to have a consistent way for namespacing the filesystem and network (instead of using a Firefox plugin) vs doing the same for other applications too (for example, an IDE).

I really disagree with Mozilla's default settings and want to eventually configure Firefox differently. For example, I've mentioned on previous posts that I strongly disagree with Pocket. Others talk about what the new page should be; I think it should be about:blank. I also want to disable autofill. And I want to have a way to import identities into Firefox for TLS client authentication. There's a ton of other options I want to change as well. I just need to take some time to figure out how.

> default settings

You can override these at the "system" level.

    $ cat /etc/firefox/syspref.js
    // This file can be used to configure global preferences for Firefox
    // Example: Homepage
    //pref("browser.startup.homepage", "http://www.weebls-stuff.com/wab/");
    
    pref("general.smoothScroll",false);
    pref("general.autoScroll",true);
    pref("browser.search.suggest.enabled",false);
    pref("browser.ctrlTab.recentlyUsedOrder",false);
    pref("browser.startup.page", 3);  //http://kb.mozillazine.org/Browser.startup.page

> You can override these at the "system" level.

I am not at all interested in a host system level change because a system package can just as easily overwrite my changes there. That occurs frequently enough with other packages (eg, GNOME).

However, I think this is useful information to put into the Dockerfile and make that the system level changes. Thanks!

Yeah, I put "system" in quotes precisely because I figured you'd do it via COPY :)

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

> Does it matter?

Yes

> Wouldn't the containerization protect you from the vulnerability?

Running javascript even in a browser is plenty enough to extract information via Spectre and Meltdown. Javascript which can escape the browser sandbox can escape a container too.

A container won't protect you from spectre and meltdown.

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.

It's to be expected that running the installer will give you a fresh install of Firefox.

You can still manually update by hitting "About Firefox" in your menu, which will keep your settings as-is.

No it's not... Program files and settings are stored in two completely different folders... Even uninstalling a program shouldn't remove your settings unless it asks you first.

Well, yes, it will keep your Firefox profile and its related settings. It's only the about:config settings that will be reset, which I think is a sane default.

You realize this isnt true anymore right?

If you disable update via policy (which is the only way you can do it now that about:config method is removed), then going to "About Firefox" doesnt give you any options regarding updating.

Check your facts.

I did check them. I set my settings to "Check for updates but let you choose to install them." via the about:config method, which is the setting I assumed they were referring to.

I could still update from 72.0.0 to 72.0.1 from the About Firefox menu item, and from the about:preferences#general page. I'm running Mac OSX Catalina.

That said, Firefox is definitely doing what they can to make users keep auto updates on. I do think there should be a way to manually update if you've disabled both auto-updates and their update checks, without requiring the user running the installer, forcing you to toggle one of those settings off again.

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.

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

That's exactly what the "Distribution" directory is for. If the package manager is going to handle updates, it can disable FF's own built-in updater. But if you then download and run the vanilla installer from Mozilla directly, it will remove the distribution customizations, including switching back to the built-in updater.

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.

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.

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.

> I'm not even sure if the linux version of FF has an auto-updater.

It does if you download it directly from Mozilla.

I love updates so much I run Nightly!

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

You realize this isnt true anymore right?

If you disable update via policy (which is the only way you can do it now that about:config method is removed), then going to "About Firefox" doesnt give you any options regarding updating.

Check your facts.

??? One of the prefs in 68.* esr is "Allow Firefox to 1)... 2)Check for updates but let you choose to install them "

Maybe that's true only for non-ESR versions?

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