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!

https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...

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?

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.

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>.

?

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

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.

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.

LXC containers and privileged Docker containers allow these namespaces to be made inside of them, whilst unprivileged Docker containers do not.

> 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@strle...

> netfilter: nf_tables: accept QUEUE/DROP verdict parameters

> Allow userspace to specify the queue number or the errno code for QUEUE and DROP verdicts.

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.

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.

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.

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.)

the problem is that containers require tons of hacks on the network side to just-work. and docker main selling point is all the usafe hacks it does for it.

so obviously, any container solution will adopt these hacks eventually, and there is the problem.

you end up with a perfectly sane namespace functionality that removes access, but then the kernel opens the gate because network hacks are good

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.

Electron apps too (if sandboxing is enabled).

Bubblewrap (used by flatpack, idk. about snap) prefers user namespaces, too.

All of them could can have suid fallbacks they would prefer to not have.

Tbh. if Linux had a proper capability system it probably would make sense to attach a "user ns" capability to binaries which in the past used suid-root for namespaces and not allow "other" processes to use it.

> there's little point in enforcing a separation between users and root

I don't agree. But it is a different discussion. (And a complicated discussion too as Linux desktop is IMHO currently lacking in various security areas as security requirements have changed. So often when you argue they should do this you get non productive answers like "oh but you also could do [that other think which also need to change sooner or later]". Anyway it can make the difference between it being easily able to steal all password from your password manager and it only being able to steal the passwords you did use since infection. Or it being able to steel a early boot full disk encryption key. etc. etc.)

* The mechanism for granting capabilities to binaries is convoluted, requiring special tools, filesystem support, and fiddly code. It's surprisingly tedious to make it work.

* There's no specific capability for user namespaces. When they require privileges at all, they require CAP_SYS_ADMIN. This capability is basically equivalent to root anyway. In fact, many Linux capabilities can easily be escalated to full root privileges.

My personal opinion is that Linux "capabilities" are not worth using most of the time. (I also hate that they are called "capabilities", a word that I would rather reserve for object-capabilities, which are an actually-useful security model!)

I agree but I don't think that's fundamental. It's pointless on Linux because any attacker can simply alias `sudo` to something and wait.

But I can imagine a modern desktop OS where there's a useful admin account. Windows is pretty close. Much better than Linux on that front.

Of course, such a platform basically exists: the web platform.

I think everything-is-a-web-site is the realistic way we get to secure desktops. I don't like it but it's hard to imagine anything else getting traction from here.

If a Chrome bug is found that allows web pages to arbitrary code execution, it can be chained with an exploit like this to infect more than just the user account, potentially, depending on the computer, the firmware itself.

For normal botnet/cryptocurrency stealing malware once it has user access it has everything it needs.

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/a...

Just think of the gap between the first time in the woodworking shop and a carpenter, first time pottery versus a master, a new painter and a professional artist. Think of how many things the master can do that it is literally impossible for the new person to do. Then add another 10-100x as much time on that. That is the gap.

[1] https://zerodium.com/program.html

> a generic Linux LPE pays 50 K$. At normal experienced exploit developer costs that buys you ~200 person-hours.

$250 per hour? I must be living in the wrong part of the world then, where can find an exploit developer job like this :o

there are "classic" techniques to bypass most of the modern protections and if there isn't then researchers often come up with novel attacks / bypasses. for example for heap protections you can see how2heap to bypass heap protections[0]. another example is an exploit which allows bypass of KASLR (which has since been patched)[1]. it looks like this exploit comes up with a "dirty pagetable" technique[2].

it's always a game of cat and mouse with more mitigations always being added while researchers constantly look to bypass them.

[0] https://github.com/shellphish/how2heap

[1] https://www.willsroot.io/2022/12/entrybleed.html

[2] https://pwning.tech/nftables/#452-the-technique

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.

But when you consider that major bugs found now are being found by well funded teams or state actors trying to exploit them, it makes more sense that they would be able to work around existing mitigations due to the sheer manpower and resources they have to throw at the problem.

  * Focal: 5.4.0-174.193
  * Jammy: 5.15.0-101.111
  * Mantic: 6.5.0-26.26

https://discourse.ubuntu.com/t/spec-unprivileged-user-namesp...

I'm not smart enough to understand it but someone may want to look into it

failed to detect overwritten pte: is more PTE spray needed? pmd: 00000000cafebabe

And if it hasn’t, any tips on how to upgrade?

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

git clone 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

The nested switch/case with return in the default path, then expecting fall-through, looks bogus to me.

https://lwn.net/Articles/882397/

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.

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.

(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?")

> The exploit does not work v6.4> kernels with kconfig CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y (including Ubuntu v6.5)

> The exploits requires user namespaces (kconfig CONFIG_USER_NS=y), that those user namespaces are unprivileged (sh command sysctl kernel.unprivileged_userns_clone = 1), and that nf_tables is enabled (kconfig CONFIG_NF_TABLES=y). By default, these are all enabled on Debian, Ubuntu, and KernelCTF. Other distro's have not been tested, but may work as well.

Also with other distros like Fedora and Arch, the kernel versions change frequently including new big versions (like 6.4 to 6.5, what in semver would be called "minor" but isn't super accurate for the linux kernel) so that list would be outdated very quickly if not immediately (for example my Fedora machine right now is on kernel 6.7.9, way beyond what is vulnerable). It's quite possible that Ubuntu is the only vulnerable distro given the way they manage kernel versions. That's not a criticism of Ubuntu, because there are pros and cons of each approach, but in this case it does probably make Ubuntu more vulnerable. RHEL and derivatives also tend to stick on a version long term, and it looks like RHEL 9.3 is on kernel 5.14 so could be vulnerable but it's at the very beginning of the range. That would be a useful thing to know.

I think it's also (generally) far more useful for most people to hear a descriptor that most closely aligns with something they can readily identify whether it affects them or not. Then people can look at the details themselves.

Edit: added a little more on other distros like Fedora and Arch

True; if the Debian family is unusual in having that config then fair enough, but it sounds like the author just didn't look at others.

> Also with other distros like Fedora and Arch, the kernel versions change frequently including new big versions (like 6.4 to 6.5, what in semver would be called "minor" but isn't super accurate for the linux kernel) so that list would be outdated very quickly if not immediately

Debian/Ubuntu still roll patch releases regularly, so that seems irrelevant; it'll be out of date in short order regardless.

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

5.10.184-175.749.amzn2.x86_64 #1 SMP