On 06 Sep 2021 17:10, Florian Weimer via Libc-alpha wrote:
> * Jann Horn:
> > My understanding is that the ChromeOS security folks (I'm not on that
> > team) would like to ensure that, as a security hardening measure,
> > attempting to load an attacker-controlled library from a noexec mount
> > doesn't give the attacker the ability to run code in the context of
> > the loader.
> >
> > As far as I understand, the kind of ELF file I used in the linked bug
> > (sorry about the access restriction) looks fairly legitimate: It
> > doesn't clobber any existing mappings, instead it uses a ".init_array"
> > section containing a relocation into glibc, like this:
> >
> >         .section        .init_array,"aw"
> >         .align 8
> >         .quad   rmdir+0x774
> >
> > By picking an appropriate gadget in glibc, and making use of the
> > register contents at the indirect call to the fake constructor
> > function, it is possible to use that to e.g. start a ROP chain.
> 
> Ah, that really needs trusted_for to fix.
> 
> Many distributions do not even mark shared objects as executable, so
> executable permission is not something we can enforce in the dynamic
> loader.

we shouldn't let bad distro decisions constrain possibilities.  we have the
ability to move the ecosystem.  we can add new features that are disabled by
default via configure options with warnings (including in NEWS) that these
will change in the future.  distros will migrate if they want newer glibc.
-mike