Linuxバイナリが位置独立コードとしてコンパイルされたかどうかをテストするにはどうすればよいですか？

最近（少なくともFedoraとRed Hat Enterprise Linuxで）、Position Independent Executables（PIE）としてコンパイルされた実行可能プログラムが、より強力なアドレス空間ランダム化（ASLR）保護を受けることを学びました。

だから：Linuxで特定の実行可能ファイルが位置非依存実行可能ファイルとしてコンパイルされたかどうかをテストするにはどうすればよいですか？

パッケージにperl含まれているスクリプトを使用できます。このスクリプトは、FedoraおよびDebian（as ）hardening-checkで利用できます。チェックされるコンパイルフラグの詳細については、このDebian wikiページをお読みください。Debian固有ですが、理論はRed Hatにも当てはまります。hardening-includes

例：

$ 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次の方法で、x86-64で静的または動的ライブラリがPICかどうかをテストするために使用しました。

$ 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_PIEELFメタデータのチェックを開始することを意図していましたが、実装のバグにより、実際に問題が発生し、GCC PIE実行可能ファイルをとして示しましたshared objects。

fileバグを含むソースコードと、それが耐え難いほど詳細にチェックするELF形式のバイトを正確に解釈しました：https : //stackoverflow.com/questions/34519521/why-does-gcc-create-a-shared-object -代わりに、実行可能なバイナリ一致/ 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は実行可能ファイルを2回実行し、ASLRを参照

実行できる非常に直接的なことの1つは、GDBを介して実行可能ファイルを2回実行し、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ビット、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