Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2026-31431: Copy Fail vs. rootless containers

dragonsreach.it

Post reply on HN
Print view View original

91–100 of 140 posts

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#91

Post by firesteelrain »

dwattttt wrote: post #74
firesteelrain wrote: post #40

Earlier quoted context omitted.

This is a problem and most people hadn’t considered it before because the caching is done to speed up build pipeline performance: “ While rootless containers prevent the attacker from escalating to host root, the page cache is still shared across the host. Containers that re-use the same base image layers share the same cached pages for those layers — if a malicious CI job corrupts a binary in the page cache, other c…

I'm no expert, but the kernel is shared between all containers and the host. I don't believe the kernel maintains separate page caches for each container; a malicious CI job could corrupt a binary from any container, or the host.

Only if there is a shared inode between host and container.

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#92

Post by cpach »

codedokode wrote: post #73

I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, or create special kind of processes, which are isolated, but quick to switch into. They are repeating Windows mistakes.

Well at least if it’s crufty stuff like AF_ALG that barely no-one is using and is kind of a forgotten place of the kernel.

I don’t oppose reasonable crypto in the kernel, like WireGuard.

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#93

Post by kevincox »

2bitencryption wrote: post #6

tl;dr - within the container, the exploit works, and elevates to root (uid 0) within the container - BUT because that namespace actually maps to uid 1000 (the user) outside the container, the escalation does not flow up to the host. But… does this escape the container? If not (the author seems to indicate it does not) then does it matter if you are in Docker or rootless Podman, right, since the end result is always:…

If any security relevant file from the host is mounted into the container this could be exploited quite easily. It is definitely a viable tool for escaping containers but it would require a bit of an attack chain and some containers may not be vulnerable.

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#94

Post by cpach »

est wrote: post #38
netheril96 wrote: post #32

If the goal is just preventing full root privileges, a CapabilityBoundingSet in a systemd unit will do. However copy fail can be used in many other ways not contained by containers or the above settings. For example it can modify the /etc/ssl/certs to prepare for MitM attacks. If you have multiple containers based on the same image then one compromised CA set affects another.

I added these AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE NoNewPrivileges=yes to my .service. Is it good enough?

Good enough for what?

I could be wrong, but I’m not sure those settings are enough to mitigate Copy Fail.

If your distro offers a patched kernel, it’s best to upgrade to that one and reboot.

You can also disable the vulnerable module (how to do it depends on what distro you’re using). But if you stay on an old unpatched kernel you might be exposed to other vulnerabilites.

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#95

Post by wang_li »

kelnos wrote: post #65
Titan2189 wrote: post #15

> [...] that root was just my unprivileged podman user on the host Couldn't you then simply re-run the exploit again as unprivileged podman user and gain root on the host?

No, because you're still in the container, and there's no route to the host's root from there. If you can orchestrate a container escape from the container's "root", then you're on to something.

This pollutes the page cache, which affects the entire host. Getting "root" in a rootless container may mean nothing. But if it attacked the ls, ps, cat, grep, etc. commands and any process outside the container invokes that command it runs the payload of the attacker. What if the payload of the attack is just the same attack to escalate to root? So now you have escaped the container and gained root.

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#98

Post by cpach »

chrisss395 wrote: post #78
PunchyHamster wrote: post #49

Earlier quoted context omitted.

tl;dr (not from article) echo -e 'install algif_aead /bin/false\n' > /etc/modprobe.d/disable-algif.conf that just prevents the faulty module from loading. So you have time to fix it properly (kernel upgrade) Technically there should be zero impact (the very very few tools that use it will fall back to userspace), I haven't even found that module loaded in infrastructure Then check if it is loaded, and if it is, unloa…

Dumb question: is preventing the module from loading safe to blindly run on, e.g., Unraid, Proxmox, WSL2? Is it possible to break anything?

I would say any sanely written application would fall back to doing the requested operations in userspace if it cannot use the AF_ALG socket.

It could fail though. But I have not yet heard of anyone noticing big problems due to disabling the problematic modules. And I have not noticed any such issues on our systems at ${DAYJOB}.

IMHO, since these parts of the Linux kernel are so crappy I personally would say disabling them is a good default choice. YMMV. But if you encounter problems, then you can always re-enable the modules. (Preferably after upgrading your kernel, obviously.)

Re: CVE-2026-31431: Copy Fail vs. rootless containers

#100

Post by jerf »

repelsteeltje wrote: post #53
Retr0id wrote: post #44

Earlier quoted context omitted.

It is, although real ELF golfers consider that a little naive.

Sorry for posting a n00b question, but could you share etymology on this term golfing ?

https://www.perlmonks.org/index.pl?replies=1;node_id=437032;...

As befits a history of perl, it is full of random quotes and rambling discourses about history, but it has a lot of info in it.

Post reply on HN