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 kernel use-after-free in Netfilter, local privilege escalation
41–50 of 107 posts
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#42There'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.
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#43There'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'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"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…
> 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"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…
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#46"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…
[0] https://oss-security.openwall.org/wiki/mailing-lists/distros
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#47Earlier 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?
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#48There'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.
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#49Glad 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?
Re: Linux kernel use-after-free in Netfilter, local privilege escalation
#50There'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.