CVE-2021-26910 and --overlay-tmpfs

[laniakea64]

I know that as an emergency fix for this CVE, firejail disabled all the overlay-related features, "fixes pending" - fb9f2a5

As I depend on extensive use of --overlay-tmpfs, and this is still disabled / fixes still pending, this became very concerning.
Sorry I'm a bit late asking about this (been busy), but looking at and testing with the publicly available exploit code, I gather that:

• Exploiting this vulnerability is not done from inside the firejail sandbox. It is done by a malicious program invoking firejail from outside a sandbox.

• The vulnerability is specifically with the overlay features that mount (persistent) overlays inside the home directory. (which I don't use)

Is this assessment correct?

Also I have two questions:

1. On my Xubuntu 20.04 + firejail 0.9.64, the exploit code fails:

$ gcc -g -fPIC -o UnjailMyHeart UnjailMyHeart.c
$ ./UnjailMyHeart
Using default firejail startup arguments.
Before sleep.
Failed to rename directories 2 (No such file or directory).
Renamed ".firejail" directory.
Exploitation failed.

And these overlay features are broken anyway:

$ firejail --overlay --noprofile
Parent pid 4040, child pid 4042

**     Warning: dropping all Linux capabilities     **

Debug: running on kernel version 5.4
Error mounting overlayfs: fs.c:1063 fs_overlayfs: Too many levels of symbolic links
Error: proc 4040 cannot sync with peer: unexpected EOF
Peer 4042 unexpectedly exited with status 1

Does it mean my setup is not vulnerable?

$ firejail --version
firejail version 0.9.64

Compile time support:
        - AppArmor support is enabled
        - AppImage support is enabled
        - chroot support is enabled
        - D-BUS proxy support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - firetunnel support is disabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - SELinux support is disabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled

2. As --overlay-tmpfs mounts in a firejail-controlled, root-owned subdirectory of /run, is it immune to this vuln? If so, could you please restore the --overlay-tmpfs while keeping the other, still-vulnerable overlay features disabled (and thus keeping this vulnerability closed)?

Thanks!

---

Relates to:

• CVE-2021-26910
• --overlay-named exits with error as of linux 5.1.15 (overlayfs) #2799
• How to compile with overlayfs support? #5658
• Will overlay / overlay-tmpfs options ever be restored (overlayfs)? #6041
• docs: clarify unmaintained status of overlayfs in configure.ac #6632

[reinerh]

Ping @netblue30.

I think one of the reasons to just disable --overlay was that it is broken on "newer" kernels anyway, as you already noticed.

I don't know why it fails on your Xubuntu, which still has a vulnerable version. Maybe the exploit code is not flexible enough.

[laniakea64]

Ping @netblue30.

Hi @netblue30 have you been able to look at this yet? Thanks

[laniakea64]

Just happened on #4006 (comment) -

You simply test if firejail --overlayfs-named=foobar --noprofile bash works. If it works, you're vulnerable.

Does this mean the answer to my question (1) is I'm not vulnerable?

[rusty-snake]

This command fails if (a) firejail is build w/o overlayfs support, (b) overlayfs support is disable in firejail.config or (c) you use a newer kenrel where firejail overlayfs implementation is broken. In all three cases you can not use --overlayfs/--overlayfs-named and therefore it can not be exploited (as I understand everything).

FYI: #2799

[laniakea64]

As --overlay-tmpfs mounts in a firejail-controlled, root-owned subdirectory of /run, is it immune to this vuln? If so, could you please restore the --overlay-tmpfs while keeping the other, still-vulnerable overlay features disabled (and thus keeping this vulnerability closed)?

Hi, with 0.9.66 now on the way to release, it would be awesome to have an answer to this, especially if --overlay-tmpfs alone can be safely restored. Thanks!

[laniakea64]

It seems @netblue30 is too busy to even respond to this, and no one is contradicting #4178 (reply in thread) which basically says overlay-tmpfs just got thrown out with the bathwater and is not itself vulnerable. So could propose the following resolution? -

• Completely separate build-time options for overlayfs and overlay-tmpfs. In all the time I've used firejail, support/usability of these two features has always been very different, so this would seem to make sense anyway.
• Keep the build-time option for overlayfs hard-disabled / commented out until that feature is really fixed.
• For the moment, make the build-time option for overlay-tmpfs disabled by default, but still accessible for those who need it (like the apparmor option is now).

Would this be reasonable?

[smitsohu]

If I recall correctly, the overlay-tmpfs option is indeed unaffected.

To me your proposal sounds reasonable, but it would be a stopgap only.

[laniakea64]

Thanks smitsohu 🙂

Any update on this?

[laniakea64]

Hi, any news on this?

Unfortunately I don't have enough C knowledge to pull request the proposal in #4178 (comment) myself. Could this be done before or soon after the upcoming 0.9.68 release?

If not, since my particular systems are not affected by the vulnerability, will I need to just manually revert that part of fb9f2a5 for my local builds for now to update firejail beyond 0.9.64 without losing the important --overlay-tmpfs?

[rusty-snake]

If not, since my particular systems are not affected by the vulnerability, will I need to just manually revert that part of fb9f2a5 for my local builds for now to update firejail beyond 0.9.64 without losing the important --overlay-tmpfs?

Yes, -DHAVE_OVERLAYFS should enable this code again.

[laniakea64]

So, this had been working well until one of my systems was upgraded to kernel 5.19.0. Apparently this kernel update put --overlay-tmpfs on the wrong side of a broken kernel version check intended to disable --overlay under kernels 4.19 and later - #2799 (comment)

So now I'm experimenting with the following patch in addition, which testing it seems to successfully restore --overlay-tmpfs under my 5.19.0 kernel while keeping --overlay blocked as intended -

diff --git a/src/firejail/fs_overlayfs.c b/src/firejail/fs_overlayfs.c
index 167a7e28b..375ddbdf5 100644
--- a/src/firejail/fs_overlayfs.c
+++ b/src/firejail/fs_overlayfs.c
@@ -144,8 +144,8 @@ void fs_overlayfs(void) {
 
        // mounting an overlayfs on top of / seems to be broken for kernels > 4.19
        // we disable overlayfs for now, pending fixing
-       if (major >= 4 &&minor >= 19) {
-               fprintf(stderr, "Error: OverlayFS disabled for Linux kernels 4.19 and newer, pending fixing.\n");
+       if (arg_overlay_keep) {
+               fprintf(stderr, "Error: OverlayFS disabled, pending fixing.\n");
                exit(1);
        }
 

(And I wonder if this would also completely eliminate the vulnerability?)

[RaphaelJenni]

Is there any news regarding a fix for the overlays feature in firejail. I need a tool that lets me run processes as if they were on the host machine but captures all changes that were made to the filesystem in a different folder.

Firejail seemed to be able to do this until the option got remvoed.

[rusty-snake]

#6632 (comment)

• crablock and bubblewrap have integrated support for overlayfs. This was possible because Linux >= 5.11 allows overlayfs mounts from unprivileged user-namespace. An "unprivileged" implementation in firejail might be the most likely comeback as it means less auditing.