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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
$ 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
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!
> 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.
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).
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.
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]
63 comments
[ 0.22 ms ] story [ 80.2 ms ] threadEdit2: never mind the old edit, lmkg has a good point about the age of the CVE.
Mozilla could have reserved CVE numbers in blocks, and still be allocating from that batch.
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.
(e.g. Canonical seems to still be on firefox 71 via standard ppa)
https://bugzilla.mozilla.org/show_bug.cgi?id=1576400
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.
Not sure how that conflict is resolved
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.
It does if you download it directly from Mozilla.
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.
Maybe that's true only for non-ESR versions?
You can still manually update by hitting "About Firefox" in your menu, which will keep your settings as-is.
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 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.
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?
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.
Heck, Qubes OS https://www.qubes-os.org/ even runs GUI apps from separate Xen VMs.
x11docker provides tooling: https://github.com/mviereck/x11docker
EDIT: also, https://wiki.archlinux.org/index.php/Firejail#Firejail_with_...
We do that both for Chrome and Firefox.
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.
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!
You could always build your container from a glibc distro and then just download and use the official binaries from Mozilla.
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.
javascript.options.baselinejit
javascript.options.ion
I cannot 100% confirm this as I haven't found a PoC in the wild yet, however.
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...
[1] https://twitter.com/campuscodi/status/1215020566656299011
[2] https://www.tenable.com/blog/cve-2019-11707-cve-2019-11708-m...