Re: [musl] [PATCH] harden against unauthorized writes to the atexit function lists

[Matthew Maurer <mmaurer@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

While we are not a supported system, I would also note that I work on a
project which *does* expect `atexit` to work properly, but does not have a
working anonymous mmap system due to how resource management works for us.

If ASLR is enabled, that should already mitigate the ability of an attacker
to write to this location. While placing these in anonymous pages would be
a further defense against cases where a pointer is leaked *and* an
arbitrary overwrite is present, this would be an argument for a more
complete form of randomization (see also pagerando,
https://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html ) rather
than trying to randomize the location of individual chunks of sensitive
data.

On Tue, Dec 1, 2020 at 5:37 PM Rich Felker <dalias@libc.org> wrote:

> On Tue, Dec 01, 2020 at 05:55:39PM -0700, Ariadne Conill wrote:
> > previously, the first atexit list block was stored in BSS, which means an
> > attacker could potentially ascertain its location and modify it, allowing
> > for its abuse as a code execution mechanism.
> >
> > by moving the atexit list into a series of anonymous mmaped pages, we can
> > use mprotect to protect the atexit lists by keeping them readonly when
> they
> > are not being mutated by the __cxa_atexit() function.
>
> This is a non-starter. atexit is specifically required by the standard
> to succeed when called no more than 32 times, which is why we have 32
> built-in slots that always exist. If you really want to pursue
> something here it should probably just be protecting the pointers with
> some secret...
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2034 bytes --]