6 ms·
"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
by l33tman 3y ago
"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.
- thelastparadise 3y agoI don't think the bug itself is newsworthy. The existence of the exploit code, and the way that it was accidentally published, I think are.
- pizzalife 3y agoIt's exploitable by an unprivileged user on the most popular distro out there (Ubuntu). I would say it's newsworthy.
- hsbauauvhabzb 3y agoWhat’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)
- sp332 3y agoOdds 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.
- j_walter 3y agoOnce 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.
- hsbauauvhabzb 3y agoSo we lower the bar to all adversaries with no benefit? If you can read exploit code to determine if patching is worth it for your use case, you can probably also read diffs for the same outcome. I’m not saying don’t release them, but releasing them with short notice seems irresponsible, without much benefit to defenders.
- ikiris 3y agoThe link to the exploit accidentally went public. Anyone can have it.
- pizzalife 3y ago> 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:~% lsmod|grep nf_table ubuntu:~% unshare -U -m -n -r ubuntu:~% nft add table inet filter ubuntu:~% lsmod|grep nf_table nf_tables 249856 0
- veonik 3y agoYikes... are other popular distros shipping with unprivileged user namespaces enabled by default?
- galangalalgol 3y agoThat is part of enabling rootless containers on rhel or similar.
- waynesonfire 3y agoshould have re-written it in rust.
- yjftsjthsd-h 3y agoRewritten 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.
- scns 3y agoThe good old Strangler Pattern. https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
- candiddevmike 3y agoWhat 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.
- krastanov 3y agoThe thing is already in the wild because someone on the private mailing list already accidentally mailed it to the public mailing list.
- chasil 3y agoYou have a few options for dealing with problems like this. You can "apt update; apt upgrade" then reboot when a new kernel is available. Oracle has also offered Ksplice for free on Ubuntu for many years, and I'm sure that patch will be available promptly. https://ksplice.oracle.com/try/desktop https://ksplice.oracle.com/try/desktop Otherwise, Kernelcare is available for a fee. I think Canonical also has paid kernel patches.
- withinboredom 3y agoThere is Ubuntu Pro which is free for up to five servers/desktops, after that, it requires a paid subscription.
- jstanley 3y ago> 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.
- failsecure 3y agoMaybe 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.
- jstanley 3y agoThat's fine. They didn't want it on linux-distros anyway!
- batch12 3y agoMaybe 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 https://oss-security.openwall.org/wiki/mailing-lists/distros
- amatecha 3y agoI believe they are referring to this: https://oss-security.openwall.org/wiki/mailing-lists/distros 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.