Come verificare se un binario Linux è stato compilato come codice indipendente dalla posizione?

Di recente ho appreso che (almeno su Fedora e Red Hat Enterprise Linux), i programmi eseguibili compilati come PIE (Position Independent Executables) ricevono una protezione ASLR (Address Space Casualization) più forte.

Quindi: come posso verificare se un particolare eseguibile è stato compilato come eseguibile indipendente dalla posizione, su Linux?

Puoi usare lo perlscript contenuto nel hardening-checkpacchetto, disponibile in Fedora e Debian (as hardening-includes). Leggi questa pagina wiki Debian per i dettagli su quali flag di compilazione sono controllati. È specifico di Debian, ma la teoria si applica anche a Red Hat.

Esempio:

$ 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

Ho usato readelf --relocsper verificare se la libreria statica o dinamica è PIC su x86-64 nel modo seguente:

$ 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

Vediamo qui R_X86_64_32e R_X86_64_32S. Ciò significa che il codice non è indipendente dalla posizione. Quando ricostruisco una libreria con -fPIC ottengo:

$ 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

Questo metodo potrebbe probabilmente funzionare per eseguibili, ma non l'ho usato in questo modo.

Basta usare filesul binario:

$ 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

Nota il diverso tipo stampato dopo le informazioni LSB.

file 5.36 lo dice chiaramente

file5.36 in realtà lo stampa chiaramente se l'eseguibile è PIE o no. Ad esempio, un eseguibile PIE mostra come:

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

e uno non PIE come:

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

La funzione è stata introdotta in 5.33 ma ha fatto solo un semplice chmod +xcontrollo. Prima di ciò è appena stato stampato shared objectper PIE.

In 5.34, doveva iniziare a controllare i DF_1_PIEmetadati ELF più specializzati , ma a causa di un bug nell'implementazione ha effettivamente rotto le cose e mostrato gli eseguibili GCC PIE come shared objects.

Ho interpretato fileil codice sorgente, incluso il bug, ed esattamente quali byte del formato ELF controlla dettagliatamente in dettaglio su: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object -invece-di-un-eseguibile-binary-secondo-a / 55704865 # 55704865

Un breve riepilogo del comportamento del file 5.36 è:

• Se Elf32_Ehdr.e_type == ET_EXEC
  • stampare executable
• altro se Elf32_Ehdr.e_type == ET_DYN
  • se DT_FLAGS_1è presente la voce di sezione dinamica
    • se DF_1_PIEè impostato in DT_FLAGS_1:
      • stampare pie executable
    • altro
      • stampare shared object
  • altro
    • se il file è eseguibile dall'utente, dal gruppo o da altri
      • stampare pie executable
    • altro
      • stampare shared object

GDB esegue il file eseguibile due volte e visualizza ASLR

Una cosa molto diretta che puoi fare è eseguire il file eseguibile due volte tramite GDB e vedere se l'indirizzo cambia tra le esecuzioni a causa di ASLR.

Ho spiegato come farlo in dettaglio su: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031 # 51308031

Sebbene questa non sia necessariamente la soluzione più pratica e non possibile se non ti fidi dell'eseguibile, è divertente e fa il controllo finale che ci interessa davvero, cioè se il kernel / caricatore dinamico Linux cambia la posizione dell'eseguibile o non.

Esiste lo script bash checksec.sh su Github per verificare le proprietà di mitigazione degli eseguibili (inclusi RELRO, Stack Canary, bit NX, PIE, RPATH, RUNPATH, Fortify Source).

Esegui checkseccon -fargomenti (input file):

$ 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