Bagaimana cara menguji apakah biner Linux dikompilasi sebagai kode independen posisi?

Baru-baru ini saya mengetahui bahwa (setidaknya pada Fedora dan Red Hat Enterprise Linux), program yang dapat dieksekusi yang dikompilasi sebagai Position Independent Executables (PIE) menerima perlindungan pengalamatan ruang alamat (ASLR) yang lebih kuat.

Jadi: Bagaimana saya menguji apakah executable tertentu dikompilasi sebagai Posisi Independen yang Dapat Dilakukan, di Linux?

Anda dapat menggunakan perlskrip yang terkandung dalam hardening-checkpaket, tersedia di Fedora dan Debian (as hardening-includes). Baca halaman wiki Debian ini untuk perincian tentang flag kompilasi yang diperiksa. Ini spesifik untuk Debian, tetapi teorinya juga berlaku untuk Red Hat.

Contoh:

$ 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

Saya biasa readelf --relocsmenguji apakah perpustakaan statis atau dinamis adalah PIC pada x86-64 dengan cara berikut:

$ 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

Kita lihat di sini R_X86_64_32dan R_X86_64_32S. Ini berarti bahwa kode tersebut tidak independen terhadap posisi. Ketika saya membangun kembali perpustakaan dengan -fPIC saya mendapatkan:

$ 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

Metode ini mungkin bekerja untuk executable, tetapi saya belum menggunakannya seperti itu.

Cukup gunakan filepada biner:

$ 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

Perhatikan jenis berbeda yang dicetak setelah informasi LSB.

file 5.36 mengatakannya dengan jelas

file5.36 sebenarnya mencetaknya dengan jelas jika executable adalah PIE atau tidak. Sebagai contoh, executable PIE ditampilkan sebagai:

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

dan yang non-PIE sebagai:

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

Fitur ini diperkenalkan pada 5.33 tetapi hanya melakukan chmod +xpemeriksaan sederhana . Sebelumnya hanya dicetak shared objectuntuk PIE.

Pada 5.34, itu dimaksudkan untuk mulai memeriksa DF_1_PIEmetadata ELF yang lebih terspesialisasi , tetapi karena bug dalam implementasi itu benar-benar memecahkan banyak hal dan menunjukkan executable GCC PIE sebagai shared objects.

Saya telah menafsirkan filekode sumber, termasuk bug, dan byte mana dari format ELF yang diperiksa dalam detail yang luar biasa di: https://stackoverflow.com/questions/34519521/why-does-gcc-create-a- Shared-object -bukan-of-an-executable-binary-sesuai-ke / 55704865 # 55704865

Ringkasan singkat perilaku file 5,36 adalah:

• jika Elf32_Ehdr.e_type == ET_EXEC
  • mencetak executable
• lain jika Elf32_Ehdr.e_type == ET_DYN
  • jika DT_FLAGS_1entri bagian dinamis hadir
    • jika DF_1_PIEdiatur DT_FLAGS_1:
      • mencetak pie executable
    • lain
      • mencetak shared object
  • lain
    • jika file dapat dieksekusi oleh pengguna, grup, atau orang lain
      • mencetak pie executable
    • lain
      • mencetak shared object

GDB menjalankan executable dua kali dan melihat ASLR

Satu hal yang sangat langsung yang dapat Anda lakukan adalah menjalankan executable dua kali melalui GDB dan melihat apakah alamat berubah di seluruh run karena ASLR.

Saya telah menjelaskan bagaimana melakukannya secara rinci di: https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld/51308031 # 51308031

Walaupun ini tidak selalu merupakan solusi yang paling praktis dan tidak mungkin jika Anda tidak mempercayai yang dapat dieksekusi, itu menyenangkan dan melakukan pemeriksaan akhir yang benar-benar kami pedulikan, yaitu jika kernel Linux / dynamic loader mengubah lokasi yang dapat dieksekusi atau tidak.

Ada bash script checksec.sh di Github untuk memeriksa properti mitigasi yang dapat dieksekusi (termasuk RELRO, Stack Canary, NX bit, PIE, RPATH, RUNPATH, Fortify Source).

Jalankan checksecdengan -fargumen (input file):

$ 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