Today I published a proof-of-concept exploit for CVE-2024-1086, working on Debian and Ubuntu among others.
The affected exploit versions are from Linux kernel v5.14 up to v6.6. The support for v6.4 to v6.6 is depending on the `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` kernel config variable, but please check README.md for this info.
The bug was patched in February 2024, and has been labelled CVE-2024-1086.
Make sure to update your Linux devices!
Can I ask why you decided to disclose this exploit rather than sell it to a company like Zerodium? Is it a matter of ethics, or is the money not worth it for you?
How does this even openly exist in post Stuxnet world? If this is not clear evidence of government working with criminals i don't know what is.
Governments only say they don't work with criminals.
Government officials are often criminals themselves.
Or the company is lying. It's not like anyone can check.
evidence is not what someone writes on their landing page
For me it is about the ethics among other things. I do not know to which goverments Zerodium is selling, much like any other zeroday broker. Additionally, I wouldn't be surprised if selling to Zerodium is illegal to begin with.
By taking the KernelCTF approach I get my bounty, I don't get into legal trouble, and I get to contribute to the Linux kernel VR community which means a lot to me
Thank you for having morals and giving this away to the community. Governments already have enough power that they don’t need more. I respect this very much, it’s hard to find people on hacker news who aren’t dyed in the wool capitalists.
Thank you, appreciated.
You are being downvoted, but as an outside observer I have also always been interested in ethics of security research.
Awwww Fuck me! that's my lazy afternoon gone now
This is local privilege escalation only right?
Correct, but it is definitively worth updating for on high-profile systems.
I have not tested it, but because I have included the namespace escape in the exploit for KernelCTF, it may be able to break out of LXC containers and privileged Docker containers running on vulnerable Linux kernels.
if it works for LXC containers shouldn't it also work for unprivileged (but non VM) docker containers?
This is an educated guess, but I believe unprivileged Docker containers cannot create (user) namespaces. Hence, the vulnerability cannot be triggered, since the exploit requires interaction with nf_tables, which requires (namespace) root.
LXC containers and privileged Docker containers allow these namespaces to be made inside of them, whilst unprivileged Docker containers do not.
Fixed kernel was released to Debian stable well over a month ago (my logs have it installed on 2/12). So unless you ignore kernel security updates you should already be covered.
Unfortunately, this was almost the same time that the Debian devs also pushed the ill-conceived Nvidia-driver-breaking kernel patch, so I wouldn't be surprised if a lot of people had disabled kernel updates.
What are some potential attack vectors and impacts for this one?
The attack vectors are pretty much the same for other Linux kernel LPE exploits. The impact is also much alike: privilege escalation from unprivileged user to root user. Should be noted that the exploit can read/write any physical memory on the device, but uses it to become root user.
An important note is that the exploit requires nf_tables to be present, and unprivileged user namespaces. This can be checked with commands specified in the README.md file in the repo.
Notice however that the exploit contains a namespace escape, allowing it to break out of namespaces on vulnerable kernels. As said in the other comment, this possibly includes LXC containers and privileged Docker containers, but this is not tested and is purely an educated guess).
The namespace escape is included because it is a requirement for the KernelCTF program.
Attack vector requires local execution access and allows for escaping limited privileges like non-root user accounts and breaking out of (some?) namespace jails used by containers and sandboxing systems.
Linked page says
?
The exploit support from v6.4 - v6.6 is depending on a Linux kernel kconfig value. If `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` is set to `y`, the exploit is not working. If it is set to `n`, it does work. I have updated my comment.
Good job writing this up!
Quick question: for "post"-exploitation, once you had a KSMA-like primitive why would you choose to still do the modprobe_path dance, and introduce a pid bruteforce for fileless :(, instead of e.g. patching kernel .text with a short shellcode to become root & break out of namespaces?
Haha. Nice sources. And nice work, curious what the larger response to this will be.
https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...
Great work and great write-up! I especially love the MAINFRAME BREACH PROTOCOL that comes with it.
Congrats! Impressive work!