PIE without PIC is possible, because every hard-coded address in the
generated code gets entered into a table of TEXTRELs in the binary. The
dynamic linker rewrites these addresses (read: rewrites executable
code) at load time, giving slowdowns and crippling certain security
enhancements. The level at which this crippling can be addressed is
debatable.
On mitigation of the crippling of such security enhancements, PaX for
example has textrel emulation that allows exactly one cycle of
mprotect(...PROT_WRITE) mprotect(...PROT_EXEC) on a library after it's
loaded iff it contains textrels. A ret2libc chain can mmap() a library,
mprotect(...PROT_WRITE), memcpy(shellcode), mprotect(...PROT_EXEC) if it
likes, and then can execute injected code; however, such an attack
pretty much owns the execution flow, and (because glibc for some unknown
reason contains the string '/bin/sh' like 7 times) can just return to
system('/bin/sh') even without knowing the address of the stack (which,
by the way, you typically need for these long chains). (About to file a
glibc bug...)
On x86-64, you definitely use PIC because it causes no performance loss
due to the special addressing modes x86-64 supplies to support PIC
natively.
--
[Security] PIE executables
https://bugs.launchpad.net/bugs/139435
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
