Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.linux.misc > #86066

Re: copy.fail

Show all headers | View raw

* 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'

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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

csiph-web