Live data from Hacker News

Copy Fail

copy.fail

61–70 of 545 posts

Re: Copy Fail

#61

It does not behave as described on EndeavorOS (arch-based) running kernel 6.19.14-arch1-1. I receive the error: Password: su: Authentication token manipulation error I'm guessing this means it's already patched?

yes, it was reported on march 23rd, patches on april 1. you are reading about it now because it has been patched.

No it hasn't.

Ubuntu before 26.04 LTS (released a week ago) are currently listed as vulnerable.

Debian other than forky and sid are currently listed as vulnerable.

This is a disgrace.

Re: Copy Fail

#62

Earlier quoted context omitted.

Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.

As of this comment, Debian Stable ("Trixie", though I hate codenames) doesn't have a fix in place and remains vulnerable, or at least their CVE tracker shows it as such: https://security-tracker.debian.org/tracker/CVE-2026-31431

"Debian Stable ("Trixie", though I hate codenames)"

You can also call it Debian 13.

Re: Copy Fail

#63
post #56

Earlier quoted context omitted.

I’ve poked around on my phone and it didn’t work: File "/data/data/com.termux/files/home/a.py", line 5, in c a=s.socket(38,5,0); # ... File "/data/data/com.termux/files/usr/lib/python3.13/socket.py", line 233, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PermissionError: [Errno 13] Permission denied

I got line 5 to run and failed on line 8 due to lack of su. I'd need to find a user accessible setuid binary for it to work. Traceback (most recent call last): File "/data/data/com.termux/files/home/exploit.py", line 8, in f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611…

Try /system/bin/ping

Re: Copy Fail

#64
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…

>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

they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.

"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."

Re: Copy Fail

#65

Earlier quoted context omitted.

yes, it was reported on march 23rd, patches on april 1. you are reading about it now because it has been patched.

No it hasn't. Ubuntu before 26.04 LTS (released a week ago) are currently listed as vulnerable. Debian other than forky and sid are currently listed as vulnerable. This is a disgrace.

Disclosure timeline

    2026-03-23Reported to Linux kernel security team
    2026-03-24Initial acknowledgment
    2026-03-25Patches proposed and reviewed
    2026-04-01Patch committed to mainline
    2026-04-22CVE-2026-31431 assigned
    2026-04-29Public disclosure (https://copy.fail/)
kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.

Re: Copy Fail

#66
post #57
post #29

Earlier quoted context omitted.

Android is smarter than setuid + system partitions aren't writable.

System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading. Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon". But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open…

Edit: Ignore this I overlooked calling order. It is indeed blocked

~~My allegedly fully patched pixel 8 pro allowed an AF_ALG socket to open under termux without virtualization so I'm not sure the last but is true~~

Re: Copy Fail

#67
post #24

This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.

On the same line it says kernel version 6.12.0-124.45.1.el10_1. Which is RHEL 10. This is the kind of typo that humans make -- the hard to type numbers are accurate because they're cut and pasted, but the "easy" numbers have errors because they're not cut and pasted.

Re: Copy Fail

#68
post #48
post #44

Earlier quoted context omitted.

I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.

The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.

Is it more likely they have no idea what version RHEL is on, or that it's just a typo?

Re: Copy Fail

#69
post #3

What is the rationale behind naming CVEs and individual domains? Marketing?

can you remember what CVE-2021-44228 is without looking it up? CVE-2014-6271? CVE-2017-5753? i bet if i told you their names, you would instantly know what vulns those are. its easier to talk about things with names. it hurts no one. it takes approximately no effort or time. CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure…

> CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.

What, you guys talk about books based on their “title” instead of just memorising the ISBN of each book? Pssh, count me disappointed!

Re: Copy Fail

#70
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…

Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things

Ah indeed, it can be used to overwrite the page cache for files on read-only volumes.
Post reply on HN