Live data from Hacker News

Linux kernel use-after-free in Netfilter, local privilege escalation

seclists.org

61–70 of 107 posts

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#61
post #59
post #55

Earlier quoted context omitted.

> to always use smart pointers for reference counting Agree - and the Linux kernel is extremely fragile because it is full of ad-hoc manual code like that. Unfortunately, Rust won't be the rescue, because (in the foreseeable future) Rust will only be available in leaf code due to the many hard problems of transitioning from fragile C APIs to something better. Writing drivers in Rust is useful, but limits the scope of…

We’ll see. As far as I know, the biggest blocker to using Rust outside of drivers is the fact that LLVM lacks support for some architectures Linux supports. And rustc_codegen_gcc seems on track to fix that eventually; even if it takes years more, that’s not much time on the scale of Linux’s development history.

That wouldn't solve the hard problems I meant. Rust portability is an easy problem - it's clear how to port Rust to more architectures, just nobody has done it. But doing interop between Rust and C in both directions, with complicated things like RCU in between - that is a hard and complex problem.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#62
post #8

"We developed an exploit that allows unprivileged local users to start a root shell by abusing the above issue. That exploit was shared privately with to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to and that email also included a link to download our description of exploitation techniques and our exploit source code. Therefore, according to the linux-distros list p…

> Somebody from the Linux kernel team then emailed the proposed fix to and that email also included a link to download our description of exploitation techniques and our exploit source code. > Therefore, according to the linux-distros list policy, the exploit must be published within 7 days from this advisory. In order to comply with that policy, [...] What? Someone publishes information about your vuln to a random m…

I believe they are referring to this:

https://oss-security.openwall.org/wiki/mailing-lists/distros

> Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 days. Please do not ask for a longer embargo. In fact, embargo periods shorter than 7 days are preferable.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#63

Earlier quoted context omitted.

That is part of enabling rootless containers on rhel or similar.

should have re-written it in rust.

Rewritten what? The container runtime will need the same access regardless of what it's written in, and rewriting all of Linux (the kernel) would be... ambitious, although it is adopting rust incrementally.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#64
post #28

There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.

Who's going to make seL4 perform comparably to Linux?

Why would we need to slow seL4 down?

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#66
post #19

Earlier quoted context omitted.

> but the specific module in question in the patch, nf_tables, is not loaded on my Ubuntu 20.04LTS 5.40 kernel running iptables/ufw at least This doesn't matter since Linux has autoloading of most network modules, and you can cause the modules to be loaded on Ubuntu since it supports unprivileged user/net namespaces. ubuntu:~% grep DISTRIB_DESCRIPTION /etc/lsb-release DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS" ubuntu:~…

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something?

Edit: should've read better, this seems to need CLONE_NEWUSER.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#67
post #48

Earlier quoted context omitted.

Microkernel does seem the only sensible path forward. Even if the kernel is slowly rustified, going to be playing security whack-a-mole for a long time.

Linux may eventually become a microkernel with most IPC done via io_uring, but it may take 20 years to reach this state.

Right now it seems microvms are the way. Build an extremely minimal tailored kernel+userland for network-facing components. If you don't have nf_tables built-in (and it's not loadable because not present) this vulnerability isn't a problem. I mean, right now to use it one would have to chain it with a RCE on your userland app (or on the kernel but just skip the nf_tables step then...). Then one would have to escape the VM, then if you're using firecracker or crosvm, you'll have to break seccomp. Still imaginable, but by then I guess the next kernel (or userland app) fix release is already available :-) and you're already rebooting your microvm.

If you can CI/CD in minutes a reduced kernel+app and reboot in 100ms your network-facing thing (be it nginx or haproxy) you might just take latest vanilla anyway...

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#68
post #19

Earlier quoted context omitted.

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something? Edit: should've read better, this seems to need CLONE_NEWUSER.

You need CAP_SYS_ADMIN to create a new network namespace.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#69
Honest question: Why did they build an exploit that uses the bug? I always assumed that use-after-free is equivalent to "game over" (i.e. I assumed that local privilege escalation is a given) and it is clear that such a bug must be fixed.

By that I mean, it might be easy or hard to exploit a bug to achieve LPE, but it seems to be redundant to prove that it is possible.

Re: Linux kernel use-after-free in Netfilter, local privilege escalation

#70
post #27

Earlier quoted context omitted.

What’s actually reasonable here. I’m all for exploit code becoming public eventually, but I think it’s silly to drop it immediately after a fix has been released, or before, in almost all scenarios (unless there’s been 90+ days or the issue marked as wontfix)

Odds are that well-resourced attackers already have the exploit by now. Making it public lets users decide if this is important to them and come up with their own mitigations.

The link to the exploit accidentally went public. Anyone can have it.
Post reply on HN