16 ms·

Flipping Pages: New Linux vulnerability in nf_tables and exploitation techniques

406 points by Unroll0201 3y ago

XCSme 3y ago
Wow, this is what it takes to find such a vulnerability? Even the initial diagram seems so complex. I wonder if AI can be used to test/find such complex exploits.
- jijijijij 3y ago
  > I wonder if AI can be used to test/find such complex exploits. https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/ https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
anonbanker 3y ago
I had been experiencing this vulnerability, as well as the Dirty Pagetable vuln, for the last six months. It's gotten to the point where I've disabled user and network namespaces entirely. Long story short: it's very advantageous for an unscrupulous kernel developer to take advantage of embargoes for 0-days on targets he does not like.
wcl_ 3y ago
Running on a VM on Debian 12 with 6.1 kernel. Got this: "failed to detect overwritten pte: is more PTE spray needed? pmd: 00000000cafebabe"
Unroll0201 3y ago
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.
amne 3y ago
Dodged it! 5.10.184-175.749.amzn2.x86_64 #1 SMP
mtlynch 3y ago
It looks like this repo is redistributing source from third-party libraries without required license notices.[0] You should put the license notices at the root of your ./include directories to respect the work of the libraries you're using. [0] https://github.com/Notselwyn/CVE-2024-1086/issues/1 https://github.com/Notselwyn/CVE-2024-1086/issues/1
- Unroll0201 3y ago
  Thanks for the notice. I will immediately fix it.
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
JonChesterfield 3y ago
Summary is netfilter has a use-after-free bug and that's sufficient to go from a normal shell to root. Bad times, nice demo
- deleted 3y ago
  [deleted]
okl 3y ago
Commit which introduced the problem: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0abdadcc6e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The nested switch/case with return in the default path, then expecting fall-through, looks bogus to me.
- rightbyte 3y ago
  Same guy? https://lwn.net/Articles/882397/ https://lwn.net/Articles/882397/
  - pphysch 3y ago
    > I would encourage you to read up on details of McHardy’s practices. They were clearly not done in good faith and there was no attempt to encourage compliance. The only goal was to extract as much money as possible even if the violations were more technical or incidental in nature and the companies willing to attempt remedy. Even minor and unintentional violations were pursued zealously without interest in remedy - just cash. > My understanding is he also didn’t truly prioritize deep pocketed violators (no suit against VMWare, afaik) - he prioritized that delicious sweet spot of “deep enough to pay me off, but too small to make it realistic to fight me in court”. And, again, he was uninterested in remediation of even minor and unintentional violations - he wanted cash. It seems unlikely this was helping the cause of free software. Seems entirely possible that such a character would knowingly insert a backdoor to sell as a 0-day.
    - spr-alex 3y ago
      this code was written before unprivileged network namespaces were much of a thing so the theory that a developer would plant a bugdoor for this is not probable. you can think of unprivileged namespaces in general as a bunch of attack surface that was previously root to kernel only and hadn't had much scrutiny. these bugs will take decades to eliminate without a rewrite of linux.
- MuffinFlavored 3y ago
  Your link converted to GitHub: https://github.com/torvalds/linux/commit/f342de4e2f33e0e39165d8639387aa6c19dff660 https://github.com/torvalds/linux/commit/f342de4e2f33e0e3916... https://bugs.launchpad.net/bugs/cve/2024-1086 https://bugs.launchpad.net/bugs/cve/2024-1086 > A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
