Як перевірити, чи був компільований бінарний код Linux як незалежний від позиції код?

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

Отже: Як перевірити, чи був певний виконуваний файл складений як незалежний від позиції виконуваний файл в Linux?

Ви можете використовувати perlскрипт, що міститься в hardening-checkпакеті, доступний у Fedora та Debian (як 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 чи ні. Наприклад, виконуваний файл PIE показує:

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

а не PIE як:

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

Ця функція була введена в 5.33, але вона зробила лише просту chmod +xперевірку. До цього його просто надрукували shared objectдля PIE.

У 5.34, передбачалося почати перевірку більш спеціалізованих DF_1_PIEметаданих ELF, але через помилку у впровадженні вони фактично зламали речі та показали виконувані файли GCC PIE як shared objects.

Я інтерпретував fileвихідний код, включаючи помилку, а також саме, які байти формату ELF він перевіряє з неприємними деталями за посиланням: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object -intead-of-an-исполняемого-бінарного-згідно / 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 script checksec.sh для перевірки властивостей пом'якшення виконуваних файлів (включаючи RELRO, Stack Canary, NX біт, 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