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

101–110 of 545 posts

Re: Copy Fail

#101

Post by microtherion »

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…

It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.

Re: Copy Fail

#102

Post by Xirdus »

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

> As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this. lucky for them, its an exploit script, not enterprise code. all that needs to be "reviewed" is whether or not it exploits the thing its supposed to. edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment…

I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.

Re: Copy Fail

#103

Post by john_strinlai »

Xirdus wrote: post #102
john_strinlai wrote: post #80

Earlier quoted context omitted.

> As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this. lucky for them, its an exploit script, not enterprise code. all that needs to be "reviewed" is whether or not it exploits the thing its supposed to. edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment…

I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.

id imagine that they received more than just the poc in the report they received

Re: Copy Fail

#105

Post by bonzini »

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)

Completely without editing, to the point of hallucinating a RHEL version (14.3) that doesn't exist.

Re: Copy Fail

#106

Post by rkeene2 »

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'm not sure I have any setuid/setgid binaries that are world-readable...

Re: Copy Fail

#107

Post by unsnap_biceps »

microtherion wrote: post #101
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…

It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.

It's patching the binary in memory, so the binary patch would be architecture dependent. The existing one is only x86_64, but with an updated payload, it would work on arm.

Re: Copy Fail

#108

Post by aniou »

Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.

Re: Copy Fail

#109

Post by fragmede »

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…

> Anyway, I could go on.

Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?

https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe...

edit: If we drop offset_src=0 and just pass in 0 positionally, it comes down to 720.

Re: Copy Fail

#110

Post by [deleted] »

MarleTangible wrote: post #89
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…

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

[deleted]
Post reply on HN