AlmaLinux OS - CVE-2024-1086 and XZ (AlmaLinux blog)

[Posted April 3, 2024 by jzb]

AlmaLinux has announced updated kernels for AlmaLinux 8 and 9 to address CVE-2024-1086, a use-after-free vulnerability in the kernel that could be exploited to gain local privilege escalation. This is notable because the fix marks a divergence between AlmaLinux and Red Hat Enterprise Linux (RHEL):

In January of this year, a kernel flaw was disclosed and named CVE-2024-1086. This flaw is trivially exploitable on most RHEL-equivalent systems. There are many proof-of-concept posts available now, including one from our Infrastructure team lead, Jonathan Wright (Dealing with CVE-2024-1086). In multi-user scenarios, this flaw is especially problematic.

Though this was flagged as something to be fixed in Red Hat Enterprise Linux, Red Hat has only rated this as a moderate impact.

The AlmaLinux project would also like to note that it is not impacted by the XZ backdoor. "Because enterprise Linux takes a bit longer to adopt those updates (sometimes to the chagrin of our users), the version of XZ that had the back door inserted hadn't made it further than Fedora in our ecosystem."

AlmaLinux OS - CVE-2024-1086 and XZ (AlmaLinux blog)

Posted Apr 4, 2024 21:54 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

The nftables CVE got me wondering how this might be prevented next time. If you remove cap_net_admin, it thwarts this exploit because user namespaces with fake root can no longer touch nftables. It's never that simple though or we'd already be doing it.

After doing some research and getting ready to write a whole essay about it, it turns out the libcap-ng homepage already has a pretty good primer on how to lock things down in this way on a traditional Linux system with clear diagrams, and most of what I would've said is already there. But its explanation stops short of touching login sessions (e.g. openssh/getty's process trees), and so wouldn't have protected from this.

I propose that user sessions shouldn't be given qualified immunity, and remove cap_net_admin and its friends from those too so that even a properly escalated root shell can't do everything. To not break legitimate sysadmin work, this setup would need an escape hatch so a real root user can get an unconfined shell. I'm imagining here there'd be a getty-alike daemon which talks over a local unix socket (for peer auth) instead of a VT, but such a thing understandably doesn't exist yet - who'd want a login shell that authenticates you by already being logged in?

I could bodge together a prototype using a regular getty and `busybox conspy`, but in a sufficiently protected system even that command ought to die with an error (I'm a bit bothered that it doesn't outright fail under `setpriv --bounding-set -all`). Maybe this is an idea that might interest the systemd folks, since they already made a few inroads on applying setcap to service trees.

AlmaLinux OS - CVE-2024-1086 and XZ (AlmaLinux blog)

Posted Apr 5, 2024 8:35 UTC (Fri) by walters (subscriber, #7396) [Link] (1 responses)

I think you're missing here that user namespaces give cap_net_admin in the user namespace, it's not about the global cap_net_admin. It's about the reachability of the nftables code from userspace in general.

From 8 years ago in https://lwn.net/Articles/673597/ a quote from Andy Lutomirski:

> I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there.

And yep...

AlmaLinux OS - CVE-2024-1086 and XZ (AlmaLinux blog)

Posted Apr 5, 2024 20:52 UTC (Fri) by flussence (guest, #85566) [Link]

I did experiment a bit before writing, and you're right I screwed up: I interpreted the error from "unshare --map-root-user --net -- setpriv --bounding-set -net_admin --nnp -- nft list ruleset" to imply it'd do the same in every case (so, with the first two programs swapped, which is how it'd be in a real situation).

Oops. Well that kind of ruins that idea. If it were so simple we'd already be doing it...

AlmaLinux OS - CVE-2024-1086 and XZ (AlmaLinux blog)

Posted Apr 11, 2024 13:36 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I thought it was weird that Alma would rate something higher to fix than RH but I think the difference of opinion is that RH documents a couple of runtime mitigations, disabling the nf_tables.so module from loading if you don't need it and/or disabling user namespaces, so you can't become root in a namespace and talk to nf_tables, if you don't need that feature. RH seems to think that the number of places which require user namespaces and/or use nf_tables is low but I'm not sure about that assumption. User namespaces are needed for containerization which is pretty common, and nf_tables is needed to enable _any_ host-based packet filtering which I think would also be pretty much standard on servers and workstations, even if you are behind a centralized firewall having network policy applied on the endpoints themselves as a belt-and-suspenders redundancy protects servers from east-west, lateral, peer-to-peer communication in the same LAN that a central firewall doesn't see and can help protect against a single firewall misconfig or accidentally enabled services from being a threat vector. There just seems few hardware that wouldn't have one or the other feature enabled as a requirement, so Alma seems right in their assessment and RH seems wrong.