V4bel/dirtyfrag

Tracked at https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/2151831

as pointed out by @ChrisTX, if you can corrupt the page cache of any file you have `READ` permission, then it would be fairly easy to build an escape by identifying a privileged container on the node and messing with it's container image content. I've described 2 such exploits over here https://github.com/clementnuss/copyfail-cve-exploits

I'm currently trying to see if `dirtyfrag` can do the same but I expect it to be the case. I'll update this post in a few hours!

Tested on `PVE 5.15.143-1 (2024-02-08T18:12Z) x86_64 Linux` seems not vulnerable.It is too old. :>

RedHat still offer security support for RHEL7 ("extended lifecycle support"). It is possible to compile the exploit on RHEL7.9. You need a newer GCC but it's not uncommon to have that available. Here using GCC 10.2.0.

Copy header from kernel sources:
```
mkdir -p include/linux
cp /usr/src/kernels/$(uname -r)/include/linux/rxrpc.h include/linux/
```

Patch the exploit code to make it compile:
```
diff --git a/exp.c b/exp.c
index d8d5711..25b5e1c 100644
--- a/exp.c
+++ b/exp.c
@@ -1,3 +1,5 @@
+typedef unsigned short u16;
+
#define _GNU_SOURCE
#include
#include
@@ -16,7 +18,7 @@
#include
#include
#include
-#include
+// #include
#include
#include
#include
```

Compile with
```
gcc --std=c99 -I./include -O0 -Wall -o exp exp.c -lutil
```

However, running the exploit fails. Tested on kernel `3.10.0-1160.147.1.el7.x86_64`.

But that doesn't mea...

On rootless containers like "unprivileged LXC" if the rootfs of the container is isolated, it cannot escape.

You're running CentOS 7 so you're already screwed regardless of _this_ vulnerability.

I have tested it on GKE and ACK clusters. All failed.

On ACK default node image:
user.max_user_namespaces is set 0, so unprivileged user can't use CLONE_NEWUSER unshare.
On GKE default node image (COS):
user.max_user_namespaces is 15426, but kubelet enables --seccomp-default, the default seccomp policy disable unshare syscall.

In my quick tests unprivileged LXC are not exploitable even if the proxmox host is.

Maybe we should evaluate the unprivileged LXC case: if it's blocked by seccomp/AppArmor, the risk is likely low.

The kernel is Ubuntu and user space is Debian

No surprise.. proxmox kernels are based heavily on Debian.
Just in case you had not already done this, I have emailed proxmox security team to alert them. Also posted here since there is no point in hiding this information: https://forum.proxmox.com/threads/dirty-frag-universal-linux-lpe-proxmox-vulnerable-in-the-wild-already.183363/

They usually backport security fixes, not entire features. If it's not essential, it's not backported. I can't see why they would have backported that stuff unless it was breaking something else important and that bad code was part of the fix.

It's true that 3.10 was released in 2013 (with LTS thru 2017 I think).

That said, Red Hat does a lot of back porting into their EL kernels and 3.10.0-1160 was released in 2020 (still old) with end of maintenance in 2024 and of extended support ending in 2028.

It's the back porting that may make it vulnerable. 🤷

That kernel is way too old for that. The bug was introduced in a commit from 2017-01-17, your kernel is from 2013.

yes here too
mitigation :

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"

works on all my servers, including ubuntu 26.04, after a reboot