return to table of content

Flipping Pages: New Linux vulnerability in nf_tables and exploitation techniques

Unroll0201
26 replies
1d3h

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!

cedws
9 replies
1d1h

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
4 replies
1d1h

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.

londons_explore
2 replies
22h29m

Governments only say they don't work with criminals.

redundantly
0 replies
20h50m

Government officials are often criminals themselves.

okasaki
0 replies
13h0m

Or the company is lying. It's not like anyone can check.

streb-lo
0 replies
1d1h

clear evidence

evidence is not what someone writes on their landing page

Unroll0201
2 replies
1d

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

ok_dad
0 replies
19h1m

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.

buggeryorkshire
0 replies
7h16m

Thank you, appreciated.

caskstrength
0 replies
23h10m

You are being downvoted, but as an outside observer I have also always been interested in ethics of security research.

pelagicAustral
6 replies
1d3h

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

richardwhiuk
3 replies
1d3h

This is local privilege escalation only right?

Unroll0201
2 replies
1d2h

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
1 replies
1d2h

if it works for LXC containers shouldn't it also work for unprivileged (but non VM) docker containers?

Unroll0201
0 replies
1d

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
1 replies
1d2h

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
0 replies
14h39m

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.

greggsy
2 replies
1d3h

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

Unroll0201
0 replies
1d2h

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
0 replies
1d2h

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.

yjftsjthsd-h
1 replies
1d2h

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
0 replies
1d2h

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.

rfoo
0 replies
23h33m

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?

dev_snd
0 replies
1d3h

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

derelicta
0 replies
1d3h

Congrats! Impressive work!

tryauuum
11 replies
1d2h

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)

kentonv
8 replies
1d2h

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.

IshKebab
4 replies
1d

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

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.

PlutoIsAPlanet
2 replies
1d

Even on a Linux desktop OS with a single user, it's still a security risk as it skips over a last line of defence.

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.

IshKebab
1 replies
19h41m

Sure but most malware doesn't really care about infecting more than the user. The only reason to infect firmware is to gain persistence in the face of OS reinstalls, but those are very rare in general. Only targeted NSA level malware is going to bother with that.

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

Manouchehri
0 replies
16h49m

If you're able to throw a 0day at a target, there's nothing stopping you from throwing it again after they reinstall.

kentonv
0 replies
22h50m

Yes, I agree. But I don't think the path forward is to re-establish the security of root. Instead the path forward is to stop granting the full capabilities of the user to every program the user runs. In Android, for example, every app has its own user account. That is meaningful! I wish every desktop app were sandboxed by default, but it requires redesigning so many interfaces that you might as well think of it as a whole new platform.

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.

jiripospisil
1 replies
1d

Is there a reason why user namespaces cannot be enabled per executable? setcap "something something user ns" /usr/bin/chrome?

kentonv
0 replies
22h57m

In theory that might work. In practice, it doesn't help much; you might as well stick with setuid-root.

* 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!)

dathinab
0 replies
1d1h

Chromes sandbox uses unprivileged namespaces but has a suid-root fallback.

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

yjftsjthsd-h
0 replies
1d2h

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
0 replies
1d2h

The issue is the “just works” philosophy. Most defaults are insecure and require technical expertise and hardening.

andy_xor_andrew
10 replies
1d1h

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

Veserv
5 replies
1d

You were a inexperienced beginner finding and exploiting tens of bugs over a 10-15 week course. In between other courses and learning you only had hours to maybe a few days per bug. On Zerodium [1], a generic Linux LPE pays 50 K$. At normal experienced exploit developer costs that buys you ~200 person-hours. That is professionals spending 10-100x as much time as you spent.

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

rfoo
3 replies
23h41m

It makes your point even stronger, but

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

bawolff
1 replies
23h7m

I don't work in that space, so i don't know what is normal, but that sounds reasonable to me. Its a niche field that requires quite a bit of low level skill. I'd expect it to pay significantly more than web dev jobs

buggeryorkshire
0 replies
9h42m

They pay more than that in certain parts of the UK and US - didn't do it myself, but know people who did and they were definitely in demand.

Veserv
0 replies
22h50m

Costs, not salary. Overhead is usually 1.5x-3x salary and I was throwing in some profit for good measure. So the number I threw out is more in the 150 k$-300 k$ range, not the 500 k$ range like you are thinking.

Manouchehri
0 replies
16h45m

I went from having previously written 0 exploits (aside from IoT fails with command injection), to my first Chrome exploit in about 15 weeks. I did probably put in about 1,000 hours though.

robotnikman
0 replies
20h32m

I've wondered this myself. I've tried a class similar to yours, where you were provided with binaries and tried to find the bugs in them. And it was hard.

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.

