[Security] PIE executables

[John Moser]

Ubuntu should ship Position Independent Executables (PIEs). (See separate bug report for PIE randomization)

PIEs contain relocation information to allow the relocation of the main executable. In theory, the kernel can randomize a PIE with the mmap() base (as with libraries); see separate bug report for in-practice analysis.

Currently the kernel randomizes the stack base and mmap() base. The mmap() base covers libraries, file-backed mmap() segments (i.e. libraries), and anonymous data segments (including shared memory mappings IIRC). The heap should not contain code. This leaves the program executable.

In the case that the stack is executable (see #34131, #34132, #34129), a stack-based buffer overflow (stack smash) can pad the beginning of the attack with ASM commands such as 'inc %ecx' (A) or 'inc %edx' (B) and then clear these out at shellcode initialization (i.e. 'xor %ecx,%ecx'). The return address can use 'jmp %esp' to jump to the stack pointer address. Because of the non-fixed length and thus non-aligned nature of x86 assembly, such an instruction need not exist; an attacker only needs to find an executable memory page at a fixed address containing the word "0xFFE4"

PIEs need not be PIC. PIC has some positive and negative effects.

On the positive side, PIC will avoid .text relocations (TEXTRELs), which require mandatory access controls such as SELinux 'execmod' to allow a program to rewrite its own executable code; TEXTRELs also cause rewritten code to take up private (instead of shared) memory and take longer to load while the dynamic linker performs relocations.

On the negative side, x86 PIC code also executes slightly slower (x86-64 has special addressing so PIC doesn't matter); benchmarks show a 1% difference, while profiles done with oprofile show the time spent in the main executable as less than 0.02% in most programs EXCEPT Xorg which spends 5-8% of its time in its main executable. At times, people have claimed slowdowns of around 20% in special cases, particularly in a PHP benchmark on the PHP Apache module as PIC vs non-PIC.

Building PIEs can prove complex. Brandon Hale may have some specific knowledge in this area.

[John Moser (nigelenki)]

Also see bug #139436

[Kees Cook (kees)]

Agreed. I'm not sure I agree about PIE not needing PIC (I would be interested in some examples of this), but yes, building PIE would be good, and work has already started there too. Note that openssh is already built as PIE (though without the kernel randomization, it's not too useful).

[John Moser (nigelenki)]

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.