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.
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 ...$ 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
0Edit: should've read better, this seems to need CLONE_NEWUSER.
> 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.
[0] 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.
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
Otherwise, Kernelcare is available for a fee. I think Canonical also has paid kernel patches.
"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"
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.
Hypervisors, userspace drivers, containers, language runtime sandboxes, bytecode deployments, driver and kernel sandboxes (safe kernel / driver guard),container only distributions,...
If you can CI/CD in minutes a reduced kernel+app and reboot in 100ms your network-facing thing (be it nginx or haproxy) you might just take latest vanilla anyway...
How would we go about GPUs, NCs, and many kinds of drivers?
My desktop, on which I am the only person with an account, has 49 "users", of which 11 are actively running a process.
At work, every daemon we run has a dedicated user.
On android, every app runs as its own user.
I'd be very interested to hear how this can be done by an unprivileged user.
Try to race set add/removals, sure, but if it depends on the set itself getting deleted, that seems… harder.
Which is the default on Ubuntu.
The NIST CVE page points back here. Funny.
Nothing I see so far specifically says how far back this goes, but, https://security-tracker.debian.org/tracker/CVE-2023-32233
Seems to go back really far.
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.
Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.
struct foo *whatever = new_foo();
// use 'whatever'
free_foo(whatever);
if (whatever->did_something) {
log_message("The whatever did something.");
}
// never use 'whatever' after this point
For use-after-free to be exploitable, by definition an attacker must be able to put arbitrary content at the memory region. This is not always easy: may require certain [mis]configuration, data layout and so on.
> practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.
I will not contest this claim, however there is a difference between "blow up" and "exploit". Malicious packet being able to segfault a server is one thing, malicious packet resulting in RCE is quite another. This may be a lost in translation moment when under colloquial use "exploit" does not include DoS.
https://github.com/igo95862/bubblejail
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.
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.
If it says (nf_tables), you are using the compatibility layer from the iptables-nft package.
It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules.
It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using nft list ruleset.
The problem is that it works so well that it seems most users just stayed with the iptables syntax and did not bother migrating at all.
priv->set->use++;
nf_tables_activate_set(ctx, priv->set);
void nf_tables_activate_set(const struct nft_ctx *ctx, struct nft_set *set) {
if (nft_set_is_anonymous(set))
nft_clear(ctx->net, set);
set->use++;
}