Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copy Fail

copy.fail

Post reply on HN
Print view View original

291–300 of 545 posts

Re: Copy Fail

#291

Post by no-name-here »

Tuna-Fish wrote: post #88
xeeeeeeeeeeenu wrote: post #82

It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…

Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.

That was fixed, it’s now marked high.

Re: Copy Fail

#292

Post by commandersaki »

sltkr wrote: post #287
commandersaki wrote: post #252

Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days. Got: OSError: [Errno 97] Address family not supported by protocol I guess AF_ALG is not part of the Arch Linux LTS kernel? Edit: Looks like on Arch you have to go out of your way to have this enabled. $ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_…

On my Arch boxes the official exploit works, both with the LTS kernel (6.18.21-1-lts) and the mainline release (6.19.6-arch1-1).

Yeah I think maybe it loads the module on demand. The problem is I've upgraded my kernel many times in the last 122 days which wipes out the running or last installed kernel modules directory. I'm guessing if I had my running kernel modules directory it would on demand load and I'd get root.

Re: Copy Fail

#293

Post by no-name-here »

boston_clone wrote: post #181
jjordan wrote: post #175

Earlier quoted context omitted.

Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.

it’s a CVE write up; the audience for these knows what an LPE is.

Content at the OP link http://copy.fail seems fairly different from any normal CVE I’ve seen.

Re: Copy Fail

#294

Post by CGamesPlay »

progval wrote: post #51

So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace). I ran the exploit in rootless Podman, and predictably it doesn't escape the container. They also claim their script "roots every Linux distribution shipped…

Kubernetes 1.33 switches to user namespaces enabled by default, which I imagine is the same underlying mechanism that rootless Podman uses. `hostUsers: false` is the way to ensure that root in the pod is root on the host. It's trivial for a real (unmapped) root to escape a Kubernetes pod.

Re: Copy Fail

#295

Post by cynicalkane »

staticassertion wrote: post #274
smaudet wrote: post #273

Earlier quoted context omitted.

You should re-evaluate your probabilities, I too have heard frequently of CVEs, but never of an LPE.

I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.

I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms.

So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly serious about sysadmin knows you want to defensively keep systems patched against important CVEs. The second layer of that, what the exploits actually are or do, is a second-layer term of art, one that one might miss the jargon for even if one has familiarity with the concepts.

To me, the fact that the page is obviously AI-assisted is way more upsetting than some guy not knowing what an acronym means. There's something about AI prose that is just so fucking tedious. It makes the mind glaze over.

Re: Copy Fail

#296

Post by ebiggers »

eqvinox wrote: post #281
ebiggers wrote: post #232

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

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL. To steal from the sibling post: > * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters…

It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.

Re: Copy Fail

#297

Post by CGamesPlay »

rcxdude wrote: post #60
progval wrote: post #51

So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace). I ran the exploit in rootless Podman, and predictably it doesn't escape the container. They also claim their script "roots every Linux distribution shipped…

If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.

It's worth pointing out that you cannot, definitionally, get "real UID 0" in a "rootless" container, because then it wouldn't be a rootless container. This is relevant because this exploit doesn't claim to be able to bypass user namespaces, and that getting "real UID 0" would be a different exploit.

Re: Copy Fail

#298

Post by eqvinox »

ebiggers wrote: post #296
eqvinox wrote: post #281

Earlier quoted context omitted.

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL. To steal from the sibling post: > * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters…

It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.

It is being used that way:

https://github.com/opensourcerouting/frr/blob/2b48e4f97fb021...

And, sure, if it breaks system security it's pointless. But so did "dirty pipe".

I do agree the number of issues in AF_ALG is annoying, which is why I suggested a CAP_* restriction. Maybe CAP_SYS_ADMIN in init_ns, that's kinda the big hammer.

Re: Copy Fail

#300

Post by l1k »

ebiggers wrote: post #232

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

It does enable address space separation of secret keys from user space, which some people love:

https://blog.cloudflare.com/the-linux-kernel-key-retention-s...

https://www.youtube.com/watch?v=7djRRjxaCKk

https://www.youtube.com/watch?v=lvZaDE578yc

So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space.

Disclosure: I'm co-maintaining crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.

Post reply on HN