Top
Best
New

Posted by unsnap_biceps 11 hours ago

Copy Fail(copy.fail)
717 points | 296 commentspage 2
giis 4 hours ago|
As soon as I read this

>Shared dev boxes, shell-as-a-service, jump hosts, build servers — anywhere multiple users share a kernel. any user becomes root

jumped out of bed and went straight into webminal.org servers as local user and ran the python code. It says permission denied on sock() call.

Then I tested with local laptop with it:

```

$ uname -a

Linux debian 6.12.43+deb12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.43-1~bpo12+1 (2025-09-06) x86_64 GNU/Linux

$ python3 copy_fail_exp.py

# cd /root && ls

bluetooth_fix_log.txt dead.letter overcommit_memorx~ overcommit_memory~ overcommit_memorz~ resize.txt snap

```

It does provide the root access!

not_your_vase 11 hours ago||
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
progval 11 hours ago||
The binary "zip" isn't the exploit, it's the shellcode. The exploit is the rest, which changes the code of a SUID executable (su).
tgies 4 hours ago|||
I have a C translation here that should be pretty readable https://github.com/tgies/copy-fail-c
stackghost 9 hours ago||
The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.
tjbecker 9 hours ago||
For this crowd, I highly suggest checking out the technical writeup

https://xint.io/blog/copy-fail-linux-distributions

belkinpower 7 hours ago|
This has frustratingly low information density for a technical writeup. The LLM output on the marketing page is whatever, but here it really feels like my time isn’t being respected.
rkeene2 9 hours ago||
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...
rkeene2 9 hours ago||
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.
hashstring 8 hours ago||
Eh, if you can pollute page caches this won’t safe you.

Think modifying shared libraries, ld preload, cron, I guess on some systems /etc/passwd even.

There are a lot of files readable that should definitely not be writable.

rkeene2 7 hours ago||
Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC:

  f=g.open("/etc/passwd",0);
  e="rkeene:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash\n".encode()
  ...
  g.system("/run/wrappers/bin/su - rkeene")
zerocrates 8 hours ago||
It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.
rkeene2 8 hours ago||
My `sudo` is also not readable. Files/directories don't need to be readable to be executed. I can still use `su` and `sudo`.
rkeene2 8 hours ago||
I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it).

[0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm

miniBill 6 hours ago|
Don't you have like, a sudo in /run/wrappers/bin?

EDIT: Sorry, I failed at reading your message. Never mind.

skilled 11 hours ago||
This looks like an extraordinary find at first glance.

Does this mean you can go from a basic web shell from a shared hosting account to root? I can see how that could wreak havoc really quickly.

barbegal 10 hours ago|
Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.
stackghost 10 hours ago|||
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

bananamogul 10 hours ago||
"Debian Stable ("Trixie", though I hate codenames)"

You can also call it Debian 13.

cachius 9 hours ago|||
13.4 since 3/14
stackghost 9 hours ago|||
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.

tremon 7 hours ago||
> I run Trixie on most of my personal boxes and I had no idea what version number it is

It's not that hard to find though:

  $ cat /etc/debian_version 
  13.4
bblb 10 hours ago||
What is "RHEL 14.3"? Was this site a one shot prompt. Quality.
dgellow 10 hours ago||
That’s the most AI-written page ever made
collinmanderson 9 hours ago|
Yes. So cringy.
commandersaki 4 hours ago||
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_SKCIPHER=m
    CONFIG_CRYPTO_USER_API_RNG=m
    # CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
    CONFIG_CRYPTO_USER_API_AEAD=m
    # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
    $ uname -r
    6.12.63-1-lts
sltkr 3 hours ago|
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).
commandersaki 2 hours ago||
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.
jzb 10 hours ago|
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.
oskarkk 9 hours ago||
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...

bryanlarsen 10 hours ago|||
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.
tylerni7 9 hours ago|||
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!
justinclift 7 hours ago|||
> obviously marketing

Why marketing though?

tylerni7 7 hours ago|||
because we're a company and we want to make money to continue to fund cool research, and help our customers secure their software :)
otterley 2 hours ago||
I don't quibble with your wanting to make money, but you also need to invest some resources on fact-checking, proofreading, and editing your work. You can hire technical writers and marketing copy editors on an hourly basis as needed. LLMs aren't good enough yet to produce high-quality output on their own; and the results tend to read similarly, loaded with clichés and identical turns of phrase.

(You're not alone in this, BTW; I don't mean to single you out.)

Sohcahtoa82 7 hours ago|||
Resume-driven development
IgorPartola 6 hours ago||
I would rather people who find this kind of stuff pad their resumes and get coolness points on HN than sell this exploit on the black market. But your priorities may be different and you might prefer they do the latter.
0x00cl 3 hours ago||
This is just a false dichotomy. Sure researches want money, credit but not at the cost of harming users or doing illegal things.
cozzyd 5 hours ago|||
yeah, I assumed the whole thing was AI slop when I saw EL14...
tjbecker 2 hours ago|||
https://x.com/i/status/2049687923814281351

> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!

rdtsc 10 hours ago||
[flagged]
tptacek 10 hours ago|||
I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.
rdtsc 10 hours ago|||
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.
tptacek 10 hours ago|||
I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory.

It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).

JeremyNT 8 hours ago|||
Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end.

Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?

stackghost 10 hours ago||||
Is it more likely they have no idea what version RHEL is on, or that it's just a typo?
0x0 8 hours ago|||
Dropping a public exploit on github before distros have patches available isn't very cool, or is that just how veterans roll these days?
tptacek 8 hours ago|||
There is no one accepted set of norms on disclosure. Any strategy you take, someone will criticize.
akerl_ 8 hours ago||||
I don’t know if “cool” is the word I’d use, but there isn’t an established “right” way to disclose a vulnerability that you found outside of a contracted security review or other employment/contracting arrangement.
john_strinlai 7 hours ago|||
mainline was patched a month ago
More comments...