Would firejail have contained the lastest firefox vulnerability?

[Gerenuk]

There has been a recent Mozilla Firefox vulnerability
https://www.bleepingcomputer.com/news/security/mozilla-firefox-9702-fixes-two-actively-exploited-zero-day-bugs/
How much is the current firejail configuration helpful in containing this attack?
If not, is there any configuration I could add to prevent attacks from such bugs? Maybe blacklisting more directories?

[glitsj16]

If I understand correctly these zero-days relate to XSLT and WebGPU IPC. According to my Firefox about:support page WebGPU is disabled by default, 'blocked by runtime: WebGPU can only be enabled in nightly' and dom.webgpu.enabled is set to 'false'. For the XSLT bug I don't know any FF-internal settings. IMO combining more secure app-internal settings in tandem with Firejail is the better way to go about these potential exploits.

Regarding the WebGPU IPC bug Firejail might offer extra protection via its ipc-namespace option, but that isn't enabled in our Firefox profiles. I've read in comments that it might cause issues on X11. But nothing stops you from adding that to a firefox.local and determining if some functionality is affected by doing so. I've been running Firefox for quite a while with ipc-namespace, never noticed anything odd. But I run FF on Wayland so YMMV.

Blacklisting more directories is obviously always possible with Firejail. Our Firefox profiles are already designed as 'whitelisting' profiles though. These are more restrictive by design and only allow access to parts of the filesystem that have been explicitly configured. So IMO there's not much protection to be gained - if any - by more blacklisting.

[rusty-snake]

Regarding the WebGPU IPC bug Firejail might offer extra protection via its ipc-namespace option

I would be really surprised if firefox would use System-V IPC for that.

[Gerenuk]

Thanks for the detailed answer!
I'm additionally using Arkenfox user.js. Not sure if that helps. Also I don't know the web technologies and XSLT. No idea if I was exposed.
Unfortunately, Wayland results in too much flickering with KDE Plasma and my NVidia card.

As for blacklisting, I was wondering if denying other directories is beneficial?! For example Firejail itself warns that /sbin and /usr/sbin are not blacklisted. I thought if an attacker cannot execute his own code, but he can run system commands, he could exploit having access to more binaries? So I thought if blacklisting some more directories with binaries may provide protection under some circumstances.

[glitsj16]

I use arkenfox user.js too and that tightens Firefox considerably IMO. But zero-days are by definition 'unknowns' and it's very hard to judge if user.js could/would mitigate those.

Unfortunately, Wayland results in too much flickering with KDE Plasma and my NVidia card.

That's indeed unfortunate. I'd consider filing an issue about it, KDE Plasma seems to be very actively developing their Wayland stack. Or at least search for potential fixes if you haven't already.

As for blacklisting, I was wondering if denying other directories is beneficial?! For example Firejail itself warns that /sbin and /usr/sbin are not blacklisted.

Ah, if you see that warning I bet you're running Arch Linux (or a derivative). The warning is hardcoded in Firejail and harmless. It stems from the fact that Arch Linux symlinks /bin, /sbin and /usr/sbin to /usr/bin. We do blacklist system directories in disable-common.inc. A bit confusing for Arch Linux users probably.

I thought if an attacker cannot execute his own code, but he can run system commands, he could exploit having access to more binaries? So I thought if blacklisting some more directories with binaries may provide protection under some circumstances.

Firejail devs also considered this. And (amongst other things) came up with private-bin. It limits the set of executables considerably and IMO is a more effective way to protect against potential exploits than blacklisting directories. Have a look inside /etc/firejail/firefox.profile. It has a comment on how to enable private-bin in a firefox.local. Depending on your setup (installed extensions, possible nmh scripts they rely on etcetera) this might break functionality and you should test it thoroughly.

In general, what this all boils down to IMO is that there is not a single magic-bullet, install and forget kind of defense against zero-days. Combining defensive techniques is not easy either. Pretty sad situation in all, but that's the challenge we us users face each and every day. Firejail is an extra tool in this context and has its limits, shortcomings and bugs just as every other piece of software. But this is nothing 'new' :-)

[Gerenuk]

Thanks! I've tried private-bin and private-etc. Private-bin seems to work so far.

Update: Private-etc works, too. I forgot about firefox-common.

[rusty-snake]

How much is the current firejail configuration helpful in containing this attack?

Firejail can help if an attacker expolits these vulnerabilities and can run arbitrary code with the privileges of the main firefox process by limiting these privileges.

[topimiettinen]

If not, is there any configuration I could add to prevent attacks from such bugs? Maybe blacklisting more directories?

Firejail can't protect from use-after-free vulnerabilities. Its protections may be able to limit the Firefox exploit but not for example if there's also vulnerabilities with the kernel like Dirty Pipe. A memory allocator, which aggressively unmaps freed memory from process' address space during free() might be able to help, it would make the program crash instead of allowing the exploit to continue. Perhaps one day libaslrmalloc would be able to help in some cases but Firefox may still need recompiling to not use its bundled malloc implementation.

[rusty-snake]

a) yes (for firefox)
b) no, hardened_malloc is much better than mozjemalloc
c) yes (mozjemalloc is still a weak malloc implementation compared to hardened_malloc)

[Gerenuk]

Oh, then last question:
Is there an indication that a proper inclusion of hardened_malloc in Firefox could have mitigated the above vulnerabilities?

[Gerenuk]

And quick question from a newbie: how can I check if my attempt to compile with hardened_malloc was successful? (some kind of linux command?)

[topimiettinen]

Oh, then last question: Is there an indication that a proper inclusion of hardened_malloc in Firefox could have mitigated the above vulnerabilities?

The bug reports in the Mozilla advisory aren't public, so I don't know the details of the vulnerability. If the memory requested was small, hardened_malloc could still have recycled the slabs instead of unmapping the page, so it's not clear that using it would have prevented the exploit 100%.

[topimiettinen]

And quick question from a newbie: how can I check if my attempt to compile with hardened_malloc was successful? (some kind of linux command?)

Firefox with internal malloc implementation (possibly also if linked with hardened_malloc instead) doesn't use external libraries for malloc (the dynamic symbol for malloc is provided by the main executable):

$ objdump --dynamic-syms /usr/lib/firefox/firefox-bin | egrep '\smalloc$'
0000000000018190 g    DF .text  000000000000015a  Base        malloc

For LD_PRELOADing a different malloc implementation, it should use glibc version (the symbol is not defined):

$ objdump --dynamic-syms /usr/bin/ls | egrep '\smalloc$'
0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) malloc