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

71–80 of 140 posts

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

#71

Post by staticassertion »

dwroberts wrote: post #33
anygivnthursday wrote: post #28

Earlier quoted context omitted.

Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.

I see the ‘not a security boundary’ thing repeated constantly, and while it makes sense (eg. they’re sharing the underlying kernel or at least some access to it) if you think about it a little more, VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common. A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervis…

Containers are a security boundary, yes.

> A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervisor will be no less damaging than this CVE is to containers

Yeah this almost never happens though whereas Linux privesc is 10x a day.

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

#72

Post by staticassertion »

jeroenhd wrote: post #35
amluto wrote: post #8

Sigh. 1. I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. 2. The write-to-RO-page-cache primitive STILL WORKED! It’s just that the particular exploit used had no meaningful effect in the already-root-in-a-container context. If you think you are safe, you’re probably wrong. All you need to make a new exploit is an fd representing something that you aren’t supposed t…

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass…

> a security bug in them that one time?

More than one time.

> a cryptographic performance enhancement feature

It's very rarely used.

> Did we blacklist OpenSSL's binaries after Heartbleed?

No, but lots of companies have since migrated away. OpenSSL was harder to move away from because there weren't as obvious drop-in replacements. Blocking a syscall that you never actually used is simple and effective.

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

#73

Post by codedokode »

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.

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

#74

Post by dwattttt »

firesteelrain wrote: post #40
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:…

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.

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

#75

Post by mjmas »

eqvinox wrote: post #67
hlieberman wrote: post #13

Earlier quoted context omitted.

In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premise of this article is flawed and irresponsible.

AIUI they haven't shown a container escape and are just claiming it so far. Or did I miss something?

Having write access on anything you can read should be enough if libraries or binaries are shared (read-only) between the host and container.

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

#76

Post by averi »

Retr0id wrote: post #47
cpach wrote: post #42

Earlier quoted context omitted.

What is the false premise in the article?

That rootless containers mitigate kernel exploits.

Nowhere in the article is mentioned user namespaces completely mitigate the vulnerability, page cache corruption still happens but not being able to obtain root in the target host increases the attack vector to more than just a one liner into having to figure out whether specific shared base image layers are in use and by whom and by what binaries (think of a shared CI platform like the one we run for GNOME).

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

#77

Post by throw0101c »

dwroberts wrote: post #33
anygivnthursday wrote: post #28

Earlier quoted context omitted.

Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.

I see the ‘not a security boundary’ thing repeated constantly, and while it makes sense (eg. they’re sharing the underlying kernel or at least some access to it) if you think about it a little more, VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common. A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervis…

> […] VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common.

VMs are not different due to 'magic' but through hardware assist with things like Intel VT-x and AMD-V:

* https://en.wikipedia.org/wiki/X86_virtualization#Hardware-as...

* https://blog.lyc8503.net/en/post/hypervisor-explore/

* https://binarydebt.wordpress.com/2018/10/14/intel-virtualisa...

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

#78

Post by chrisss395 »

PunchyHamster wrote: post #49
washbasin wrote: post #3

Please post a tl;dr at the top or even in the subject. Many of us are scrambling to patch/reboot our **.

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?

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

#79

Post by averi »

M_bara wrote: post #19
averi wrote: post #11

[flagged]

> (like reading env vars and sending them to an external server) it'd not be able to send credentials or fetch a malware remotely at all due to the DNS queries being intercepted by eBPF and being sent to a CoreDNS proxy. Wouldn’t the exploit then just use ip addresses directly?

You can work with the idea of a DNS whitelist, as in you pass a list of allowed DNS entries via your .gitlab-ci.yml (or separate config) resolution happens and those entries (IPs) are stored in a list, any other IP not present in that list gets denied by eBPF (which can easily be used to rewrite the source and destination of a packet before the packet actually reaches the NIC for dispatch)

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

#80

Post by Retr0id »

averi wrote: post #76
Retr0id wrote: post #47

Earlier quoted context omitted.

That rootless containers mitigate kernel exploits.

Nowhere in the article is mentioned user namespaces completely mitigate the vulnerability, page cache corruption still happens but not being able to obtain root in the target host increases the attack vector to more than just a one liner into having to figure out whether specific shared base image layers are in use and by whom and by what binaries (think of a shared CI platform like the one we run for GNOME).

The article does not prove that you can't get root on the host via page cache corruption, just that the specific exploit strategy they tried didn't work.
Post reply on HN