[conspire] kernel Dirty Pipe Vulnerability: overwriting data in arbitrary read-only files

[Rick Moen]

I highly recommend https://dirtypipe.cm4all.com/ as a truly excellent 
detective story -- getting to the bottom of a puzzling Linux server 
problem that, for a change, was traceable to very nasty kernel bug in
Linux 5.8 and later kernels.

Attempting to summarise:  Max Kellermann's hosting operation collects
Web-access logfiles, split daily into one file per hosted Web site,
gzipped, into a custom in-RAM database called Pond.  Further processing
concatenates all such files for a month into a Zip archive. Kellerman
kept finding corrupted logfiles that were corrupted in a way leaving
telltale signs of the Web process using the splice() system call that
creates the Zip archive (because of a bogus "PK" header all Zip archives
have had since the late Phil Katz invented Zip archiving) -- but that
seemed impossible, because the Web process runs as a different user that
lacks write permission on the log files.

Through brilliant debugging, Kellermann ruled out other possible
suspects, leaving only a serious kernel bug -- improbable as that seems.
_Then_, he wrote simple test code.

o  One C program wrote chunks of the string "AAAAA" to a test file as a
   simulation of the process that runs daily to split the log files into
   one file per hosted Web site.

o  One C program (lacking permission to write to the test file)  runs to
   collect that file data and send it to a pipe using splice() and then
   writing the string “BBBBB” to the pipe (simulating the ZIP generator).

Running both programs on the log server, the string "BBBBB" started
appearing in the -test file-, even though nobody ever wrote this string
to the file (only to the pipe by a process without write permissions).

Some checking of the kernel found a bug in a git commit that which
refactors the pipe buffer code for anonymous pipe buffers.  Without
paraphrasing the bug description, in general terms, sloppy kernel
handling of "flags" for pipe buffers (uninitialised variable
"pipe_buffer.flags") made it possible for a page cache reference to
overwrite data in the page cache.  If the kernel memory manager then
judges that page to be "dirty", then it will get written back to disk.
If not, the change will be ephemeral.  Subtle attacks on system security
are then possible.

  To make this vulnerability more interesting, it not only works
  without write permissions, it also works with immutable files, on
  read-only btrfs snapshots and on read-only mounts (including CD-ROM
  mounts). That is because the page cache is always writable (by the
  kernel), and writing to a pipe never checks any permissions.

Anyhow, I recommend that page for details.

The bug was designated CVE-2022-0847,  Kellerman's fix got merged into 
Linux kernel versions 5.16.11, 5.15.25 and 5.10.102.


----- Forwarded message from Russell Coker <russell at coker.com.au> -----

Date: Thu, 10 Mar 2022 13:42:12 +1100
From: Russell Coker <russell at coker.com.au>
To: luv-main at luv.asn.au
Subject: latest Linux major kernel issue

https://dirtypipe.cm4all.com/

This one is interesting and gives a lot of information on how the bug was 
tracked down.

It's fixed in the latest release of linux-image-5.10.0-11-amd64 in Debian and 
I rebooted my server 2 days ago so the LUV VM has the fix.  It's a very 
serious issue and SE Linux won't save you as it permits writing to read-only 
files.  So for example a process that can read /etc/passwd (which means every 
process) can write to it and potentially change the UID of an account to zero.

The Debian package linux-image-5.10.0-12-amd64 has just been released which 
has fixes for other security issues.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/



_______________________________________________
luv-main mailing list -- luv-main at luv.asn.au
To unsubscribe send an email to luv-main-leave at luv.asn.au

----- End forwarded message -----