[ALERT] CopyFail 3.0 - Fragnesia - Unpatched vulnerability

Fragnesia is a universal Linux local privilege escalation exploit, discovered with V12 by William Bowling with the V12 team. Fragnesia is a member of the Dirty Frag vulnerability class. This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.

The technique extends the page-cache write bug class that includes Dirty Pipe: when a TCP socket transitions to espintcp ULP mode after data has already been spliced from a file into the receive queue, the kernel processes the queued file pages as ESP ciphertext. The AES-GCM keystream byte at counter block position 2, byte 0 is XORed directly into the cached file page. By selecting the IV nonce to produce a desired keystream byte, any target byte in the file can be set to any value — one byte per trigger invocation.

The exploit builds a 256-entry lookup table mapping each possible keystream byte to its corresponding nonce, then iterates over a payload, firing the splice/ULP race for each byte that needs changing. It writes a small position-independent ELF stub (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of /usr/bin/su in the page cache, then calls execve("/usr/bin/su") to obtain a root shell. The page cache modification is not backed to disk; the on-disk binary is untouched.

No kernel is patched against this one yet!

Mitigation

rmmod esp4 esp6 rxrpc
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf

Possible patches are currently discussed upstream:

More info:

12 Likes

man what a mess, good luck everyone

Hey Phil, since your NEW mitigation does something with /etc/modprobe.d/dirtyfrag.conf again. I’m wondering about the compatibility when i look at the last mitigation from Dirty Frag which you posted 6 days ago:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Is there something which we need to pay attention? Before we execute your NEW mitigation.

Proof of Concept pocs/fragnesia confirms the mitigation is the same as previous mitigation for DirtyFrag

$ cat /etc/modprobe.d/dirtyfrag.conf
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
5 Likes
rmmod esp4 esp6 rxrpc
rmmod: ERROR: Module esp4 is not currently loaded
rmmod: ERROR: Module esp6 is not currently loaded
rmmod: ERROR: Module rxrpc is not currently loaded

it means I’m not affected?

1 Like

Me too and other machines on my network

1 Like

Not quite. The modules are likely already installed on the filesystem, so it just needs something to trigger loading of those modules, and then exploit their vulnerabilities. (Note, however, I’m not following these developments closely, so I may be wrong. If I’m mistaken, please correct me.)

Thus, given that, it’s better to add that mitigation configuration file that prevents those modules from being loaded.

9 Likes

That’s loaded too.

But I’m assuming if we are getting the error module not loaded message, for those three modules, we can assume that nothing on our current system configuration needs them. Yes? No?

No, this modules are loaded dynamically on demand. you must blacklist them to prevent that a process can access them.

2 Likes

That was not my question. @denilsonsa already said above what you are saying. My questions was, if the modules hadn’t been loaded, which I learned by trying to rmmod them, then can I assume that nothing I’m currently using on my system needs those modules. In other words, can I assume I’m not breaking something on my system that I’m currently using.

that question was already discussed in the parallel-thread. in short: the main-number of users will face no problems by blacklisting these modules but some users may run into problems with vpn-providers and server-based usecases where these modules are used. trial and error is the answer.

Nothing used it between booting and running the command. We cannot know what other software that is installed on your PC that you haven’t used and could cause them to load.
However, it seems unlikely that you will end up with an unbootable system.

Just in case keep a bootable USB Stick around

2 Likes

For the record. I’m using Mullvad-VPN, and running a Local Manjaro Server, and experiencing no issues, with these modules blacklisted.

4 Likes
4 Likes

Yes, I’m also using Mullvad with no problems. It was unclear to me if the reference to vpn-providers meant consumer oriented vpn services like Mullvad or something more complicated that has to do with business applications.

**

[Edit]

I found this information that discusses a little what the esp4, esp6, and rxrpc modules are used for:

Esp4 and esp6 are used for IPsec vpn connections. Since most consumer oriented VPN services use wireguard and openvpn, probably that’s not going to affect many people on those sorts of services. But in the business world it sounds like it’s still widely used.

Rxrpc is a network protocol mainly used somehow mostly to operate the Andrew File System, which I guess is used mainly for file sharing and distributed systems. It sounds complicated. I don’t really understand it.

So it sounds like blacklising esp4, esp6, and rxrpc is not going to affect your average linux desktop end user. But it may be a nightmare for businesses and system administrators who deal with backend systems of all sorts.

4 Likes

It is only a matter of time before a patch comes and the mitigation isn’t needed anymore.