How to test whether a Linux binary was compiled as position independent code?

Question

I recently learned that (at least on Fedora and Red Hat Enterprise Linux), executable programs that are compiled as Position Independent Executables (PIE) receive stronger address space randomization (ASLR) protection.

So: How do I test whether a particular executable was compiled as a Position Independent Executable, on Linux?

Answer 1

You can use the perl script contained in the hardening-check package, available in Fedora and Debian (as hardening-includes). Read this Debian wiki page for details on what compile flags are checked. It's Debian specific, but the theory applies to Red Hat as well.

Example:

$ hardening-check $(which sshd)
/usr/sbin/sshd:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

Answer 2

Simply use file on the binary:

$ file ./pie-off
./pie-off: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0dc3858e9f0334060bfebcbe3e854909191d8bdc, not stripped
$ file ./pie-on
./pie-on: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=962235df5bd188e1ec48c151ff61b6435d395f89, not stripped

Note the different type printed after the LSB information.

Answer 3

file 5.36 says it clearly

file 5.36 actually prints it clearly if the executable is PIE or not. For example, a PIE executable shows as:

main.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, not stripped

and a non-PIE one as:

main.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

The feature was introduced in 5.33 but it did just a simple chmod +x check. Before that it just printed shared object for PIE.

In 5.34, it was meant to start checking the more specialized DF_1_PIE ELF metadata, but due to a bug in the implementation it actually broke things and showed GCC PIE executables as shared objects.

I have interpreted file source code, including the bug, and exactly which bytes of the ELF format it checks in excruciating detail at: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object-instead-of-an-executable-binary-according-to/55704865#55704865

A quick summary of file 5.36 behavior is:

• if Elf32_Ehdr.e_type == ET_EXEC
  • print executable
• else if Elf32_Ehdr.e_type == ET_DYN
  • if DT_FLAGS_1 dynamic section entry is present
    • if DF_1_PIE is set in DT_FLAGS_1:
      • print pie executable
    • else
      • print shared object
  • else
    • if file is executable by user, group or others
      • print pie executable
    • else
      • print shared object

GDB run the executable twice and see ASLR

One very direct thing that you can do is to run the executable twice through GDB and see if the address changes across runs due to ASLR.

I have explained how to do that in detail at: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031#51308031

While this is not necessarily the most practical solution and not possible if you don't trust the executable, it is fun and it does the ultimate check that we really care about, which is if the Linux kernel / dynamic loader changes the executable location or not.

Answer 4

I used readelf --relocs to test whether static or dynamic library is PIC on x86-64 the following way:

$ readelf --relocs /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a |\
      awk '$3~/^R_/ && $5!~/^\.debug/{print $3}' |sort -u
R_X86_64_32
R_X86_64_32S
R_X86_64_64
R_X86_64_DTPOFF32
R_X86_64_GOTPCREL
R_X86_64_PC32
R_X86_64_PLT32
R_X86_64_TLSLD
R_X86_64_TPOFF32

We see here R_X86_64_32 and R_X86_64_32S. This means that the code is not position independent. When I rebuild a library with -fPIC I get:

$ readelf --relocs libstdc++.a |\
      awk '$3~/^R_/ && $5!~/^\.debug/{print $3}' |sort -u
R_X86_64_64
R_X86_64_DTPOFF32
R_X86_64_GOTPCREL
R_X86_64_PC32
R_X86_64_PLT32
R_X86_64_TLSGD
R_X86_64_TLSLD

This method may probably work for executables, but I have not used it that way.

Answer 5

There is bash script checksec.sh on Github to check the executables mitigation properties (including RELRO, Stack Canary, NX bit, PIE, RPATH, RUNPATH, Fortify Source).

Run checksec with -f (file input) arguments:

$ checksec -f /usr/bin/bash

RELRO           STACK CANARY      NX            PIE             RPATH     RUNPATH      FORTIFY Fortified Fortifiable
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH    YES      13        33