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

111–120 of 545 posts

Re: Copy Fail

#111

Post by rkeene2 »

rkeene2 wrote: post #106

Interestingly it fails for me because my `su` isn't world-readable: $ stat /bin/su File: /bin/su Size: 59552 Blocks: 118 IO Block: 59904 regular file Device: 0,52 Inode: 796854 Links: 1 Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-09-18 13:23:03.117105665 -0500 Modify: 2021-02-13 05:15:56.000000000 -0600 Change: 2023-09-18 13:23:03.119105665 -0500 Birth: 2023-09-18 13:23:03.117105665 -0500 I…

A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.

Re: Copy Fail

#112

Post by oskarkk »

jzb wrote: 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.

14.3 seems to come from some Red Hat-specific GCC version, which can be reported as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)". See these random examples I found by googling:

https://github.com/anthropics/claude-code/issues/40741 (gcc version "Red Hat 14.3" included in system version at the bottom)

https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/s...

Re: Copy Fail

#113

Post by stackghost »

not_your_vase wrote: post #2

Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice

The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.

Re: Copy Fail

#114

Post by tylerni7 »

jzb wrote: 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.

ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!

Re: Copy Fail

#115

Post by nh2 »

If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines:

    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
Similarly, when the mitigation is in place,

    modprobe algif_aead
should fail with an error.

Re: Copy Fail

#116

Post by stackghost »

bananamogul wrote: post #62
stackghost wrote: post #23

Earlier quoted context omitted.

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.

I choose not to call it Debian 13 because that carries less context than Stable/Testing/sid. I'd rather not require the user to maintain that extra metnal mapping.

Anyone who knows anything about this subject immediately understands what is connoted by "Debian Stable". I run Trixie on most of my personal boxes and I had no idea what version number it is, nor do I particularly care.

Re: Copy Fail

#117

Post by tjbecker »

refulgentis wrote: post #79
smlacy wrote: post #75

The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. Looking at their source code [1] it starts with this simple line: import os as g,zlib,socket as s And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely bec…

It's just lazy AI* writing w/0 editing. "Just" is doing a lot of work there, I'm so annoyed reading it. It's like an anti-ad and they had pretty cool material to work with. * Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)

I recommend reading the technical writeup https://xint.io/blog/copy-fail-linux-distributions

Re: Copy Fail

#118

Post by tjbecker »

john_strinlai wrote: post #64
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…

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

This is correct. The container escape exploit and writeup is not yet released.

Re: Copy Fail

#120

Post by pixel_popping »

Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
Post reply on HN