"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 <security () kernel org> to assist with fix development.
Somebody from the Linux kernel team then emailed the proposed fix to
<linux-distros () vs openwall org> 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, I intend to publish both the description of exploitation
techniques and also the exploit source code on Monday 15th by email to
this list."
Interesting.. they didn't write what conditions have to be met for it to be exploitable. Also interesting that someone screwed up and accidentally forwarded an email including the exploit to a broad mailing list...
Part of the nf modules are active if you have iptables, which you have if you run ufw (for example), so pretty broad exploit if that's all that's required, 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.
> 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.
For comparison, on my Debian Bookworm (aka "testing" but in hard freeze and full freeze in a few days I think, stable release in june) here...
...$ lsmod|grep nf_table (tried without any just to make sure)
...$ unshare -U -m -n -r
unshare: unshare: failed: Operation not permitted
...$ /sbin/nft add table inet filter
Error: Could not process rule: Operation not permitted
add table inet filter
^^^^^^^^^^^^^^^^^^^^^^
root # cat /proc/sys/kernel/unprivileged_userns_clone
0
Most, I think Debian has patch to be disabled at runtime via sysctl. The reason is that most containers or sandboxing techniques are root only unless you mix it with user namescapes. So most container or sandbox software use suid(firejail) , root daemon(docker) or user namescapes (podman and flatpak). Looking at the cves, user namespaces is probably the safer option
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.
Some of the issue though is that a monolithic kernel provides more access than necessary to many things. When they made the locks granular, those might be reasonable boundaries for permissions? At this point I'd rather figure out how to make windows drivers work in redox or something crazy like that.
> Somebody from the Linux kernel team then emailed the proposed fix to <linux-distros () vs openwall org> 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.
> 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.
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.
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.
Once they issue the patch...it's only a matter of time till a good chunk of reasonably decent coders can develop the exploit. Once the premise is released...yeah the top exploit coders will have this in a few hours.
What a dumb policy. Why have the disclosure time be so soon? This thing will be in the wild before folks can upgrade if I'm understanding this correctly.
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, I intend to publish both the description of exploitation techniques and also the exploit source code on Monday 15th by email to this list."
Interesting.. they didn't write what conditions have to be met for it to be exploitable. Also interesting that someone screwed up and accidentally forwarded an email including the exploit to a broad mailing list...
Part of the nf modules are active if you have iptables, which you have if you run ufw (for example), so pretty broad exploit if that's all that's required, 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.