Как проверить, был ли двоичный файл Linux скомпилирован как позиционно-независимый код?

Недавно я узнал, что (по крайней мере, в Fedora и Red Hat Enterprise Linux) исполняемые программы, которые скомпилированы как независимые от позиции исполняемые файлы (PIE), получают более надежную защиту от рандомизации адресного пространства (ASLR).

Итак: Как проверить, был ли определенный исполняемый файл скомпилирован как независимый от позиции исполняемый файл в Linux?

Вы можете использовать perlскрипт, содержащийся в hardening-checkпакете, доступный в Fedora и Debian (as hardening-includes). Прочтите эту вики-страницу Debian, чтобы узнать, какие флаги компиляции проверены. Это специфично для Debian, но теория применима и к Red Hat.

Пример:

$ 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

Я использовал readelf --relocsдля проверки статической или динамической библиотеки PIC на x86-64 следующим образом:

$ 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

Мы видим здесь R_X86_64_32и R_X86_64_32S. Это означает, что код не зависит от позиции. Когда я перестраиваю библиотеку с -fPIC, я получаю:

$ 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

Этот метод, вероятно, может работать для исполняемых файлов, но я не использовал его таким образом.

Просто используйте fileна двоичном:

$ 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

Обратите внимание на другой тип, напечатанный после информации LSB.

file 5.36 ясно говорит

file5.36 фактически печатает это ясно, если исполняемый файл - ПИРОГ или нет. Например, исполняемый файл PIE выглядит так:

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

и не пирог, как:

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

Эта функция была представлена ​​в 5.33, но она просто chmod +xпроверила. До этого он просто печатался shared objectдля пирога.

В 5.34 предполагалось начать проверку более специализированных DF_1_PIEметаданных ELF, но из-за ошибки в реализации это фактически сломало вещи и показало исполняемые файлы GCC PIE как shared objects.

Я интерпретировал fileисходный код, включая ошибку, и какие именно байты формата ELF он проверяет в мельчайших подробностях по адресу: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object -instead-оф-ан-исполняемым-двоично-по-с / 55704865 # 55704865

Краткое описание поведения файла 5.36:

• если Elf32_Ehdr.e_type == ET_EXEC
  • Распечатать executable
• иначе если Elf32_Ehdr.e_type == ET_DYN
  • если присутствует DT_FLAGS_1динамическая запись раздела
    • если DF_1_PIEустановлено в DT_FLAGS_1:
      • Распечатать pie executable
    • еще
      • Распечатать shared object
  • еще
    • если файл исполняемый пользователем, группой или другими
      • Распечатать pie executable
    • еще
      • Распечатать shared object

GDB дважды запускает исполняемый файл и видит ASLR

Одна очень прямая вещь, которую вы можете сделать, это запустить исполняемый файл дважды через GDB и посмотреть, не меняется ли адрес при запуске из-за ASLR.

Я объяснил, как это сделать, подробно по адресу: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031 # 51308031

Хотя это не обязательно самое практичное решение, и оно невозможно, если вы не доверяете исполняемому файлу, но это забавно, и он в конечном итоге проверяет, что нас действительно волнует, - это если ядро ​​/ динамический загрузчик Linux изменяет местоположение исполняемого файла или не.

На Github есть скрипт bash checksec.sh для проверки свойств смягчения исполняемых файлов (включая RELRO, Stack Canary, NX bit, PIE, RPATH, RUNPATH, Fortify Source).

Запустить checksecс -f(входной файл) аргументами:

$ 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