จะทดสอบว่าไบนารีลินุกซ์ได้รับการรวบรวมเป็นรหัสอิสระหรือไม่?

เมื่อเร็ว ๆ นี้ฉันได้เรียนรู้ว่า (อย่างน้อยใน Fedora และ Red Hat Enterprise Linux) โปรแกรมปฏิบัติการที่คอมไพล์เป็น Position Independent Executables (PIE) ได้รับการปกป้องพื้นที่แอดเดรสแบบสุ่ม (ASLR) ที่แข็งแกร่งยิ่งขึ้น

ดังนั้น: ฉันจะทดสอบได้อย่างไรว่ามีการประมวลผลไฟล์ใดไฟล์หนึ่งที่เรียกว่า Position Independent Executable บน Linux หรือไม่?

คุณสามารถใช้perlสคริปต์ที่มีอยู่ในhardening-checkแพ็คเกจซึ่งมีอยู่ใน FedoraและDebian (as hardening-includes) อ่านหน้าวิกิพีเดีย Debian นี้เพื่อดูรายละเอียดเกี่ยวกับการตรวจสอบสถานะการคอมไพล์ มันเป็นเรื่องเฉพาะของเดเบียน แต่ทฤษฎีนี้ใช้กับเรดแฮทเช่นกัน

ตัวอย่าง:

$ 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

วิธีนี้อาจใช้กับ executables ได้ แต่ฉันไม่ได้ใช้วิธีนี้

เพียงใช้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

และไม่ใช่พาย - หนึ่ง:

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เอลฟ์เมตาดาต้า แต่เนื่องจากข้อผิดพลาดในการดำเนินการก็สิ่งที่ยากจนจริงและแสดงให้เห็น executables GCC shared objectsพายเป็น

ฉันได้ตีความfileซอร์สโค้ดรวมถึงข้อผิดพลาดและจำนวนไบต์ของรูปแบบเอลฟ์ที่ตรวจสอบในรายละเอียดที่ระรัวทุกข์ทรมานที่: 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-the-fpie-option-for-position-indrants-executables-in-gcc-and-ld/51308031 # 51308031

แม้ว่านี่จะไม่ใช่วิธีแก้ปัญหาที่ใช้งานได้จริงและเป็นไปไม่ได้ถ้าคุณไม่เชื่อใจในปฏิบัติการ แต่มันก็สนุกและมันก็เป็นการตรวจสอบขั้นสุดยอดที่เราใส่ใจจริงๆซึ่งถ้าเคอร์เนล Linux / ตัวโหลดแบบไดนามิกเปลี่ยนตำแหน่งปฏิบัติการหรือ ไม่.

มีสคริปต์ทุบตีchecksec.sh บน Githubเพื่อตรวจสอบคุณสมบัติการลดการปฏิบัติการ (รวมถึง 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