Comment tester si un binaire Linux a été compilé en tant que code indépendant de la position?

J'ai récemment appris que (du moins sur Fedora et Red Hat Enterprise Linux), les programmes exécutables compilés en tant qu'exécutables indépendants de la position (PIE) bénéficient d'une protection renforcée de la randomisation de l'espace adresse (ASLR).

Alors: comment puis-je tester si un exécutable particulier a été compilé en tant qu’exécutable indépendant du poste sous Linux?

Vous pouvez utiliser le perlscript contenu dans le hardening-checkpaquet, disponible dans Fedora et Debian (en tant que hardening-includes). Lisez cette page wiki Debian pour plus de détails sur les drapeaux de compilation à vérifier. C'est spécifique à Debian, mais la théorie s'applique également à Red Hat.

Exemple:

$ 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

J'avais l'habitude readelf --relocsde tester si la bibliothèque statique ou dynamique est PIC sur x86-64 de la manière suivante:

$ 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

Nous voyons ici R_X86_64_32et R_X86_64_32S. Cela signifie que le code n'est pas indépendant de la position. Lorsque je reconstruis une bibliothèque avec -fPIC, je reçois:

$ 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

Cette méthode peut probablement fonctionner pour les exécutables, mais je ne l'ai pas utilisée de cette façon.

Utilisez simplement filesur le binaire:

$ 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

Notez le type différent imprimé après les informations LSB.

file 5.36 le dit clairement

file5.36 l’imprime clairement si l’exécutable est PIE ou non. Par exemple, un exécutable PIE s'affiche comme suit:

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

et un non-PIE comme:

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

La fonctionnalité a été introduite dans la version 5.33 mais elle n’a fait qu’une simple chmod +xvérification. Avant cela, il venait juste d’être imprimé shared objectpour PIE.

En 5.34, il était censé commencer à vérifier les DF_1_PIEmétadonnées ELF plus spécialisées , mais en raison d’un bogue dans l’implémentation, il a en réalité volé en éclats et a montré les exécutables de GCC PIE shared objects.

J'ai interprété filele code source, y compris le bogue, et exactement quels octets du format ELF il vérifie avec des détails insoutenables à l' adresse : https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object au lieu d'un exécutable binaire selon / 55704865 # 55704865

Un résumé rapide du comportement du fichier 5.36 est le suivant:

• si Elf32_Ehdr.e_type == ET_EXEC
  • impression executable
• sinon si Elf32_Ehdr.e_type == ET_DYN
  • si DT_FLAGS_1une entrée de section dynamique est présente
    • si DF_1_PIEest défini dans DT_FLAGS_1:
      • impression pie executable
    • autre
      • impression shared object
  • autre
    • si le fichier est exécutable par l'utilisateur, le groupe ou d'autres
      • impression pie executable
    • autre
      • impression shared object

GDB exécuter le fichier exécutable deux fois et voir ASLR

Une chose très directe que vous pouvez faire est d'exécuter l'exécutable deux fois via GDB et de voir si l'adresse change d'une exécution à l'autre en raison de ASLR.

J'ai expliqué comment procéder en détail à l' adresse suivante : https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031 # 51308031

Bien que ce ne soit pas nécessairement la solution la plus pratique et impossible si vous ne faites pas confiance à l’exécutable, c’est amusant et cela vérifie en dernier ressort que nous nous soucions vraiment de savoir si le chargeur dynamique du noyau / de Linux modifie l’emplacement de l’exécutable ou si ne pas.

Il existe un script bash checksec.sh sur Github pour vérifier les propriétés d’atténuation des exécutables (notamment RELRO, Stary Canary, bit NX, PIE, RPATH, RUNPATH, Fortify Source).

Exécuter checksecavec -fdes arguments (entrée de fichier):

$ 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