¿Cómo probar si un binario de Linux fue compilado como código independiente de la posición?

Hace poco aprendí que (al menos en Fedora y Red Hat Enterprise Linux), los programas ejecutables que se compilan como ejecutables independientes de posición (PIE) reciben una protección más fuerte de aleatorización del espacio de direcciones (ASLR).

Entonces: ¿Cómo pruebo si un ejecutable particular se compiló como un ejecutable independiente de posición en Linux?

Puede usar el perlscript contenido en el hardening-checkpaquete, disponible en Fedora y Debian (as hardening-includes). Lea esta página wiki de Debian para obtener detalles sobre qué marcas de compilación están marcadas. Es específico de Debian, pero la teoría también se aplica a Red Hat.

Ejemplo:

$ 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

Solía readelf --relocsprobar si la biblioteca estática o dinámica es PIC en x86-64 de la siguiente manera:

$ 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

Vemos aquí R_X86_64_32y R_X86_64_32S. Esto significa que el código no es independiente de la posición. Cuando reconstruyo una biblioteca con -fPIC obtengo:

$ 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

Este método probablemente funcione para ejecutables, pero no lo he usado de esa manera.

Simplemente use fileen el 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

Tenga en cuenta el tipo diferente impreso después de la información LSB.

file 5.36 lo dice claramente

file5.36 realmente lo imprime claramente si el ejecutable es PIE o no. Por ejemplo, un ejecutable PIE se muestra como:

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

y no PIE como:

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

La característica se introdujo en 5.33 pero solo hizo una simple chmod +xcomprobación. Antes de eso solo se imprimió shared objectpara PIE.

En 5.34, estaba destinado a comenzar a verificar los DF_1_PIEmetadatos ELF más especializados , pero debido a un error en la implementación, realmente rompió las cosas y mostró los ejecutables GCC PIE como shared objects.

He interpretado el filecódigo fuente, incluido el error, y exactamente qué bytes del formato ELF verifica con un detalle insoportable en: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object -en lugar de un binario-ejecutable-de acuerdo a / 55704865 # 55704865

Un resumen rápido del comportamiento del archivo 5.36 es:

• Si Elf32_Ehdr.e_type == ET_EXEC
  • impresión executable
• si no si Elf32_Ehdr.e_type == ET_DYN
  • si DT_FLAGS_1la entrada de sección dinámica está presente
    • si DF_1_PIEse establece en DT_FLAGS_1:
      • impresión pie executable
    • más
      • impresión shared object
  • más
    • si el archivo es ejecutable por usuario, grupo u otros
      • impresión pie executable
    • más
      • impresión shared object

GDB ejecuta el ejecutable dos veces y ve ASLR

Una cosa muy directa que puede hacer es ejecutar el ejecutable dos veces a través de GDB y ver si la dirección cambia a través de ejecuciones debido a ASLR.

He explicado cómo hacerlo en detalle en: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031 # 51308031

Si bien esta no es necesariamente la solución más práctica y no es posible si no confía en el ejecutable, es divertido y hace la comprobación final que realmente nos importa, que es si el kernel / cargador dinámico de Linux cambia la ubicación del ejecutable o no.

Hay bash script checksec.sh en Github para verificar las propiedades de mitigación de los ejecutables (incluidos RELRO, Stack Canary, NX bit, PIE, RPATH, RUNPATH, Fortify Source).

Ejecutar checkseccon -fargumentos (entrada de archivo):

$ 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