6 ms·

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

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!

nineteen20 3y ago
Congratulations! How did you spot the bug? As official Syzkaller has missed these lines of nf_tables.
- Unroll0201 3y ago
  Manual auditing ;-) I have specified it in https://pwning.tech/nftables#31-finding-the-bug https://pwning.tech/nftables#31-finding-the-bug
pelagicAustral 3y ago
Awwww Fuck me! that's my lazy afternoon gone now
- richardwhiuk 3y ago
  This is local privilege escalation only right?
  - Unroll0201 3y ago
    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.
    - dathinab 3y ago
      if it works for LXC containers shouldn't it also work for unprivileged (but non VM) docker containers?
      - Unroll0201 3y ago
        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.
- eikenberry 3y ago
  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.
  - blincoln 3y ago
    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.
derelicta 3y ago
Congrats! Impressive work!
junon 3y ago
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/main.c#L197 https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...
greggsy 3y ago
What are some potential attack vectors and impacts for this one?
- Unroll0201 3y ago
  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.
- MrStonedOne 3y ago
  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.
dev_snd 3y ago
Great work and great write-up! I especially love the MAINFRAME BREACH PROTOCOL that comes with it.
deleted 3y ago
[deleted]
yjftsjthsd-h 3y ago
> The affected exploit versions are from Linux kernel v5.14 up to v6.4. Linked page says > The exploit affects versions from (including) v5.14 to (including) v6.6, excluding patched branches v5.15.149>, v6.1.76>, v6.6.15>. ?
- Unroll0201 3y ago
  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.
cedws 3y ago
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?
- junaru 3y ago
  > Zerodium customers are government institutions (mainly from Europe and North America) in need of advanced zero-day exploits and cybersecurity capabilities. 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.
  - streb-lo 3y ago
    >clear evidence evidence is not what someone writes on their landing page
  - londons_explore 3y ago
    Governments only say they don't work with criminals.
    - redundantly 3y ago
      Government officials are often criminals themselves.
    - okasaki 3y ago
      Or the company is lying. It's not like anyone can check.
- Unroll0201 3y ago
  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
rfoo 3y ago
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?
- Unroll0201 3y ago
  I'm a bit late, but it's because I wanted my exploit to be universal. When patching kernel .text I'd need know: - know the offset to the patched instructions (memory scanning will not work) - know the architecture-compatible instructions to replace it with

nineteen20 3y ago

Congratulations! How did you spot the bug? As official Syzkaller has missed these lines of nf_tables.

Unroll0201 3y ago
Manual auditing ;-) I have specified it in https://pwning.tech/nftables#31-finding-the-bug https://pwning.tech/nftables#31-finding-the-bug

pelagicAustral 3y ago

Awwww Fuck me! that's my lazy afternoon gone now

richardwhiuk 3y ago
This is local privilege escalation only right?
- Unroll0201 3y ago
  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.
  - dathinab 3y ago
    if it works for LXC containers shouldn't it also work for unprivileged (but non VM) docker containers?
    - Unroll0201 3y ago
      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.
eikenberry 3y ago
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.
- blincoln 3y ago
  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.

derelicta 3y ago

Congrats! Impressive work!

junon 3y ago

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/main.c#L197 https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...

greggsy 3y ago

What are some potential attack vectors and impacts for this one?

Unroll0201 3y ago
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.
MrStonedOne 3y ago
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.

dev_snd 3y ago

Great work and great write-up! I especially love the MAINFRAME BREACH PROTOCOL that comes with it.

deleted 3y ago

[deleted]

yjftsjthsd-h 3y ago

> The affected exploit versions are from Linux kernel v5.14 up to v6.4. Linked page says > The exploit affects versions from (including) v5.14 to (including) v6.6, excluding patched branches v5.15.149>, v6.1.76>, v6.6.15>. ?

Unroll0201 3y ago
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.

cedws 3y ago

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?

junaru 3y ago
> Zerodium customers are government institutions (mainly from Europe and North America) in need of advanced zero-day exploits and cybersecurity capabilities. 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.
- streb-lo 3y ago
  >clear evidence evidence is not what someone writes on their landing page
- londons_explore 3y ago
  Governments only say they don't work with criminals.
  - redundantly 3y ago
    Government officials are often criminals themselves.
  - okasaki 3y ago
    Or the company is lying. It's not like anyone can check.
Unroll0201 3y ago
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

rfoo 3y ago

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?

Unroll0201 3y ago
I'm a bit late, but it's because I wanted my exploit to be universal. When patching kernel .text I'd need know: - know the offset to the patched instructions (memory scanning will not work) - know the architecture-compatible instructions to replace it with