Làm cách nào để kiểm tra xem tệp nhị phân Linux có được biên dịch thành mã độc lập vị trí không?

Gần đây tôi đã biết rằng (ít nhất là trên Fedora và Red Hat Enterprise Linux), các chương trình thực thi được biên dịch dưới dạng Thực thi độc lập vị trí (PIE) nhận được sự bảo vệ ngẫu nhiên không gian địa chỉ (ASLR) mạnh hơn.

Vậy: Làm cách nào để kiểm tra xem một tệp thực thi cụ thể có được biên dịch dưới dạng Thực thi độc lập vị trí trên Linux không?

Bạn có thể sử dụng perltập lệnh có trong hardening-checkgói, có sẵn trong Fedora và Debian (dưới dạng hardening-includes). Đọc trang wiki Debian này để biết chi tiết về những cờ biên dịch nào được kiểm tra. Đó là Debian cụ thể, nhưng lý thuyết cũng áp dụng cho Red Hat.

Thí dụ:

$ 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

Tôi đã sử dụng readelf --relocsđể kiểm tra xem thư viện tĩnh hay động là PIC trên x86-64 theo cách sau:

$ 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

Chúng tôi thấy ở đây R_X86_64_32và R_X86_64_32S. Điều này có nghĩa là mã không độc lập với vị trí. Khi tôi xây dựng lại một thư viện với -fPIC, tôi nhận được:

$ 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

Phương pháp này có thể hoạt động cho các tệp thực thi, nhưng tôi chưa sử dụng theo cách đó.

Chỉ cần sử dụng filetrên nhị phân:

$ 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

Lưu ý các loại khác nhau được in sau thông tin LSB.

file 5,36 nói rõ ràng

file5.36 thực sự in nó rõ ràng nếu thực thi là PIE hay không. Ví dụ, một tệp thực thi PIE hiển thị như:

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

và một người không PIE như:

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

Tính năng này được giới thiệu vào 5.33 nhưng nó chỉ là một chmod +xkiểm tra đơn giản . Trước đó nó chỉ in shared objectcho PIE.

Trong 5.34, nó có nghĩa là bắt đầu kiểm tra DF_1_PIEsiêu dữ liệu ELF chuyên dụng hơn , nhưng do lỗi trong quá trình triển khai, nó thực sự đã phá vỡ mọi thứ và hiển thị các tệp thực thi GCC PIE như shared objects.

Tôi đã giải thích filemã nguồn, bao gồm cả lỗi và chính xác các byte của định dạng ELF mà nó kiểm tra chi tiết rõ ràng tại: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a- Shared-object -instead-of-an-execable-binary-theo / 55704865 # 55704865

Tóm tắt nhanh về hành vi của tệp 5.36 là:

• nếu Elf32_Ehdr.e_type == ET_EXEC
  • in executable
• khác nếu Elf32_Ehdr.e_type == ET_DYN
  • nếu DT_FLAGS_1mục động phần là hiện tại
    • nếu DF_1_PIEđược đặt trong DT_FLAGS_1:
      • in pie executable
    • khác
      • in shared object
  • khác
    • nếu tập tin được thực thi bởi người dùng, nhóm hoặc người khác
      • in pie executable
    • khác
      • in shared object

GDB chạy thực thi hai lần và xem ASLR

Một điều rất trực tiếp mà bạn có thể làm là chạy hai lần thực thi thông qua GDB và xem liệu địa chỉ có thay đổi trong các lần chạy do ASLR không.

Tôi đã giải thích cách thực hiện điều đó một cách chi tiết tại: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-poseition-indeperee-executables-in-gcc-and-ld/51308031 # 51308031

Mặc dù đây không nhất thiết là giải pháp thiết thực nhất và không thể thực hiện được nếu bạn không tin tưởng vào khả năng thực thi, nhưng thật thú vị và đó là kiểm tra cuối cùng mà chúng tôi thực sự quan tâm, đó là nếu hạt nhân / trình tải động của Linux thay đổi vị trí thực thi hay không phải.

Có bash script testsec.sh trên Github để kiểm tra các thuộc tính giảm thiểu thực thi (bao gồm cả RELRO, Stack Canary, NX bit, PIE, RPATH, RUNPATH, Fortify Source).

Chạy checksecvới các -fđối số (nhập tệp):

$ 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