Devastating 'Dirty Frag' exploit leaks out, gives immediate root access on most Linux machines since 2017, no patches available, no warning given — Copy Fail-like vulnerability had its embargo broken

extract

Devastating 'Dirty Frag' exploit leaks out, gives immediate root access on most Linux machines since 2017, no patches available, no warning given — Copy Fail-like vulnerability had its embargo broken A great disturbance in the cyberspace, as if millions of sysadmins suddenly cried out in terror. Here's a question for the systems administrators in the crowd: what's better than one instant-root™️Linux vulnerability that affects most every system since 2017? Two of them, of course. Today's bag of bad news comes by way of the Dirty Frag vulnerability, which uses a mechanism similar to the Copy Fail exploit that's currently setting the Linux server world on fire. This vulnerability affects nearly every Linux install since 2017, and no advance warning was given, so there is no patch available. This appears to be due to a broken embargo that revealed the vulerability before preparations were made. As a refresher, any local user can instantly get root (administrator) access on an affected box, just by running a small program. The attack does not depend on specific system conditions or timing, as it's a straightforward logic bug. Most every popular Linux distribution since 2017 is affected, including but not limited to current versions of Ubuntu (24 and 26), Arch, RHEL, OpenSUSE, CentOS Stream, Fedora, and Alma. We even tested WSL2 ourselves and sure enough, "root" was the word. Dirty Frag one-ups its cousin, though, as there are currently zero patches for it at the time of this writing, making it spectacularly dangerous. Even the mainline Linux kernel itself doesn't appear to have any patches, as one colleague of mine reported a successful trigger of the exploit on a CachyOS machine running kernel 7.0.3-1-cachyos, and also on an updated Arch box. Needless to say, keep your eyes peeled for updates and patch your servers the second they're available. Mercifully, though, the machine gods made the mitigation easy and unlikely to affect the functioning of the vast majority of servers. One needs only to disable the esp4, esp6, and rxrpc modules. These are all related in various degrees to IPSec networking and unlikely to be used unless the machine in question is an IPSec client or server. You can disable the modules in question with: 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" The reason why Dirty Frag is catching everyone flat-footed is because although the vulnerability was reported to the Linux kernel team in April 30, an "unrelated third party" broke the embargo for the reveal. The website offers no more detail, but our best theory is that it means the exploit is already in use by malicious actors, prompting the embargo breakage. If you want to test your boxen, you can use: git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp As far as technical details go, the story isn't much different than with Copy Fail, relying on exploiting a zero-copy operation by splicing a page cache descriptor into it. The different is that this time around, the fallible code is in the IPSec-related modules. The original vulnerability is "xfrm-ESP Page Cache Write", introduced in kernel commit cac2661c53f3 from 2017, and present across most distros. Since Ubuntu systems' AppArmor plugs that particular hole, the PoC chains a second exploit, "RxRPC Page-Cache Write", added in commit 2dc334f1a63a. Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds. Get Tom's Hardware's best news and in-depth reviews, straight to your inbox. Bruno Ferreira is a contributing writer for Tom's Hardware. He has decades of experience with PC hardware and assorted sundries, alongside a career as a developer. He's obsessed with detail and has a tendency to ramble on the topics he loves. When not doing that, he's usually playing games, or at live music shows and festivals. - bit_user Again, this is a local exploit. This should really be stated in the headline, which is too alarmist as written. It's not until the second paragraph that this is mentioned.Reply Yes, it's bad (mainly in terms of being published before patches were fully out, as we've seen plenty of privilege escalation exploits before). However, in the thread about the Copy Fail exploit, we saw that some folks clearly got the impression the vulnerability directly enabled a remote attacker to gain root access, which it didn't. Please take care not to mislead people. I'd suggest the headline should characterize it as a privilege-escalation exploit, which is the usual way of describing them. - chaos215bar2 Replygit clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Is Tom's Hardware really sure they want to be recommending people download, build, and run code straight from some Github repository without even bothering to explain who's repository this is? I mean, I'm going to assume this has been vetted and the repository is from a very well trusted source, but telling people to execute code effectively straight from a repository without further vetting doesn't exactly seem like the kind of thing you want to be recommending people do in an article about the second Linux zero day to drop in quick succession. - bit_user Reply Yeah, I'd say just link the repository. It has a readme which says how to execute it, if that's what someone chooses to do. But, you could also just study the source code by browsing it.chaos215bar2 said:Is Tom's Hardware really sure they want to be recommending people download, build, and run code straight from some Github repository without even bothering to explain who's repository this is? - ThisIsMe It’s not limited to local only. It can be remotely executed by any user that has remote access to the Linux device. This describes a large number of Linux devices. This could also affect systems that have other software running on them with possible vulnerabilities that let you execute code within its context. To try understating it is dangerous imho. It likely means much less to people who only have that one hobby-fulfilling Linux installation at home so they can say they have a Linux installation at home. However, this will affect many devices and enterprise Linux environments.Reply - rluker5 I like that Tom's posted a fix.Reply I rarely run Linux, mostly just to occasionally check it out, know almost nothing about it, but would have no problem copy/pasting that line to put myself at ease. - bit_user Reply What the local/remote thing is really meant to distinguish is whether or not you're authenticated. Someone who is not logged in to a machine and doesn't have a way of making an authenticated user execute arbitrary code cannot apply this exploit.ThisIsMe said:It’s not limited to local only. It can be remotely executed by any user that has remote access to the Linux device. Yes, if there's a remote-access exploit, which grants access or execution privileges to a remote, unauthenticated actor, then they can combine such remote-access or code-execution exploits with privilege-escalation.ThisIsMe said:This could also affect systems that have other software running on them with possible vulnerabilities that let you execute code within its context. - JarredWaltonGPU Reply Seems like this would be pretty catastrophic in hosted Linux instances, as you could get root on any box. Hopefully the VMs are sandboxed off and can't affect other VMs on the same hardware. Still having full root access to any Linux system where you have an account is pretty bad. And any employee of a company who might be leaving could get root as well. Basically, while it doesn't inherently affect everyone, even a local account hack to get root is terrible and can't really be overstated as a serious issue. IMObit_user said:What the local/remote thing is really meant to distinguish is whether or not you're authenticated. Someone who is not logged in to a machine and doesn't have a way of making an authenticated user execute arbitrary code cannot apply this exploit. Yes, if there's a remote-access exploit, which grants access or execution privileges to a remote, unauthenticated actor, then they can combine such remote-access or code-execution exploits with privilege-escalation.