如何测试 Linux 二进制文件是否被编译为位置无关代码？

Question

我最近了解到（至少在 Fedora 和 Red Hat Enterprise Linux 上），编译为位置独立可执行文件 (PIE) 的可执行程序会获得更强的地址空间随机化 (ASLR) 保护。

那么：如何在 Linux 上测试特定的可执行文件是否被编译为位置无关的可执行文件？

Answer 1

您可以使用Fedora和Debian 中提供perl的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

Answer 2

只需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 信息之后打印的不同类型。

Answer 3

我曾经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

这种方法可能适用于可执行文件，但我没有这样使用过。

Answer 4

file 5.36 说的清楚

file如果可执行文件是 PIE，5.36 实际上会清楚地打印出来。例如，一个 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 -instead-of-an-executable-binary-according-to/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 内核/动态加载程序是否更改了可执行文件位置或不是。

Answer 5

Github 上有 bash 脚本checksec.sh来检查可执行文件缓解属性（包括 RELRO、Stack Canary、NX bit、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