[dead]
CVE-2026-31431: Copy Fail vs. rootless containers
51–60 of 140 posts
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#52[dead]
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#53Re: CVE-2026-31431: Copy Fail vs. rootless containers
#54Sigh. 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…
iiuc the AF_ALG interface only offers real performance wins if you have specialized hardware that the kernel can offload computations to. If you're not using that hardware, there's little reason not to do the crypto in userspace.
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#55Earlier quoted context omitted.
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…
You are obviously right that these are similar in principle: VM isolation exploit would lead to the same exposure like container-related isolation exploits. VMs are considered vastly better because the surface area where exploits can happen is smaller and/or better isolated within the kernel. If you are arguing the latter is not true — and we are all collectively hand-waving away big chunk of the surface area so that…
I would say it's the fact that "not a security boundary" appears to be a pass/fail statement, whereas the reality is more like a security continuum, along which VMs are further than containers.
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#56Re: CVE-2026-31431: Copy Fail vs. rootless containers
#57> [...] 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?
did anyone try it? it suppose to work right?
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#58Earlier quoted context omitted.
In fairness, after heartbleed - there was quite a push to move away from openSSL - like Google's boring ssl, openbsd libressl and Mozilla/nss or gnutls - but the alternative here would be moving to a different kernel, like freebsd or open Solaris/Illumos ...
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).
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#59Earlier 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 ?
It’s manipulating the binary to make it as small as possible. In golf, the lowest score wins. So, in this context, the smallest binary that still works wins.
Re: CVE-2026-31431: Copy Fail vs. rootless containers
#60Earlier quoted context omitted.
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?
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?