jimmyl02
0 replies
1d1h

modern mitigations have made exploits much more difficult, however researchers continue to find bypasses to these mitigations.

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

freedomben
0 replies
1d1h

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.

4gotunameagain
0 replies
1d1h

There's an entire section about KASLR in the blogpost linked on the repository.

loudmax
9 replies
1d2h

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
2 replies
1d2h

:\ 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
1 replies
1d1h

IMHO it is just too complicated/flexible designed.

yjftsjthsd-h
0 replies
1d

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.

aidenn0
2 replies
21h34m

6.1.65 and that option doesn't exist. Did it get renamed?

bjackman
0 replies
20h5m

I don't think it's in the upstream kernel - various distros carry it as a patch. Maybe yours doesn't?

Unroll0201
0 replies
20h20m

The sysctl command isn't available on specific kernel configurations. You could try running `unshare -Urn`. If it runs without sudo (and you haven't configured any specific permissions yourself), unprivileged namespaces are enabled.

1oooqooq
1 replies
10h30m

the real problem is not that. this is nothing but a way to DROP privilege!

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

GoblinSlayer
0 replies
6h17m

AIU the cause is Netfilter API that doesn't sanitize its input, because only root can call it, so there is no need to sanitize. Then unprivileged user namespaces open all root API to unprivileged user, so nonsanitizing Netfilter API became available to unprivileged user.

dathinab
0 replies
1d1h

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

yjftsjthsd-h
8 replies
1d2h

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

wiredfool
3 replies
1d2h

Also, it's already been patched and the vulnerable are the ones who haven't updated.

pajko
1 replies
1d1h

The world was given a pretty short time frame to adapt. Now the script kiddies will unleash the hell.

eikenberry
0 replies
1d

It was patched a month and a half ago which means it was known about before that. So around 30ish days known until the CVE and 60 until this published exploit. IMO this is a decent time frame, how long do you think is enough?

krylon
0 replies
1d1h

Thanks for pointing that out, I was confused about that.

freedomben
2 replies
1d1h

You're not necessarily wrong, although simply saying "Linux" isn't accurate either because it's in part a vuln exposed by a specific kconfig, which differs by distro. From the caveats section:

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

yjftsjthsd-h
0 replies
1d

simply saying "Linux" isn't accurate either because it's in part a vuln exposed by a specific kconfig, which differs by distro

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.

candiddevmike
0 replies
1d1h

Interesting Arch discussion on the security implications of user namespaces when they were considering adding it to their kconfig: https://bugs.archlinux.org/task/36969

loeg
2 replies
22h44m

Yeah, but why?

rokkitmensch
1 replies
21h45m

If one has to ask, it's a Five Eyes plant.

aseipp
0 replies
19h46m

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.

aseipp
0 replies
19h49m

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.

pphysch
1 replies
1d

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
0 replies
23h57m

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
0 replies
1d1h

Your link converted to GitHub: https://github.com/torvalds/linux/commit/f342de4e2f33e0e3916...

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.
pqdbr
3 replies
1d1h

How do I check if my Ubuntu kernel has already been patched?

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

popol12
1 replies
1d1h

sudo apt-get install musl-tools

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

caseyf
0 replies
22h55m

little warning for others - i tested it on a jammy box with kernel.unprivileged_userns_clone = 0 and it froze up good

wiredfool
0 replies
1d

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.

rakejake
2 replies
1d2h

Running Ubuntu with Kernel 6.5.0-26 Got this?

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

Unroll0201
1 replies
1d2h

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
0 replies
1d1h

Ah I read that versions upto v6.6 were affected and didn't notice the caveats. Thanks

jcalvinowens
2 replies
1d

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
1 replies
10h25m

this zeroes memory on every allocation and deallocation. huge perf hit

jcalvinowens
0 replies
1h25m

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.

Unroll0201
1 replies
22h57m

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
0 replies
22h43m

The title generated complaints: 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.

mtlynch
1 replies
1d3h

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

Unroll0201
0 replies
1d3h

Thanks for the notice. I will immediately fix it.

freedomben
1 replies
1d1h

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
0 replies
20h20m

Thank you so much! It feels great to hear this.

XCSme
1 replies
4h41m

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.

wiredfool
0 replies
1d2h

According to ubuntu -- It hits all LTS releases, and is fixed in current patched kernels: (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

mise_en_place
0 replies
21h36m

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

cschmid
0 replies
1d2h

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

bhaney
0 replies
1d1h

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.

amne
0 replies
1d3h

Dodged it!

5.10.184-175.749.amzn2.x86_64 #1 SMP

JonChesterfield
0 replies
1d2h

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

FergusArgyll
0 replies
22h24m

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