[PATCH] Deny preload of files on NOEXEC mounts

[Florian Weimer]

* 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.

> I think there are also more fundamental things that a library without
> any executable segments could do, by design, to compromise the
> integrity of the process - e.g. depending on when the evil library is
> loaded, it might be able to override a pointer symbol that was
> supposed to be located in a ".bss" section to point at the evil
> library's ".data" section instead and use that to effectively clobber
> a NULL-initialized pointer variable with an arbitrary value, or
> something like that?

A symbol could have a value that is not within the current shared
object, pointing into some other shared object's executable segment.

I don't think ELF has a generic redirection mechanism that isn't based
on code execution, though.  There is something limited for canonical
function addresses, but I'm not sure if it can be used this way.

> (Btw, this also means that IMA-based auditing of library loading based
> on executable mappings is currently bypassable. I don't think anyone
> really cares about that though - I brought it up with the IMA
> maintainers back in 2018 and IIRC they didn't see it as a problem.)

IMA only covers the contents, I think.  Neither paths nor even the most
basic file attributes are covered by the digest.

Thanks,
Florian