Live data from Hacker News

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

seclists.org

41–50 of 107 posts

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

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

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.

For rack servers you could probably get away with a number of microkernel os today. Desktop has clear options in that regard, but you are giving up op n source.

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

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

Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.

What's the alternative, just running all code at ring 0?

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

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

It won't make that big of a difference. If you exploit the networking layer you could intercept any local traffic, which will mostly be unencrypted, and communicate with outside attackers. You are probably owned by that point unless you treated localhost as untrusted.

It's like why it doesn't matter if you are running as root or not. The user account has access to whats important, like a database or keychain.

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

#44
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 mailing list, and this somehow creates an obligation on you to follow that mailing list's policies? I don't get it.

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

#45
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…

Maybe linux-distros has a poc or GTFO rule in place to keep the unchecked "I can get root on your box with this one weird trick but I won't tell you how" emails to a minimum. Just a guess though.

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

#46
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…

Maybe they consider the exploit is in the wild when sending to a distro that large[0] with recipients that aren't provably trustworthy.

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

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

#47
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?

Yes and this decision haunts distros like Ubuntu over and over again. There's no easy win though.

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

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

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.

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

#49
post #2

Glad to have sticked with the good old iptables and left CONFIG_NF_TABLES unset in kernel configuration.

Aren't iptables just an emulation layer on top of netfilter?

For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.

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

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

Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.

I’ve been thinking this recently as well.
Post reply on HN