1

I am also wondering what does pie and what does aslr effect in memory as I understand, aslr randomizes addresses of libc base,stack and heap. And pie randomizes elf base and with that .text,.data,.bss,.rodata...

Is that correct or am I getting it wrong?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Noxy_proxy
  • 11
  • 2
  • 3
    PIE doesn't randomize anything. It's just a feature of your code, that it can be loaded at any address. Of course the loader still has to pick some addresses because the binary uses zero based offsets. It's just that ASLR can randomize more things if your binary is PIE. – Jester Apr 06 '20 at 14:22

1 Answers1

3

PIE requires position-independent code, costing a small amount of performance. (Or a large amount like 15% on ISAs like 32-bit x86 that don't easily support PC-relative addressing). See 32-bit absolute addresses no longer allowed in x86-64 Linux?.

With ASLR disabled, e.g. when running under GDB or with it disabled system-wide, Linux chooses a base address of 0x0000555555555000 to map the executable, so objdump -d addresses relative to the file start like 0x4000 end up at that high virtual address.

A PIE executable is an ELF shared object (like a .so), as opposed to an ELF "executable". An ELF executable has a base address in the ELF headers, set by the linker, so absolute addresses can be hard-coded into the machine code and data without needing relocations for fixups. (That's why there's no way to ASLR a proper ELF executable, only a PIE).

The mechanism that supports PIE was originally just a fun hack of putting an entry point in a library. Later people realized it would be useful for ASLR for static code/data in executables to be possible, so this existing support became official. (Or something like that; I haven't read up on the history.)

But anyway, ASLR is enabled by PIE, but PIE is a thing even with ASLR disabled, if you want the most general non-technical description.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • 1
    Yeah pretty much what you said. I wrote about this years ago (https://flameeyes.blog/2009/11/02/the-pie-is-not-exactly-a-lie/), back when the kernel had no ASLR by default. – Diego Elio Pettenò Apr 07 '20 at 16:37
  • @DiegoElioPettenò Then what PIE does if it chooses 0x0000555555555000 everytime? I can take this address if aslr is disabled and find the function addresses. It suppose to be independent and it is not a mitigation if it chooses the same address every run, even after boot it doesn't changes. – Ori May 07 '22 at 15:04
  • @Ori: If you don't disable ASLR, then it *is* randomized. e.g. run `cat /proc/self/maps` a few times, not under GDB and without globally disabling ASLR earlier this boot. If you *do* disable ASLR, then of course it's the same every time, not gaining any security. Like this answer says, PIE makes ASLR possible, but on its own is *not* a security measure. And yes, if you're going to run a system with ASLR disabled via `/proc/sys/kernel/randomize_va_space` = 0, you might as well build traditional executables instead of PIEs. – Peter Cordes May 07 '22 at 15:05
  • @PeterCordes Thanks, what PIE grants if there is no aslr? what's the difference between randomizing the default 0x400000 entry point? – Ori May 07 '22 at 15:38
  • 1
    @Ori: Nothing. Being able to ASLR the .text / .data of the main executable is the entire point of distros switching to PIEs, because of course **ASLR is already on by default** to randomize stack / mmap and shared library addresses. A PIE can be randomized like a shared library. – Peter Cordes May 07 '22 at 15:46