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

81–90 of 140 posts

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

#81

Post by throw0101c »

necovek wrote: post #37
ButlerianJihad wrote: post #30

Earlier quoted context omitted.

Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but th…

Security scanners already support most container and VM image formats in widespread use. Does this increase complexity? Yes, it does. Is it worth the cost? Depends on each individual case IMO.

> Security scanners already support most container and VM image formats in widespread use.

E.g.,

> Container Security stores and scans container images as the images are built, before production. It provides vulnerability and malware detection, along with continuous monitoring of container images. By integrating with the continuous integration and continuous deployment (CI/CD) systems that build container images, Container Security ensures every container reaching production is secure and compliant with enterprise policy.

* https://docs.tenable.com/enclave-security/container-security...

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

#82

Post by mjmas »

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…

Though this won't work for some kernels:

If algif_aead was a builtin module, it needs to be disabled by adding initcall_blacklist=algif_aead_init to the boot cmdline.

However initcall_blacklist requires the kernel to be built with CONFIG_KALLSYMS.

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

#83

Post by averi »

Retr0id wrote: post #80
averi wrote: post #76

Earlier quoted context omitted.

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.

There's a specific reason why the exploit targets a setuid binary, if you poison it in memory it will be executed with the permissions of the user owning it, in this case root, meaning a setuid(0) + spawning a new shell will effectively give you root access on the host system, this for systems where uid=0 is equivalent inside and outside the container itself. The vulnerability is still there and is deadly serious, with rootless containers the attack vector just increases, the attacker will have to identify other factors (what containers are using a shared base image, what binaries are being called, what binaries should be overridden in memory etc).

On top of this there's another thing worth mentioning, it's a common thing in Openshift (for non rootless podman) to allow CAP_SETGID/CAP_SETUID for being able to create a container within a container (this is called the allowPrivilegeEscalation in SCCs), that effectively grants you the ability to become uid=root in the container and in that scenario uid=0 matches the host uid=0. The important difference is that specific instance of the root user doesn't have CAP_SYS_ADMIN (or most of the other privileged kernel capabilities) meaning the actions the user can then perform are very limited.

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

#84

Post by Retr0id »

averi wrote: post #83
Retr0id wrote: post #80

Earlier quoted context omitted.

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.

There's a specific reason why the exploit targets a setuid binary, if you poison it in memory it will be executed with the permissions of the user owning it, in this case root, meaning a setuid(0) + spawning a new shell will effectively give you root access on the host system, this for systems where uid=0 is equivalent inside and outside the container itself. The vulnerability is still there and is deadly serious, wi…

I know how the reference exploit works, but that's not the only way to exploit the bug.

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

#86

Post by tremon »

cduzz wrote: post #61
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

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!

How do you propose to implement that "drop everything except what you need" policy? Do your containers come with a detailed list of which OS services and syscalls are required? I think your idea has the same issue as what held back the adoption of selinux: many developers think that having to enumerate their application's behaviour like that is an undue burden.

A compounding issue is that using AF_ALG doesn't require a separate syscall: it's just using SYS_socket with the first argument set to 38. Your container behaviour specification needs to be specific enough to not only enumerate allowed syscalls, but the allowed values for each syscall parameter.

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

#87

Post by ohnei »

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.

I don't think it was a bad idea, doing any idea requires an investment and a better investment would have been kernel layer, just ask the history of export control law what the US feared breaking more. Having security in userland means attacks in kernel or in userland are worthwhile against it. In the kernel it could have been secured better than OpenSSL was with less resources and could have had keys unavailable from userland. Instead it got basically no uptake as everyone hobbled along on slightly more resources spread even thinner on OpenSSL clones.

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

#88

Post by eqvinox »

mjmas wrote: post #75
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?

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

> if libraries or binaries are shared (read-only) between the host and container.

Yeah, exactly - that's a pretty big "if", and not how a lot of container automation does things. In particular you'd need to hit the base system, it's no help at all if some application files that the host does nothing with can be hit.

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

#89

Post by cormorant »

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.

It's not faster than userspace, it's much slower normally. On special boards with crypto accelerators it can be faster, and there can be compliance reasons to want it. References: [1] https://www.chronox.de/libkcapi/html/ch01s02.html [2] https://lwn.net/Articles/410763/ [3] https://trac.gateworks.com/wiki/linux/encryption#PerformaceC...

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

#90

Post by cduzz »

tremon wrote: post #86
cduzz wrote: post #61

Earlier quoted context omitted.

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!

How do you propose to implement that "drop everything except what you need" policy? Do your containers come with a detailed list of which OS services and syscalls are required? I think your idea has the same issue as what held back the adoption of selinux: many developers think that having to enumerate their application's behaviour like that is an undue burden. A compounding issue is that using AF_ALG doesn't require…

There are those who are paranoid and those who are expedient. If you're truly paranoid, you spin up the thing you want to run, measure what it does, and open the holes to allow it to do what it needs to. It's tedious and sometimes error-prone, but in some environments it is necessary.

In the vast majority of the world, you set permissions to what's reasonable and trust that most of the time things will work out pretty well and have a plan for if you need to fix things on the fly.

I personally am not terribly paranoid, but I've worked places where we had to be pretty paranoid (shared hosting).

Post reply on HN