From: Andy Lutomirski <luto@amacapital.net>
To: musl@lists.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to musl
Date: Wed, 01 Oct 2014 08:00:59 -0700 [thread overview]
Message-ID: <542C172B.5030601@mit.edu> (raw)
In-Reply-To: <20141001132932.GJ23797@brightrain.aerifal.cx>
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
>
next prev parent reply other threads:[~2014-10-01 15:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 12:43 Weldon Goree
2014-09-30 14:59 ` stephen Turner
2014-09-30 16:20 ` Weldon Goree
2014-09-30 15:32 ` Isaac Dunham
2014-09-30 15:50 ` Rich Felker
2014-09-30 23:50 ` Andy Lutomirski
2014-10-01 0:05 ` Rich Felker
2014-10-01 5:49 ` Andy Lutomirski
2014-10-01 13:29 ` Rich Felker
2014-10-01 15:00 ` Andy Lutomirski [this message]
2014-10-01 7:48 ` Szabolcs Nagy
2014-10-01 8:19 ` u-wsnj
2014-10-01 13:30 ` Rich Felker
2014-09-30 15:46 ` Rich Felker
2014-09-30 16:05 ` Weldon Goree
2014-10-01 6:29 ` Timo Teras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542C172B.5030601@mit.edu \
--to=luto@amacapital.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).