[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <542C172B.5030601@mit.edu>
Date: Wed, 01 Oct 2014 08:00:59 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to musl
On 10/01/2014 06:29 AM, Rich Felker wrote:
> On Tue, Sep 30, 2014 at 10:49:15PM -0700, Andy Lutomirski wrote:
>>>> (Even better: the loader could patch the PLT with a direct jump. Could
>>>> musl do this? At least in the case where the symbol is within 2G of the
>>>> PLT entry,
>>>
>>> This is really not a good idea. The old PowerPC ABI did this, and musl
>>> does not support it (it requires the new "secure-plt" mode). Hardened
>>> kernels have various restrictions on modifying executable pages, up to
>>> and including completely forbidding this kind of usage. And even if
>>> it's not forbidden, it's going to use more memory due to an additional
>>> page (or more) per shared library that's not going to be sharable.
>>> Also it requires complex per-arch code (minimal machine code
>>> generation, instruction cache flushing/barriers, etc.).
>>
>> That extra page might not be needed if the linker could end up
>> removing a bunch of GOT entries for functions that don't have their
>> addresses taken. (Or, on x86_64, where unaligned access is cheap,
>> the GOT could actually overlap the PLT in memory, but only if
>
> This is not an option. It would require the page containing the GOT
> (and a lot of data) to be executable. Not only is this a huge security
> risk (makes exploiting other vulnerabilities a lot easier); it's also
> physically impossible to do on hardened kernels which simply lack
> "rwx" permission for mappings.
No rwx mapping would ever be needed. The GOT would be shoved *into* the
text segment, and the loader would switch it to rw, write in the
relocations, and switch it back to rx.
Some hardened kernels disallow this. I think that this particular
hardening option has long since served its purpose (distros no longer
ship things that are dangerous like this), but any exploit that can
convince a buggy program to do:
- mprotect to rw (or just find an rw mapping to begin with)
- attacker-controlled shellcode write
- mprotect to rx
- attacker-contolled jump
on a non-stack address has already won (they could just as easily have
written a ROP or SROP payload, or they could have written an environment
block and called execve instead of mprotect). Disallowing the mprotect
to rx is IMO utterly pointless and merely annoys everyone who tries to
write a JIT compiler.
At least new enough kernels probably allow reliable JITting using
memfd_create and two mmap calls.
(It wouldn't work anyway as I've described it because x86_64 has no
64-bit absolute jump.)
Anyway, this is off-topic enough that I'll shut up now.
>
>>>> this should be straightforward if no threads have been
>>>> started yet.
>>>
>>> Threads having been started or not are not relevant. The newly loaded
>>> code is not visible until dlopen returns, so nothing can race with
>>> modifications to it.
>>
>> True, at least when lazy binding is off.
>
> musl does not do lazy binding at all, and won't. There's been some
> demand for it in terms of allowing loading hacks where the symbols
> needed by the loaded library are not provided until later, but that
> can be satisfied by emulating it (basically, keeping a list of
> unsatisfied relocs and retrying them after each dlopen) rather than
> actually doing lazy binding at call time.
>
> Rich
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
