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

61–70 of 140 posts

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

#61

Post by cduzz »

PunchyHamster wrote: post #46
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. there is no reason it would be default policy. Else might as well block every socket and just multiplex everything on stdin/out

I'd have guessed that the default paranoia-first policy would be "drop everything; verify what you need" which would include AF_ALG.

share and enjoy!

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

#62

Post by SV_BubbleTime »

PunchyHamster wrote: post #46
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. 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…

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

#63

Post by eqvinox »

Retr0id wrote: post #44
eqvinox wrote: post #4

Running sstrip on an ELF binary is called ELF "golfing"? TIL…

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

It does feel a little simplistic to get a special name. But lesser things have gotten fancier names...

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

#64

Post by throw0101a »

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…

> 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.

The need for this feature/functionality in the fist place is questioned by some:

> As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).

> The algorithm being used in this [specific] exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API. […]

* https://news.ycombinator.com/item?id=47952181#unv_47956312

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

#65

Post by kelnos »

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.

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

#67

Post by eqvinox »

hlieberman wrote: post #13
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…

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?

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

#68

Post by staticassertion »

PunchyHamster wrote: post #46
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. there is no reason it would be default policy. Else might as well block every socket and just multiplex everything on stdin/out

The reason is that it's very rarely used and has a history of issues.

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

#70

Post by staticassertion »

dwroberts wrote: post #22
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…

There is an addendum at the bottom where they admit the page corruption is still problematic even with rootless podman. Although using this to justify their migration to micro-VMs is very strange to me. Sure for this CVE it would have been better, but surely for a future attack it could hit a component shared across VMs but not containers? Are people really choosing technology based on CVE-of-the-week?

These sorts of vulns are extremely common on Linux. This one is making the rounds for various reasons but it's a good justification for a migration away from containers if your threat model is concerned about it.

MicroVMs have much lower attack surface and you can even toss a container into one if you'd like.

Or use gvisor, which mitigates this vulnerability.

Post reply on HN