"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.<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, I intend to publish both the description of exploitation
techniques and also the exploit source code on Monday 15th by email to
this list."<p>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...<p>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.
Based on this 11 month old discussion this has been an exploit vector for sometime - <a href="https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3DR5w" rel="nofollow">https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3...</a><p>"I vaguely recall at least around 6-7 such holes, and a quick google
search seems to reveal that at least those would have been mitigated
by unprivileged user namespaces being disabled:
CVE-2019-18198
CVE-2020-14386
CVE-2022-0185
CVE-2022-24122
CVE-2022-25636
CVE-2022-1966 resp. CVE-2022-32250"
There's easily thousands of such bugs hidden in the kernel.<p>Reminder the kernel has over ten million LoCs, or megabytes of object code.<p>Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges.<p>I wouldn't say it is sensible in a world where seL4 exists.
> delete an existing nft rule that uses an nft anonymous set. And an example of the latter operation is an attempt to delete an element from that nft anonymous set after the set gets
deleted<p>I'd be very interested to hear how this can be done by an unprivileged user.<p>Try to race set add/removals, sure, but if it depends on the set itself getting deleted, that seems… harder.
<a href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2023-32233</a><p>The NIST CVE page points back here. Funny.<p>Nothing I see so far specifically says how far back this goes, but, <a href="https://security-tracker.debian.org/tracker/CVE-2023-32233" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2023-32233</a><p>Seems to go back really far.
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.<p>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.
I am developing a sandbox project for Linux desktop applications called bubblejail:<p><a href="https://github.com/igo95862/bubblejail">https://github.com/igo95862/bubblejail</a><p>In the next not yet released version 0.8.0 there will be a new option to disable a specific namespace type per sandbox. For example, disabling the network namespace would prevent this exploit.<p>This is more flexible than globally disabling all user namespaces as some programs might use other more harmless namespaces like Steam uses mount namespaces to setup runtime libraries.