oss-security - Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240713205858.LSnJJGoo@steffen%sdaoden.eu>
Date: Sat, 13 Jul 2024 22:58:58 +0200
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: ASLRn't is still alive and well on x86
 kernels, despite CVE-2024-26621 patch

Jacob Bachmeyer wrote in
 <6691E39C.8090600@...il.com>:
 |Steffen Nurpmeso wrote:
 |> [...]
 |>
 |> So if someone says "this  was a source of
 |> denial‐of‐service attacks" then i need to wrap my head, and it is
 |> not as if an in-between-the-lines reference to MAP_DENYWRITE ring
 |> any bells except that i think the flag has been removed.
 |
 |The manpage indicates that, long ago, a mapping with MAP_DENYWRITE would 
 |effectively make the underlying file read-only, even to root, for as 
 |long as the mapping exists.

Thank you.  I add a search result from Google Groups which still
exists for doing so collected just now:

  Linus Torvalds Oct 4, 2001, 7:38:12 AM

  Rob Landley <lan...@...mmello.org> wrote:
  >I.E. it seems like they go out of their way to ALLOW writing to the libaries.
  > (I assume they KNOW the difference between MAP_DENYWRITE, MAP_COPY, and
  >MAP_PRIVATE...?)

  Note that the kernel will refuse to honour MAP_DENYWRITE from user
  space, so I'm afraid that changing ld.so won't do a thing.

  The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
  excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
  and even root cannot write to it.. Vary nasty.

  Which is why the kernel only allows it when the binary loader itself
  sets the flag, because security-conscious application writers are
  already aware of the "oh, a running binary may not be writable" issues.

  So sorry..

  Linus

  Linus Torvalds Oct 4, 2001, 7:49:27 AM

  On Thu, 4 Oct 2001, Alexander Viro wrote:
  > <nit>
  > I _really_ doubt that something does write() on /etc/passwd. Create a
  > file and rename it over the thing - sure, but that's it.
  > </nit>

  Well, yeah, bad choice. Can you believe /var/run/utmp or similar?

  And yes, we could add checks for the thing being executable before we
  accept MAP_DENYWRITE instead of just ignoring the flag from user space.
  Nobody has cared enough to make the effort.

  Until now?

  Linus

Some findings:
  . I note that the mentioned files are writable by only root (and
  i would assume MAP_DENYWRITE to only work if i could do so
  myself).
  . Capabilities have become more fine-grained.
  . I always whimper when i have to rm(1) a running executable before
  placing an updated variant on Linux, on BSDs i simply over-cp(1)
  (and i do not understand as long as one gets either the one or
  the other when executing the path).
  . Shouldn't mandatory file locking have the same effect.
But it is ok to me, Linux is as it is, and they progress and
iterate over the code at an unbelievable speed.  And some things
are just the way they are.  (Or change.  Back.  And forth.  And
back etc etc)

 |>   And then
 |> someone who seems to know uses it nonetheless in a small showcase
 |> program, likely trying to say even more in-between-the-lines.
 |
 |That commit message seems to indicate that the program was using 
 |SHM_HUGETLB when it should have been using MAP_HUGETLB, those constants 
 |represent different bits, and passing SHM_HUGETLB to mmap(2) will be 
 |interpreted as MAP_DENYWRITE, and therefore ignored.  Presumably, there 
 |is some other syscall (likely shmat(2)) that uses that bit (represented 
 |under the constant SHM_HUGETLB) to request huge pages, and the test 
 |program in question was supposed to get huge pages from mmap(2) but was 
 |not actually asking for huge pages because it was using the wrong constant.
 |
 |In other words, MAP_DENYWRITE was not being intentionally used at all.  
 |Another constant, for a different set of flags, that happens to have the 
 |same value, was being used, causing a quiet bug.  (The test program 
 |would have still worked, but was not actually exercising huge pages as 
 |intended.)

The Linux commit messages are tremendous books that often leave me
stunning.  I *never* get together such things in my own work
process.  So thanks for spending additional time reiterating this.

 |-- Jacob

Thank you very much.

 --End of <6691E39C.8090600@...il.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.