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

131–140 of 140 posts

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

#131

Post by anygivnthursday »

graemep wrote: post #60
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.

They may not provide isolation as VMs but they clearly do limit some attacks. VMs do not provide the same isolation as using physically separate hardware either. I would have thought they provide better isolation than using multiple users which is the traditional security boundary. It might depends on what you mean by a container? Are sandboxes such as Bubblewrap and Firejail containers?

> It might depends on what you mean by a container?

The article was about Podman and Linux namespaces

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

#132

Post by pjmlp »

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.

Those Windows mistakes have been sorted out for a long time now.

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

#133

Post by graemep »

anygivnthursday wrote: post #131
graemep wrote: post #60

Earlier quoted context omitted.

They may not provide isolation as VMs but they clearly do limit some attacks. VMs do not provide the same isolation as using physically separate hardware either. I would have thought they provide better isolation than using multiple users which is the traditional security boundary. It might depends on what you mean by a container? Are sandboxes such as Bubblewrap and Firejail containers?

> It might depends on what you mean by a container? The article was about Podman and Linux namespaces

I understood the comment I replied to (and many similar comments that are regularly made on HN) as talking about containers in general.

Namespaces are used as a security mechanism.

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

#134

Post by seanhunter »

Retr0id wrote: post #56
repelsteeltje wrote: post #53

Earlier quoted context omitted.

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

In golf, lower scores are better.

Which, if you think about it, means the objective of golf is to be the person who plays the least golf.

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

#135

Post by chadgpt2 »

SV_BubbleTime wrote: post #62
PunchyHamster wrote: post #46

Earlier quoted context omitted.

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. there is no reason it would be default policy. Else might as well block every socket and just multiplex everything on stdin/out

>might as well block every socket and just multiplex everything on stdin/out You may be on to something…

They we can build an encoding to allow arbitrary syscalls via stdin/out for convenience

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

#136

Post by eqvinox »

angry_octet wrote: post #122
eqvinox wrote: post #67

Earlier quoted context omitted.

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

It's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.

It's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall.

Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.

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

#137

Post by cpach »

atmosx wrote: post #127
cpach wrote: post #111

Earlier quoted context omitted.

How does allowPrivilegeEscalation=False help?

Have you tested running the PoC in a pod with and without proviEsc set?

No, I haven’t.

My concern is to try to understand the mechanisms of the exploit.

Copy Fail is not simply ”hey, kernel, give me root”. I would say it’s more general than that. It’s rather: ”Hey, kernel, when you present file /foo to a process, make the contents of that file appear according to my wishes”. Which can be used (in various ways) to advance the attacker’s position.

That’s why I think it’s interesting to ponder if that power allows the attacker to simply sneak past security policies such as allowPrivilegeEscalation=false.

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

#138

Post by Anonbrit »

ranger_danger wrote: post #114
nwallin wrote: post #113

Earlier quoted context omitted.

I like the idea of keeping stuff out of the kernel as much as possible, but in this case, there are good reasons why cryptography has to live in the kernel. We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that. We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption. IPsec, for better or for worse, is authen…

What about having a way to run the same crypto code but in userspace? Or perhaps turn it into a library that can be used from userspace.

For encrypted disks, you've now got high-performance data shuffling between userspace and kernel space - a massive new attack surface

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

#139

Post by PunchyHamster »

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?

check if module is loaded. if it isn't nothing is using it and you can safely add it. I'd also imagine most software doesn't fail but just use userspace lib

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

#140

Post by PunchyHamster »

DarkUranium wrote: post #58
PunchyHamster wrote: post #48

Earlier quoted context omitted.

that's just moving to kernel that had 1000x less eyes on it. Yeah sure it will have less exploits but purely because nobody bothers to look when there are much juicer targets on Linux. But I am disappointed that we still don't have clear OpenSSL successor, there is nothing to be salvaged from this mess of a project

1000x less eyes is true, but also: Linux, even in the kernel, has a long history of "move fast and break things". Yes, the syscall API is (famously) stable, but the drivers, for example, are such a mess that many non-Linux projects prefer to take BSD drivers for e.g. WiFi despite them supporting far fewer devices (even if the Linux ones would be license compatible).

driver attitude in Linux could be summed up to "we'd rather have the hardware driver working than absent".

> but the drivers, for example, are such a mess that many non-Linux projects prefer to take BSD drivers for e.g. WiFi despite them supporting far fewer devices (even if the Linux ones would be license compatible).

or vote with your wallet and get device that has well supported card.

Post reply on HN