cschmid 3y ago
For anyone who's wondering, you can see your current kernel config in a file like /boot/config or /proc/config.gz
yjftsjthsd-h 3y ago
I think it's misleading to label this "Debian/Ubuntu privilege escalation"; it's a Linux kernel local exploit, that happens to be confirmed to apply to Debian and Ubuntu. (Edit: Because when I read "Debian/Ubuntu privilege escalation PoC exploit for CVE-2024-1086" my first thought was something like, "Oh, is it in apt-get? Or is this another distro patch gone wrong?")
- KennyBlanken 3y ago
  [flagged]
  - jvanderbot 3y ago
    > Don't criticize a title based on a barely-15-seconds-examination of something. Suggest removing this, it's overly-reproachful and GP comment be explained by being less knowledgeable, busy, under-caffeinated, etc. Your comment is highly informative for those who had similar thoughts - no reason to make it negative in nature.
    - KennyBlanken 3y ago
      [flagged]
      - jvanderbot 3y ago
        You are free to attempt to enforce a price-of-admission to comment. I attempt to use the up/down vote to filter rather than reproach. I feel it's more in the spirit of HN. I appreciate you providing context to your thought process, and I am only doing so similarly for transparency. I think we can politely disagree about approach and go on our way now. Have a good day!
  - dang 3y ago
    If you keep posting personal attacks, we're going to have to ban you. I don't want to ban you—you're a knowledgeable user who has posted good things. But we've warned you a whole bunch of times already, the slack can't be infinite, and no amount of good comments makes it ok to repeatedly poison the well. https://news.ycombinator.com/item?id=39111764 https://news.ycombinator.com/item?id=39111764 (Jan 2024) https://news.ycombinator.com/item?id=35416693 https://news.ycombinator.com/item?id=35416693 (April 2023) https://news.ycombinator.com/item?id=34606566 https://news.ycombinator.com/item?id=34606566 (Feb 2023) https://news.ycombinator.com/item?id=33292588 https://news.ycombinator.com/item?id=33292588 (Oct 2022) https://news.ycombinator.com/item?id=32729960 https://news.ycombinator.com/item?id=32729960 (Sept 2022) https://news.ycombinator.com/item?id=32729939 https://news.ycombinator.com/item?id=32729939 (Sept 2022) https://news.ycombinator.com/item?id=31842940 https://news.ycombinator.com/item?id=31842940 (June 2022) https://news.ycombinator.com/item?id=30436952 https://news.ycombinator.com/item?id=30436952 (Feb 2022) https://news.ycombinator.com/item?id=30433141 https://news.ycombinator.com/item?id=30433141 (Feb 2022) https://news.ycombinator.com/item?id=28948931 https://news.ycombinator.com/item?id=28948931 (Oct 2021) If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
rakejake 3y ago
Running Ubuntu with Kernel 6.5.0-26 Got this? failed to detect overwritten pte: is more PTE spray needed? pmd: 00000000cafebabe
- Unroll0201 3y ago
  This is indeed expected. I specified in the "Caveats" section in README.md that the exploit does not work on Ubuntu v6.5 (because it enables a certain kernel config value that indirectly mitigates the exploit starting from v6.4), and may not work on other kernels above v6.4 depending on the config.
  - rakejake 3y ago
    Ah I read that versions upto v6.6 were affected and didn't notice the caveats. Thanks
loudmax 3y ago
This exploit relies on unprivileged access to user namespaces: `sysctl kernel.unprivileged_userns_clone = 1` This is the default setting for Debian/Ubuntu, and also Arch Linux kernels. If you don't have a need for that setting, (eg. running Docker commands without sudo), you should probably disable that anyway.
- yjftsjthsd-h 3y ago
  :\ It really is unfortunate that that setting is great for letting people run containers (and the like) without giving them root access... but also has a bad track record of then having vulnerabilities that allow root access.
  - dathinab 3y ago
    IMHO it is just too complicated/flexible designed.
    - yjftsjthsd-h 3y ago
      I'm not a kernel developer so take with a grain of salt; what I've heard suggested is that it's not fundamentally bad and if we'd had it from day one it would be fine, but a lot of kernel interfaces were designed with the idea that only root could use them so they didn't worry about certain security matters as much. And maybe that was never ideal but it could even be reasonable; if only root can trigger a bug that gives you root access... it's not good because it could be used to work around other restrictions, but one can imagine that it wouldn't exactly be a priority. But then what actually happened is that very late in the game we got this new feature that allows any old user to access these less-protected interfaces, and that's resulted in a certain amount of... catching up.
