[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZpRSEWkkG6hmNhNo@itl-email>
Date: Sun, 14 Jul 2024 18:32:33 -0400
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Subject: Re: ASLRn't is still alive and well on x86 kernels,
despite CVE-2024-26621 patch
On Sat, Jul 13, 2024 at 10:58:58PM +0200, Steffen Nurpmeso wrote:
> 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)
Executable files and shared libraries should _never_ be modified
in-place. They should _always_ be renamed over. Otherwise, a program
might be a mixture of the old and new version, with completely undefined
results when the program is run.
> |> 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)
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
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.
