prelink/ExecShield/PIE interactions?

James Ralston qralston+ml.redhat-fedora-devel at andrew.cmu.edu
Fri Oct 15 22:37:00 UTC 2004


I'm confused as to how prelink and ExecShield interact, and
unfortunately, neither of these two docs really clarifies the issue:

    http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
    http://people.redhat.com/drepper/nonselsec.pdf

The nonselsec.pdf document states that prelinking and load address
randomization exclude each other.  Prelink does not appear to conflict
with either randomizing the stack location or making the stack
non-executable.

But if that's the case, then what exactly does the --no-exec-shield
option to prelink actually *do*?  What functionality of ExecShield
(that it doesn't already conflict with) is left for it to disable?

The reason I'm curious is due to dealing with programs that load
Windows DLLs and want to load them at specific addresses.  Here's what
mplayer recommends as a work-around:

    http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#id2895374

If I compare prelink.log files with and without the --no-exec-shield
option, it's obvious that --no-exec-shield does in fact free up
address 0x400000:

    --- prelink.log.old	2004-10-15 04:03:35.000000000 -0400
    +++ prelink.log	2004-10-15 17:38:15.549151696 -0400
    @@ -1 +1 @@
    -/usr/sbin/prelink -av -mR -q
    +/usr/sbin/prelink -av -mR --no-exec-shield -q
    @@ -12,2 +12,2 @@
    -Laying out 1 libraries in virtual address space 00101000-50000000
    -Random base 0x3d5ee000
    +Laying out 663 libraries in virtual address space 41000000-50000000
    +Random base 0x4d93c000

But I still don't understand why --no-exec-shield has that effect, or
what I actually loose by using it.

The nonselsec.pdf document also states that PIEs are excluded from
prelinking.  That makes sense.  But if code segments aren't writable
(and I don't believe they are, IIRC), what benefit does PIE actually
bring?  Is it trying to make it harder for an attacker to leverage
pre-existing code in the application to launch an exploit?

TIA for any insight...




More information about the devel mailing list