- dathinab 3y ago
  It's not just used by docker/packman. But also e.g. by the chrome sandbox used by e.g. electron apps (or e.g. 1password). Through that sandbox helper binary can also work with being a suid program. I also wouldn't be too surprised if e.g. proton will start using user namspaces at some point in the future. So for any non-hardened desktop linux system you probably should _not_ disable it! (For many servers or special hardened Linux it often isn't a bad idea to disable it.)
tryauuum 3y ago
why are unprivilged user namespaces enabled by default? why by default give user the ability to run iptables and other stuff (mount?) (even though it runs in an "unprivilged" namespace)
- yjftsjthsd-h 3y ago
  Because if they didn't keep having bugs like this, they'd be a great security feature. Like, it'd be great if running flatpaks didn't require a suid binary on the host in order to isolate apps.
- _factor 3y ago
  The issue is the “just works” philosophy. Most defaults are insecure and require technical expertise and hardening.
- kentonv 3y ago
  Unprivileged user namespaces make it possible for unprivileged programs to set up sandboxes. For example, Chrome uses namespaces to implement its process sandbox. However, Chrome installs a setuid-root binary, so that it doesn't need "unpriveleged" namespaces enabled. This is sad, though: setuid-root binaries are inherently a security risk of their own. It would be nice if Chrome did not need to install a suid-root binary. But, it can only possibly avoid this in the future if unprivileged user namespaces are widely available. Bugs like this unfortunately delay that future. Incidentally, programs like Chrome that set up namespace-based sandbox also commonly use seccomp to prevent the sandboxed code from using exotic kernel features -- including namespaces. So user namespaces won't be available to sandboxed code regardless of whether you enable unprivileged user namespaces at the system level. Personally I feel that on a single-user desktop, there's little point in enforcing a separation between users and root -- everything interesting is probably available to your user account anyway. But sandboxes like Chrome's are obviously essential to security on desktops. So I'd tend to say, on a single-user desktop, enabling unprivileged user namespaces improves security overall, by encouraging the use of sandboxes. Multi-user systems are a different story, obviously.
  - dathinab 3y ago
wiredfool 3y ago
According to ubuntu -- It hits all LTS releases, and is fixed in current patched kernels: (https://ubuntu.com/security/CVE-2024-1086 https://ubuntu.com/security/CVE-2024-1086) * Focal: 5.4.0-174.193 * Jammy: 5.15.0-101.111 * Mantic: 6.5.0-26.26 As well as Xenial and Bionic for those of you with extended support
whoopdedo 3y ago
Does this still work if you have user namespace covered by AppArmor? https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 https://discourse.ubuntu.com/t/spec-unprivileged-user-namesp...
bhaney 3y ago
Tried running it on a vulnerable Debian system of mine. Didn't privesc, but did lock up the entire system on the second run (first run just failed entirely). So still definitely worth taking the time to patch.
pqdbr 3y ago
How do I check if my Ubuntu kernel has already been patched? And if it hasn’t, any tips on how to upgrade?
- popol12 3y ago
  sudo apt-get install musl-tools git clone https://github.com/Notselwyn/CVE-2024-1086 https://github.com/Notselwyn/CVE-2024-1086 cd CVE-2024-1086 /disable your wifi (the author says it's increasing chances of the exploit working)/ ./exploit If it runs till the end, then you should update your kernel
  - caseyf 3y ago
    little warning for others - i tested it on a jammy box with kernel.unprivileged_userns_clone = 0 and it froze up good
- wiredfool 3y ago
  https://ubuntu.com/security/CVE-2024-1086 https://ubuntu.com/security/CVE-2024-1086 There's a super long list there, but most everything has been updated or superceded. The standard (updated) kernels are: * Focal: 5.4.0-174.193 * Jammy: 5.15.0-101.111 * Mantic: 6.5.0-26.26 And if you haven't updated, apt-get update && apt-get dist-upgrade.
  - RVRX 3y ago
    Can you help me with reading that page? What's the difference between the `linux-kvm` vs `linux-hwe-6.5`? They both list different release fixes for Jammy, 5.15.0-101.111 and 6.5.0-26.26 respectively. Edit: Oh it looks like the generic kernel is the one named just "linux" and also has 5.15.0... as the patched version on Jammy
    - wiredfool 3y ago
      FWIW, hwe is hardware enablement, so bleeding edge kernel on older distro. KVM is specifically focused on KVM virtual machines.
andy_xor_andrew 3y ago
I have some questions for you wizard shellcode-flinging hackers out there. with modern mitigations like ASLR and beyond, how are exploits like this even possible? I took a course in college which provided us with a dozen binaries, to be run on a specific Ubuntu version. Each binary had a different bug, use-after-free, buffer overflow, both, or more, and our task was to exploit it.[0] It was HARD. Finding the flaw was hard. Then, writing the exact correct shellcode to do something useful with the flaw was even harder. Especially when you only have the compiled binary and GDB to work with. In harder levels, we had to do this with mitigations enabled like ASLR, stack canaries, etc. And my takeaway was, this is nearly impossible, because you need to 1. discover an exploitable flaw (or multiple, and chain them together!!) 2. find the exact binary shellcode payload that will do something useful without simply crashing the executable. And this was in a controlled environment as students, not the real world which is even more difficult. So my question is, with all these mitigations, how is it possible?! [0] I googled for the exact project but could not find it, though it was very very similar to this: https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/assign6/ https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/a...
- 4gotunameagain 3y ago
  There's an entire section about KASLR in the blogpost linked on the repository.
- freedomben 3y ago
  short answer: some people are good, some people are lucky, and some people are good and lucky. It only takes one from the latter category to find these things longer answer: It is definitely really damn hard these days. Even disabling the mitigations, it's still pretty hard to find and a vuln and write an exploit. But many people who find these (not all though) work as part of a team, where they can parallelize fuzzing efforts and combine/chain knowledge and other exploits much better than an individual could. The level of expertise and talent that some of these people have is absolutely incredible, and experience is worth a pound of gold for these types of things, and some people have years or decades of experience.
- jimmyl02 3y ago
dang 3y ago
Url changed from https://github.com/Notselwyn/CVE-2024-1086 https://github.com/Notselwyn/CVE-2024-1086, which points to this.
- Unroll0201 3y ago
  Is there a reason why you did this? I knowingly chose the other title because it would apply more to the Hackernews audience to raise more awareness of the exploit and that people should update. This title was aimed at the Linux kernel VR community, which also shows because the post instantly dropped down from a 2-hour #1 position to #8
  - dang 3y ago
    The title generated complaints: https://news.ycombinator.com/item?id=39829308 https://news.ycombinator.com/item?id=39829308. In such cases we usually change the title (experience has shown this to be the best way to turn discussion away from title complaints to whatever the more interesting topic is). In doing that, I noticed that the blog post includes a lot more background than the github link, so I switched the URL as well.
deleted 3y ago
[deleted]
freedomben 3y ago
This is an extremely impressive write-up. When writing security blog posts, there's always a constant battle of essentially "how much background/prerequisite knowledge do I assume," and getting the balance right to make it accessible but also feasible to write can be very challenging. Identifying your target market up front, and then delivering to that market with plenty of background info, is no easy feat! Well done! I'm bookmarking this to give to aspiring researchers, of whom I meet a few every year who are looking for guidance like this.
- Unroll0201 3y ago
  Thank you so much! It feels great to hear this.
bakkoting 3y ago
From the patch [1]: > This reverts commit e0abdadcc6e1. [...] Its not clear to me why this commit was made. Anyone dug up the history here? [1] https://lore.kernel.org/all/20240120215012.129529-1-fw@strlen.de/ https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...
- tg180 3y ago
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0abdadcc6e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... > netfilter: nf_tables: accept QUEUE/DROP verdict parameters > Allow userspace to specify the queue number or the errno code for QUEUE and DROP verdicts.
  - loeg 3y ago
    Yeah, but why?
    - rokkitmensch 3y ago
      If one has to ask, it's a Five Eyes plant.
      - aseipp 3y ago
        Hardly. This is just a typical double free vulnerability, AKA a normal Tuesday in the C/C++ world, and which people have been exploiting in the kernel (with its complex object lifetimes and semantics) for well over 10 years now. There's no need to "plant" anything to find these.
        rokkitmensch 3y ago
        Which makes it a fine cover!
- aseipp 3y ago
  The original commit is over 10 years old now, so it's probably lost to the sands of time. I did some looking but couldn't find anything on the old netdev lists. Maybe the patch was sent directly to Pablo Neira Ayuso, the committer. It was part of a series so it's not like it was a one-off patch. In a strange twist of fate, the original author was Patrick McHardy who is now a persona non grata. Unless Pablo can remember or dig it from his emails, it probably won't ever be clear exactly what the use case was, at least not through basic investigation.
jcalvinowens 3y ago
Distros don't build with it, but CONFIG_INIT_ON_FREE_DEFAULT_ON prevents the exploit. I think it's a nice demonstration of the value of the hardening in the kernel.
- 1oooqooq 3y ago
  this zeroes memory on every allocation and deallocation. huge perf hit
  - jcalvinowens 3y ago
    Zeroing on allocation is almost free. You can invent microbenchmarks where it hurts, but for most workloads it doesn't matter. You can also invent micro cases where it is beneficial, because the cache is hot after the zeroing. The always kernel zeros all userspace allocations, and always has. In a former life, I actually tested this on an x86 webserver workload: the overhead of zeroing on allocation on CPUs that were Ivy Bridge or newer was so small it was literally impossible to measure in high-level web metrics. Sandy Bridge took a 1-2% hit in request throughput as I recall. Zeroing on free is a different story though, that trashes the cache.
FergusArgyll 3y ago
I just tried this on WSL Ubuntu (after an apt update && upgrade), Completely freaked my computer out, I almost thought I bricked it but a restart worked. I'm not smart enough to understand it but someone may want to look into it
mise_en_place 3y ago
Oof, double free is one of those notorious bugs. And to think it comes from something as innocuous as netfilter rules.

406 points by Unroll0201 3y ago

Wow, this is what it takes to find such a vulnerability? Even the initial diagram seems so complex. I wonder if AI can be used to test/find such complex exploits.

jijijijij 3y ago
> I wonder if AI can be used to test/find such complex exploits. https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/ https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

anonbanker 3y ago

I had been experiencing this vulnerability, as well as the Dirty Pagetable vuln, for the last six months. It's gotten to the point where I've disabled user and network namespaces entirely. Long story short: it's very advantageous for an unscrupulous kernel developer to take advantage of embargoes for 0-days on targets he does not like.

wcl_ 3y ago

Running on a VM on Debian 12 with 6.1 kernel. Got this: "failed to detect overwritten pte: is more PTE spray needed? pmd: 00000000cafebabe"

Unroll0201 3y ago

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.

amne 3y ago

Dodged it! 5.10.184-175.749.amzn2.x86_64 #1 SMP

mtlynch 3y ago

It looks like this repo is redistributing source from third-party libraries without required license notices.[0] You should put the license notices at the root of your ./include directories to respect the work of the libraries you're using. [0] https://github.com/Notselwyn/CVE-2024-1086/issues/1 https://github.com/Notselwyn/CVE-2024-1086/issues/1

Unroll0201 3y ago
Thanks for the notice. I will immediately fix it.
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

JonChesterfield 3y ago

Summary is netfilter has a use-after-free bug and that's sufficient to go from a normal shell to root. Bad times, nice demo

deleted 3y ago
[deleted]

okl 3y ago

Commit which introduced the problem: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0abdadcc6e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The nested switch/case with return in the default path, then expecting fall-through, looks bogus to me.

rightbyte 3y ago
Same guy? https://lwn.net/Articles/882397/ https://lwn.net/Articles/882397/
- pphysch 3y ago
  > I would encourage you to read up on details of McHardy’s practices. They were clearly not done in good faith and there was no attempt to encourage compliance. The only goal was to extract as much money as possible even if the violations were more technical or incidental in nature and the companies willing to attempt remedy. Even minor and unintentional violations were pursued zealously without interest in remedy - just cash. > My understanding is he also didn’t truly prioritize deep pocketed violators (no suit against VMWare, afaik) - he prioritized that delicious sweet spot of “deep enough to pay me off, but too small to make it realistic to fight me in court”. And, again, he was uninterested in remediation of even minor and unintentional violations - he wanted cash. It seems unlikely this was helping the cause of free software. Seems entirely possible that such a character would knowingly insert a backdoor to sell as a 0-day.
  - spr-alex 3y ago
    this code was written before unprivileged network namespaces were much of a thing so the theory that a developer would plant a bugdoor for this is not probable. you can think of unprivileged namespaces in general as a bunch of attack surface that was previously root to kernel only and hadn't had much scrutiny. these bugs will take decades to eliminate without a rewrite of linux.
MuffinFlavored 3y ago
Your link converted to GitHub: https://github.com/torvalds/linux/commit/f342de4e2f33e0e39165d8639387aa6c19dff660 https://github.com/torvalds/linux/commit/f342de4e2f33e0e3916... https://bugs.launchpad.net/bugs/cve/2024-1086 https://bugs.launchpad.net/bugs/cve/2024-1086 > A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

cschmid 3y ago

For anyone who's wondering, you can see your current kernel config in a file like /boot/config or /proc/config.gz

yjftsjthsd-h 3y ago

I think it's misleading to label this "Debian/Ubuntu privilege escalation"; it's a Linux kernel local exploit, that happens to be confirmed to apply to Debian and Ubuntu. (Edit: Because when I read "Debian/Ubuntu privilege escalation PoC exploit for CVE-2024-1086" my first thought was something like, "Oh, is it in apt-get? Or is this another distro patch gone wrong?")

KennyBlanken 3y ago
[flagged]
- jvanderbot 3y ago
  > Don't criticize a title based on a barely-15-seconds-examination of something. Suggest removing this, it's overly-reproachful and GP comment be explained by being less knowledgeable, busy, under-caffeinated, etc. Your comment is highly informative for those who had similar thoughts - no reason to make it negative in nature.
  - KennyBlanken 3y ago
    [flagged]
    - jvanderbot 3y ago
      You are free to attempt to enforce a price-of-admission to comment. I attempt to use the up/down vote to filter rather than reproach. I feel it's more in the spirit of HN. I appreciate you providing context to your thought process, and I am only doing so similarly for transparency. I think we can politely disagree about approach and go on our way now. Have a good day!
- dang 3y ago
  If you keep posting personal attacks, we're going to have to ban you. I don't want to ban you—you're a knowledgeable user who has posted good things. But we've warned you a whole bunch of times already, the slack can't be infinite, and no amount of good comments makes it ok to repeatedly poison the well. https://news.ycombinator.com/item?id=39111764 https://news.ycombinator.com/item?id=39111764 (Jan 2024) https://news.ycombinator.com/item?id=35416693 https://news.ycombinator.com/item?id=35416693 (April 2023) https://news.ycombinator.com/item?id=34606566 https://news.ycombinator.com/item?id=34606566 (Feb 2023) https://news.ycombinator.com/item?id=33292588 https://news.ycombinator.com/item?id=33292588 (Oct 2022) https://news.ycombinator.com/item?id=32729960 https://news.ycombinator.com/item?id=32729960 (Sept 2022) https://news.ycombinator.com/item?id=32729939 https://news.ycombinator.com/item?id=32729939 (Sept 2022) https://news.ycombinator.com/item?id=31842940 https://news.ycombinator.com/item?id=31842940 (June 2022) https://news.ycombinator.com/item?id=30436952 https://news.ycombinator.com/item?id=30436952 (Feb 2022) https://news.ycombinator.com/item?id=30433141 https://news.ycombinator.com/item?id=30433141 (Feb 2022) https://news.ycombinator.com/item?id=28948931 https://news.ycombinator.com/item?id=28948931 (Oct 2021) If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

rakejake 3y ago

Running Ubuntu with Kernel 6.5.0-26 Got this? failed to detect overwritten pte: is more PTE spray needed? pmd: 00000000cafebabe

Unroll0201 3y ago
This is indeed expected. I specified in the "Caveats" section in README.md that the exploit does not work on Ubuntu v6.5 (because it enables a certain kernel config value that indirectly mitigates the exploit starting from v6.4), and may not work on other kernels above v6.4 depending on the config.
- rakejake 3y ago
  Ah I read that versions upto v6.6 were affected and didn't notice the caveats. Thanks

loudmax 3y ago

This exploit relies on unprivileged access to user namespaces: `sysctl kernel.unprivileged_userns_clone = 1` This is the default setting for Debian/Ubuntu, and also Arch Linux kernels. If you don't have a need for that setting, (eg. running Docker commands without sudo), you should probably disable that anyway.

yjftsjthsd-h 3y ago
:\ It really is unfortunate that that setting is great for letting people run containers (and the like) without giving them root access... but also has a bad track record of then having vulnerabilities that allow root access.
- dathinab 3y ago
  IMHO it is just too complicated/flexible designed.
  - yjftsjthsd-h 3y ago
    I'm not a kernel developer so take with a grain of salt; what I've heard suggested is that it's not fundamentally bad and if we'd had it from day one it would be fine, but a lot of kernel interfaces were designed with the idea that only root could use them so they didn't worry about certain security matters as much. And maybe that was never ideal but it could even be reasonable; if only root can trigger a bug that gives you root access... it's not good because it could be used to work around other restrictions, but one can imagine that it wouldn't exactly be a priority. But then what actually happened is that very late in the game we got this new feature that allows any old user to access these less-protected interfaces, and that's resulted in a certain amount of... catching up.
dathinab 3y ago
It's not just used by docker/packman. But also e.g. by the chrome sandbox used by e.g. electron apps (or e.g. 1password). Through that sandbox helper binary can also work with being a suid program. I also wouldn't be too surprised if e.g. proton will start using user namspaces at some point in the future. So for any non-hardened desktop linux system you probably should _not_ disable it! (For many servers or special hardened Linux it often isn't a bad idea to disable it.)

tryauuum 3y ago

why are unprivilged user namespaces enabled by default? why by default give user the ability to run iptables and other stuff (mount?) (even though it runs in an "unprivilged" namespace)

yjftsjthsd-h 3y ago
Because if they didn't keep having bugs like this, they'd be a great security feature. Like, it'd be great if running flatpaks didn't require a suid binary on the host in order to isolate apps.
_factor 3y ago
The issue is the “just works” philosophy. Most defaults are insecure and require technical expertise and hardening.
kentonv 3y ago
Unprivileged user namespaces make it possible for unprivileged programs to set up sandboxes. For example, Chrome uses namespaces to implement its process sandbox. However, Chrome installs a setuid-root binary, so that it doesn't need "unpriveleged" namespaces enabled. This is sad, though: setuid-root binaries are inherently a security risk of their own. It would be nice if Chrome did not need to install a suid-root binary. But, it can only possibly avoid this in the future if unprivileged user namespaces are widely available. Bugs like this unfortunately delay that future. Incidentally, programs like Chrome that set up namespace-based sandbox also commonly use seccomp to prevent the sandboxed code from using exotic kernel features -- including namespaces. So user namespaces won't be available to sandboxed code regardless of whether you enable unprivileged user namespaces at the system level. Personally I feel that on a single-user desktop, there's little point in enforcing a separation between users and root -- everything interesting is probably available to your user account anyway. But sandboxes like Chrome's are obviously essential to security on desktops. So I'd tend to say, on a single-user desktop, enabling unprivileged user namespaces improves security overall, by encouraging the use of sandboxes. Multi-user systems are a different story, obviously.
- dathinab 3y ago

wiredfool 3y ago

According to ubuntu -- It hits all LTS releases, and is fixed in current patched kernels: (https://ubuntu.com/security/CVE-2024-1086 https://ubuntu.com/security/CVE-2024-1086) * Focal: 5.4.0-174.193 * Jammy: 5.15.0-101.111 * Mantic: 6.5.0-26.26 As well as Xenial and Bionic for those of you with extended support

whoopdedo 3y ago

Does this still work if you have user namespace covered by AppArmor? https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 https://discourse.ubuntu.com/t/spec-unprivileged-user-namesp...

bhaney 3y ago

Tried running it on a vulnerable Debian system of mine. Didn't privesc, but did lock up the entire system on the second run (first run just failed entirely). So still definitely worth taking the time to patch.

pqdbr 3y ago

How do I check if my Ubuntu kernel has already been patched? And if it hasn’t, any tips on how to upgrade?

popol12 3y ago
sudo apt-get install musl-tools git clone https://github.com/Notselwyn/CVE-2024-1086 https://github.com/Notselwyn/CVE-2024-1086 cd CVE-2024-1086 /disable your wifi (the author says it's increasing chances of the exploit working)/ ./exploit If it runs till the end, then you should update your kernel
- caseyf 3y ago
  little warning for others - i tested it on a jammy box with kernel.unprivileged_userns_clone = 0 and it froze up good
wiredfool 3y ago
https://ubuntu.com/security/CVE-2024-1086 https://ubuntu.com/security/CVE-2024-1086 There's a super long list there, but most everything has been updated or superceded. The standard (updated) kernels are: * Focal: 5.4.0-174.193 * Jammy: 5.15.0-101.111 * Mantic: 6.5.0-26.26 And if you haven't updated, apt-get update && apt-get dist-upgrade.
- RVRX 3y ago
  Can you help me with reading that page? What's the difference between the `linux-kvm` vs `linux-hwe-6.5`? They both list different release fixes for Jammy, 5.15.0-101.111 and 6.5.0-26.26 respectively. Edit: Oh it looks like the generic kernel is the one named just "linux" and also has 5.15.0... as the patched version on Jammy
  - wiredfool 3y ago
    FWIW, hwe is hardware enablement, so bleeding edge kernel on older distro. KVM is specifically focused on KVM virtual machines.

andy_xor_andrew 3y ago

I have some questions for you wizard shellcode-flinging hackers out there. with modern mitigations like ASLR and beyond, how are exploits like this even possible? I took a course in college which provided us with a dozen binaries, to be run on a specific Ubuntu version. Each binary had a different bug, use-after-free, buffer overflow, both, or more, and our task was to exploit it.[0] It was HARD. Finding the flaw was hard. Then, writing the exact correct shellcode to do something useful with the flaw was even harder. Especially when you only have the compiled binary and GDB to work with. In harder levels, we had to do this with mitigations enabled like ASLR, stack canaries, etc. And my takeaway was, this is nearly impossible, because you need to 1. discover an exploitable flaw (or multiple, and chain them together!!) 2. find the exact binary shellcode payload that will do something useful without simply crashing the executable. And this was in a controlled environment as students, not the real world which is even more difficult. So my question is, with all these mitigations, how is it possible?! [0] I googled for the exact project but could not find it, though it was very very similar to this: https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/assign6/ https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/a...

4gotunameagain 3y ago
There's an entire section about KASLR in the blogpost linked on the repository.
freedomben 3y ago
short answer: some people are good, some people are lucky, and some people are good and lucky. It only takes one from the latter category to find these things longer answer: It is definitely really damn hard these days. Even disabling the mitigations, it's still pretty hard to find and a vuln and write an exploit. But many people who find these (not all though) work as part of a team, where they can parallelize fuzzing efforts and combine/chain knowledge and other exploits much better than an individual could. The level of expertise and talent that some of these people have is absolutely incredible, and experience is worth a pound of gold for these types of things, and some people have years or decades of experience.
jimmyl02 3y ago

dang 3y ago

Url changed from https://github.com/Notselwyn/CVE-2024-1086 https://github.com/Notselwyn/CVE-2024-1086, which points to this.

Unroll0201 3y ago
Is there a reason why you did this? I knowingly chose the other title because it would apply more to the Hackernews audience to raise more awareness of the exploit and that people should update. This title was aimed at the Linux kernel VR community, which also shows because the post instantly dropped down from a 2-hour #1 position to #8
- dang 3y ago
  The title generated complaints: https://news.ycombinator.com/item?id=39829308 https://news.ycombinator.com/item?id=39829308. In such cases we usually change the title (experience has shown this to be the best way to turn discussion away from title complaints to whatever the more interesting topic is). In doing that, I noticed that the blog post includes a lot more background than the github link, so I switched the URL as well.

deleted 3y ago

[deleted]

freedomben 3y ago

This is an extremely impressive write-up. When writing security blog posts, there's always a constant battle of essentially "how much background/prerequisite knowledge do I assume," and getting the balance right to make it accessible but also feasible to write can be very challenging. Identifying your target market up front, and then delivering to that market with plenty of background info, is no easy feat! Well done! I'm bookmarking this to give to aspiring researchers, of whom I meet a few every year who are looking for guidance like this.

Unroll0201 3y ago
Thank you so much! It feels great to hear this.

bakkoting 3y ago

From the patch [1]: > This reverts commit e0abdadcc6e1. [...] Its not clear to me why this commit was made. Anyone dug up the history here? [1] https://lore.kernel.org/all/20240120215012.129529-1-fw@strlen.de/ https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...

tg180 3y ago
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0abdadcc6e1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... > netfilter: nf_tables: accept QUEUE/DROP verdict parameters > Allow userspace to specify the queue number or the errno code for QUEUE and DROP verdicts.
- loeg 3y ago
  Yeah, but why?
  - rokkitmensch 3y ago
    If one has to ask, it's a Five Eyes plant.
    - aseipp 3y ago
      Hardly. This is just a typical double free vulnerability, AKA a normal Tuesday in the C/C++ world, and which people have been exploiting in the kernel (with its complex object lifetimes and semantics) for well over 10 years now. There's no need to "plant" anything to find these.
      - rokkitmensch 3y ago
        Which makes it a fine cover!
aseipp 3y ago
The original commit is over 10 years old now, so it's probably lost to the sands of time. I did some looking but couldn't find anything on the old netdev lists. Maybe the patch was sent directly to Pablo Neira Ayuso, the committer. It was part of a series so it's not like it was a one-off patch. In a strange twist of fate, the original author was Patrick McHardy who is now a persona non grata. Unless Pablo can remember or dig it from his emails, it probably won't ever be clear exactly what the use case was, at least not through basic investigation.

jcalvinowens 3y ago

Distros don't build with it, but CONFIG_INIT_ON_FREE_DEFAULT_ON prevents the exploit. I think it's a nice demonstration of the value of the hardening in the kernel.

1oooqooq 3y ago
this zeroes memory on every allocation and deallocation. huge perf hit
- jcalvinowens 3y ago
  Zeroing on allocation is almost free. You can invent microbenchmarks where it hurts, but for most workloads it doesn't matter. You can also invent micro cases where it is beneficial, because the cache is hot after the zeroing. The always kernel zeros all userspace allocations, and always has. In a former life, I actually tested this on an x86 webserver workload: the overhead of zeroing on allocation on CPUs that were Ivy Bridge or newer was so small it was literally impossible to measure in high-level web metrics. Sandy Bridge took a 1-2% hit in request throughput as I recall. Zeroing on free is a different story though, that trashes the cache.

FergusArgyll 3y ago

I just tried this on WSL Ubuntu (after an apt update && upgrade), Completely freaked my computer out, I almost thought I bricked it but a restart worked. I'm not smart enough to understand it but someone may want to look into it

mise_en_place 3y ago

Oof, double free is one of those notorious bugs. And to think it comes from something as innocuous as netfilter rules.