深入了解GOT,PLT和动态链接

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

之前几篇介绍exploit的文章, 有提到return-to-plt的技术. 当时只简单介绍了

GOT和PLT表的基本作用和他们之间的关系, 所以今天就来详细分析下其具体的工作过程.

本文所用的依然是Linux x86 64位环境, 不过分析的ELF文件是32位的(-m32).

大局观

首先, 我们要知道, GOT和PLT只是一种重定向的实现方式. 所以为了理解他们的作用,

就要先知道什么是重定向, 以及我们为什么需要重定向.

重定向(relocations), 简单来说就是二进制文件中留下的"坑", 预留给外部变量或函数.

这里的变量和函数统称为符号(symbols). 在编译期我们通常只知道外部符号的类型

(变量类型和函数原型), 而不需要知道具体的值(变量值和函数实现). 而这些预留的"坑",

会在用到之前(链接期间或者运行期间)填上. 在链接期间填上主要通过工具链中的连接器,

比如GNU链接器ld; 在运行期间填上则通过动态连接器, 或者说解释器(interpreter)来实现.

比如:

$ file /bin/ls /bin/ls: 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]=3c233e12c466a83aa9b2094b07dbfaa5bd10eccd, stripped

可以看到/bin/ls的解释器是/lib64/ld-linux-x86-64.so.2.

在本文中, 用下面两个简单的c文件来进行说明, 首先是symbol.c, 定义了一个函数变量:

// symbol.c int my_var = 42; int my_func(int a, int b) { return a + b; }

编译为动态链接库:

gcc -g -m32 -masm=intel -shared -fPIC symbol.c -o libsymbol.so

另一个文件是main.c, 调用该动态链接库:

// main.c int var = 10; extern int my_var; extern int my_func(int, int);int main() { int a, b; a = var; b = my_var; return my_func(a, b); }

分别编译两个版本, 位置相关的main和位置无关的main_pi, 具体会稍后解释.

# 位置相关 gcc -g -m32 -masm=intel -L. -lsymbol -no-pie -fno-pic main.c libsymbol.so -o main # 位置无关 gcc -g -m32 -masm=intel -L. -lsymbol main.c libsymbol.so -o main_pi

符号表

函数和变量作为符号被存在可执行文件中, 不同类型的符号又聚合在一起, 称为符号表.

有两种类型的符号表, 一种是常规的(.symtab和.strtab), 另一种是动态的(.dynsym和.dynstr),

他们都在对应的section中, 以main为例:

$ readelf -S ./main [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 5] .dynsym DYNSYM 080481ec 0001ec 0000b0 10 A 6 1 4 [ 6] .dynstr STRTAB 0804829c 00029c 000085 00 A 0 0 1 ... [33] .symtab SYMTAB 00000000 00120c 000490 10 34 52 4 [34] .strtab STRTAB 00000000 00169c 0001e1 00 0 0 1

常规的符号表通常只在调试时用到. 我们平时用的strip命令删除的就是该符号表;

而动态符号表则是程序执行时候真正会查找的目标.

位置无关代码

刚刚编译动态链接库时指定了-fPIC, 编译main_pi时(默认)指定了-pie, 其实都是为了

生成位置无关的代码, 那么什么是位置无关? 为什么要位置无关?

我们执行一个可执行文件的时候, 其实是先将磁盘上的该文件读取到内存中, 然后再执行.

而每个进程都有自己的虚拟内存空间, 以32位程序为例, 就有2^32=4GB的寻址空间, 从0x00000000

到0xffffffff. 这里暂时不深入介绍, 只需要知道虚拟内存最终会通过页表映射到物理内存中.

当然, 如果你感兴趣, 强烈推荐你去看下Gustavo Duarte的这篇文章.

按照链接器的约定, 32位程序会加载到0x08048000这个地址中(为什么?),

所以我们写程序时, 可以以这个地址为基础, 对变量进行绝对地址寻址. 以main为例:

$ readelf -S ./main | grep "\.data" [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [25] .data PROGBITS 0804a014 001014 00000c 00 WA 0 0 4

.data部分在可执行文件中的偏移量为0x1014, 那么加载到虚拟内存中的地址应该是

0x8048000+0x1014=0x804a14, 正好和显示的结果一样. 再看看main函数的汇编代码:

$ objdump -d ./main | grep "<main>" -A 15 080484db <main>: 80484db:8d 4c 24 04 lea ecx,[esp+0x4] 80484df:83 e4 f0 and esp,0xfffffff0 80484e2:ff 71 fc push DWORD PTR [ecx-0x4] 80484e5:55 push ebp 80484e6:89 e5 mov ebp,esp 80484e8:51 push ecx 80484e9:83 ec 14 sub esp,0x14 80484ec:a1 1c a0 04 08 mov eax,ds:0x804a01c 80484f1:89 45 f4 mov DWORD PTR [ebp-0xc],eax 80484f4:a1 20 a0 04 08 mov eax,ds:0x804a020 80484f9:89 45 f0 mov DWORD PTR [ebp-0x10],eax 80484fc:83 ec 08 sub esp,0x8 80484ff:ff 75 f0 push DWORD PTR [ebp-0x10] 8048502:ff 75 f4 push DWORD PTR [ebp-0xc] 8048505:e8 a6 fe ff ff call 80483b0 <my_func@plt>

注意80484ec这行, 可以看到获取变量直接用的绝对地址0x804a01c(正好在.data范围内).

用gdb(在启动程序之前)可看到该地址正是var变量的地址, 且初始值为10:

$ gdb ./main (gdb) x/xw 0x804a01c 0x804a01c <var>:0x0000000a

按绝对地址寻址, 对可执行文件来说不是什么大问题, 因为一个进程只有一个主函数.

可对于动态链接库而言就比较麻烦, 如果每个.so文件都要求加载到某个绝对地址,

那简直是个噩梦, 因为你无法保证不和别人的.so加载地址冲突. 所以就有了位置无关代码的概念.

以位置无关的方式编译的main_pi, 来看看其相关信息:

$ readelf -S ./main_pi | grep "\.data" [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [25] .data PROGBITS 00002014 001014 00000c 00 WA 0 0 4

偏移量还是固定的, 但Addr部分不再是绝对地址. 也就是说程序可以加载到虚拟内存的任意位置.

听起来很神奇? 其实实现很简单, 继续看看main()的汇编:

$ objdump -d main_pi | grep "<main>" -A 20 00000660 <main>: 660:8d 4c 24 04 lea ecx,[esp+0x4] 664:83 e4 f0 and esp,0xfffffff0 667:ff 71 fc push DWORD PTR [ecx-0x4] 66a:55 push ebp 66b:89 e5 mov ebp,esp 66d:53 push ebx 66e:51 push ecx 66f:83 ec 10 sub esp,0x10 672:e8 36 00 00 00 call 6ad <__x86.get_pc_thunk.ax> 677:05 89 19 00 00 add eax,0x1989 67c:8b 90 1c 00 00 00 mov edx,DWORD PTR [eax+0x1c] 682:89 55 f4 mov DWORD PTR [ebp-0xc],edx 685:8b 90 f0 ff ff ff mov edx,DWORD PTR [eax-0x10] 68b:8b 12 mov edx,DWORD PTR [edx] 68d:89 55 f0 mov DWORD PTR [ebp-0x10],edx 690:83 ec 08 sub esp,0x8 693:ff 75 f0 push DWORD PTR [ebp-0x10] 696:ff 75 f4 push DWORD PTR [ebp-0xc] 699:89 c3 mov ebx,eax 69b:e8 20 fe ff ff call 4c0 <my_func@plt>

注意67c~682处, 和之前的区别是这次通过eax寄存器来对变量进行寻址, 不过有个__x86.get_pc_thunk.ax函数,

其作用很简单, 在之前的IOLI-crackme0x06-0x09 writeup中有简单介绍过:

objdump -d main_pi | grep "__x86.get_pc_thunk.ax" -A 2 000006ad <__x86.get_pc_thunk.ax>: 6ad:8b 04 24 mov eax,DWORD PTR [esp] 6b0:c3 ret

作用就是把esp(即返回地址)的值保存在eax(PIC寄存器)中, 在接下来寻址用.

有人可能好奇, 为什么这么麻烦, 直接用eip寄存器不就行了?

其实64位下就是这样操作的! 不过32位下不支持直接访问PC寄存器,

所以就多了一层间接的函数调用.

扯远了, 经过672和677两条指令后, eax的值将等于相对当前PC指针的固定位移.

只看静态代码的话, 可知eax=0x677+0x1989=0x2000, 而这个地址是...

$ readelf -S ./main_pi | grep 2000 -C 1 [23] .got PROGBITS 00001fe4 000fe4 00001c 04 WA 0 0 4 [24] .got.plt PROGBITS 00002000 001000 000014 04 WA 0 0 4 [25] .data PROGBITS 00002014 001014 00000c 00 WA 0 0 4

.got.plt的起始地址! 这个section我们接下来会说到. 现在先看汇编的67c处,

通过eax+0x1c=0x201c获取了变量的值, 这个地址已经进入到了.data之中:

$ gdb ./main_pi (gdb) x/xw 0x2000+0x1c 0x201c <var>:0x0000000a

所以, 位置无关代码实际上就是通过运行时PC指针的值来找到代码所引用的

其他符号的位置, 不管二进制文件被加载到哪个位置, 都可以正确执行.

缺点

位置无关代码的缺点是, 在执行时要保留一个寄存器作为PIC寄存器,

有可能会导致寄存器不够用; 还有一个缺点是运行时要经过计算来获得

符号的地址, 从某种方面来说也对运行速度有点小影响.

优点

位置无关代码的优点就跟他名字一样, 可以保证加载到任意地址都能

正常执行, 这也是每个动态链接库都需要支持的.

动态链接

刚刚我们说位置无关代码的时候有看到, PIC寄存器为.got.plt的地址, 然后按偏移量

来获取变量. 上面只看了eax+0x1c即从.data段获取的内容(var), 还有一个参数是通过

eax-0x10即.got段之中获取的my_var. 后者是在symbol.c中定义的, 所以其内容在编译期

未知. 如果是静态链接, 则可以在链接时解析符号的值. 我们这里主要考虑动态链接的情况.

一些定义

上面说了很多.got, .plt啥的, 那么这些section到底是做什么用的呢. 其实这些都是

链接器(或解释器, 下面统称为链接器)在执行重定向时会用到的部分, 先来看他们的定义.

.got

这是我们常说的GOT, 即Global Offset Table, 全局偏移表. 这是链接器在执行链接时

实际上要填充的部分, 保存了所有外部符号的地址信息.

不过值得注意的是, 在i386架构下, 除了每个函数占用一个GOT表项外，GOT表项还保留了

3个公共表项, 每项32位(4字节), 保存在前三个位置, 分别是:

got[0]: 本ELF动态段(.dynamic段)的装载地址
got1: 本ELF的link_map数据结构描述符地址
got2: _dl_runtime_resolve函数的地址

其中, link_map数据结构的定义如下:

struct link_map { /* Shared library's load address. */ ElfW(Addr) l_addr; /* Pointer to library's name in the string table. */ char *l_name; /* Dynamic section of the shared object. Includes dynamic linking info etc. Not interesting to us. */ ElfW(Dyn) *l_ld; /* Pointer to previous and next link_map node. */ struct link_map *l_next, *l_prev; };

.plt

这也是我们常说的PLT, 即Procedure Linkage Table, 进程链接表. 这个表里包含了一些代码,

用来(1)调用链接器来解析某个外部函数的地址, 并填充到.got.plt中, 然后跳转到该函数; 或者

(2)直接在.got.plt中查找并跳转到对应外部函数(如果已经填充过).

.got.plt

.got.plt相当于.plt的GOT全局偏移表, 其内容有两种情况, 1)如果在之前查找过该符号,

内容为外部函数的具体地址. 2)如果没查找过, 则内容为跳转回.plt的代码, 并执行查找.

至于为什么要这么绕, 后面会说明具体原因.

.plt.got

说实话, 这部分我还不知道有什么具体作用, 可能是为了对称吧. 逃)

对于我们将要研究的main程序, 这些段的地址如下:

$ readelf -S main | egrep '.plt|.got' [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [12] .plt PROGBITS 080483a0 0003a0 000030 04 AX 0 0 16 [13] .plt.got PROGBITS 080483d0 0003d0 000008 00 AX 0 0 8 [23] .got PROGBITS 08049ffc 000ffc 000004 04 WA 0 0 4 [24] .got.plt PROGBITS 0804a000 001000 000014 04 WA 0 0 4

变量

有了上面的定义, 先看变量的解析过程, 以main为例(位置相关的),

查看需要重定向的符号:

$ readelf --relocs ./mainRelocation section '.rel.dyn' at offset 0x358 contains 2 entries: Offset Info Type Sym.Value Sym. Name 08049ffc 00000206 R_386_GLOB_DAT 00000000 __gmon_start__ 0804a020 00000605 R_386_COPY 0804a020 my_varRelocation section '.rel.plt' at offset 0x368 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0804a00c 00000107 R_386_JUMP_SLOT 00000000 my_func 0804a010 00000307 R_386_JUMP_SLOT 00000000 __libc_start_main@GLIBC_2.0

my_var的地址为0804a020, 注意这里实际上是.bss段, 如下:

$ readelf -S main | grep 0804a020 -B 2 [24] .got.plt PROGBITS 0804a000 001000 000014 04 WA 0 0 4 [25] .data PROGBITS 0804a014 001014 00000c 00 WA 0 0 4 [26] .bss NOBITS 0804a020 001020 000008 00 WA 0 0 4

因为main.c里只是声明变量而且没初始化, 在链接前并不知道是否在外部定义.

同时, 该变量的值一开始是不知道的, 我们可以通过gdb来验证:

(gdb) x/dw 0x0804a020 0x804a020 <my_var>:0

显示值为0, 但实际上在symbol.c中定义了其值为42, 启动前我们先在这里下个观察点,

看看究竟是什么时候加载进去的:

(gdb) set environment LD_LIBRARY_PATH=. (gdb) watch -l *0x804a020 Hardware watchpoint 1: -location *0x804a020 (gdb) run Starting program: /home/pan/project/cFile/shared_library/plt/main Hardware watchpoint 1: -location *0x804a020Old value = 0 New value = 42 0xf7ff2e08 in ?? () from /lib/ld-linux.so.2 (gdb) x/xd 0x804a020 0x804a020 <my_var>:42

所以, 确实是链接器/lib/ld-linux.so.2负责填充了该变量的内容.

而且是在程序运行之前就完成了符号解析.

函数

接下来看看外部函数符号. 外部函数的内容(指令)也是像变量一样在

程序运行之前完成填充的吗? 其实这理论上是可以的, 事实上稍有不同.

静态分析

我们先从汇编看看main是如何调用my_func()函数的:

(gdb) disassemble main Dump of assembler code for function main: 0x080484db <+0>:lea ecx,[esp+0x4] 0x080484df <+4>:and esp,0xfffffff0 0x080484e2 <+7>:push DWORD PTR [ecx-0x4] 0x080484e5 <+10>:push ebp 0x080484e6 <+11>:mov ebp,esp 0x080484e8 <+13>:push ecx 0x080484e9 <+14>:sub esp,0x14 0x080484ec <+17>:mov eax,ds:0x804a01c 0x080484f1 <+22>:mov DWORD PTR [ebp-0xc],eax 0x080484f4 <+25>:mov eax,ds:0x804a020 0x080484f9 <+30>:mov DWORD PTR [ebp-0x10],eax 0x080484fc <+33>:sub esp,0x8 0x080484ff <+36>:push DWORD PTR [ebp-0x10] 0x08048502 <+39>:push DWORD PTR [ebp-0xc] 0x08048505 <+42>:call 0x80483b0 <my_func@plt>

调用的地址是0x80483b0, 在.plt段中, 之前说了PLT的定义, 现在具体看看里面的内容:

(gdb) disassemble 0x80483b0 Dump of assembler code for function my_func@plt: 0x080483b0 <+0>:jmp DWORD PTR ds:0x804a00c 0x080483b6 <+6>:push 0x0 0x080483bb <+11>:jmp 0x80483a0 End of assembler dump.

首先是跳转到*0x804a00c, 该地址在.got.plt之中, 之前说了, .got.plt相当于

.plt的GOT, 而GOT本身相当于一个数组, 看看该"数组"的内容:

(gdb) x/4xw 0x804a00c 0x804a00c:0x080483b60x080483c60x000000000x00000000

所以, 0x080483b0这里的跳转, 相当于跳转到0x080483b6, 即下一条指令!

这个多余的跳转先打个问号, 把流程走完再说. 接着, 跳转到了0x80483a0,

这个地址, 是.plt的起始地址, 这里的指令如下:

(gdb) x/2i 0x080483a0 0x80483a0:push DWORD PTR ds:0x804a004 0x80483a6:jmp DWORD PTR ds:0x804a008

跳转到了0x804a008, 在前面我们知道0x804a000是.got.plt的地址,

而在上一节的定义中, 也知道了.got表前三项的作用, 0x804a008

正好是第三项got2, 即_dl_runtime_resolve函数的地址. 0x804a004

则是调用该函数的参数, 且值为got1, 即本ELF的link_map的地址.

如下, 在进程未启动前, got1和got2都为0, 在启动时由链接器装填:

(gdb) x/4xw 0x804a000 0x804a000:0x08049f0c0x000000000x000000000x080483b6

因此, 实际上(第一次)调用my_func@plt就相当于调用了

_dl_runtime_resolve((link_map *)m, 0)! 其中link_map提供了运行时的必要信息,

而0则是my_func函数的偏移(在my_func@plt中push 0x0).

该函数定义在glibc/sysdeps/i386/dl-trampoline.S中, 关键代码如下:

_dl_runtime_resolve: cfi_adjust_cfa_offset (8) pushl %eax # Preserve registers otherwise clobbered. cfi_adjust_cfa_offset (4) pushl %ecx cfi_adjust_cfa_offset (4) pushl %edx cfi_adjust_cfa_offset (4) movl 16(%esp), %edx # Copy args pushed by PLT in register. Note movl 12(%esp), %eax # that `fixup' takes its parameters in regs. call _dl_fixup # Call resolver. popl %edx # Get register content back. cfi_adjust_cfa_offset (-4) movl (%esp), %ecx movl %eax, (%esp) # Store the function address. movl 4(%esp), %eax ret $12 # Jump to function address.

从注释里也可以看出来, 该函数实际上做了两件事:

1)解析出my_func的地址并将值填入.got.plt中.
2)跳转执行真正的my_func函数.

动态分析

上面虽然用了gdb, 但程序并未运行, 只是分析静态的汇编代码, 为了验证上面的说法,

我们需要进行动态分析. 接着上面的分析, 我们这次在调用_dl_runtime_resolve

前打上断点. 还记得之前在my_func@plt中一次多余的跳转吗? 当时打了个问号,

现在就来解答这个疑问. 在0x804a00c处打上观察点并运行:

(gdb) b *0x80483a6 (gdb) watch -l *0x804a00c (gdb) run Breakpoint 1, 0x080483a6 in ?? () (gdb) x/xw 0x804a00c 0x804a00c:0x080483b6 (gdb) continue Hardware watchpoint 1: -location *0x804a00cOld value = 0x80483b6 New value = 0xf7fcf4f0 0xf7fe8113 in ?? () from /lib/ld-linux.so.2 (gdb) disassemble 0xf7fcf4f0 Dump of assembler code for function my_func: ...

可以看到, 在_dl_runtime_resolve之前, 0x804a00c地址的值为0x080483b6,

即下一条指令. 而运行之后, 该地址的值变为0xf7fcf4f0, 正是my_func的加载地址!

也就是说, my_func函数的地址是在第一次调用时, 才通过连接器动态解析并加载到

.got.plt中的. 而这个过程, 也称之为延时加载或者惰性加载.

延时加载

延时加载的好处是, 只有当外部函数被调用了才会去进行动态加载, 降低程序的启动时间.

而第一次加载之后, 对于后续的调用就可以直接跳转而不需要再去加载.

这样一方面减少了进程的启动开销, 另一方面也不会造成太多额外的运行时开销,

所以延时加载在当今也是广泛应用的一个思想. 对于位置无关的代码,

延时加载的过程也是类似的, 并没有太大区别. 读者可以自己去追踪一下.

ret2libc

我在栈溢出攻击和缓解中有提到, ret2libc的使用场景是当栈不可执行时,

直接跳转到libc.so某个函数的地址, 比如system(), 来获得shell.

不过前提是要知道libc.so在运行时的加载地址. 如果没启用ASLR, 这个地址是固定的.

启用ASLR之后就会有个随机的偏移, 如下:

根据ASLR随机化的等级, 会在栈和内核空间之间, 栈和动态库(mmap)之间, 堆和.bss之间

都分别加上随机的偏移. 所以此时libc.so的地址是未知的, ret2libc攻击也就得到缓解了.

ret2plt

但是, 虽然ASLR随机化了上面的几个地址, 在位置相关代码的情况下, PLT的地址还是确定的!

所以如果没有启用位置无关代码的话, 即使启用了ASLR, 我们还是可以通过PLT来跳转到libc

中的函数执行, 这种攻击方法就叫ret2plt.

除此之外, 因为.got.plt是有写入权限的, 攻击者还可以通过代码中的内存破坏漏洞对

.got.plt段进行覆盖, 从而间接控制代码的执行流程.

攻击缓解

ret2plt这么屌, 就没人管管吗? 当然有! 一个最简单的办法就是启用位置无关代码,

不过就算可执行程序的代码是位置无关的, 链接器还是有可能将其加载到老地方.

一个更正确的缓解措施是RELRO即relocations read-only.

RELRO是链接器的一个选项, 可以通过man ld来查看. 主要作用就是令重定向只读.

有两个RELRO的等级, 部分RELRO和完全RELRO.

部分RELRO(由ld -z relro启用):

将.got段映射为只读(但.got.plt还是可以写)
重新排列各个段来减少全局变量溢出导致覆盖代码段的可能性.

完全RELRO(由ld -z relro -z now启用)

执行部分RELRO的所有操作.
让链接器在链接期间(执行程序之前)解析所有的符号, 然后去除.got的写权限.
将.got.plt合并到.got段中, 所以.got.plt将不复存在.

因此可以看到, 只有完全RELRO才能防止攻击者覆盖.got.plt, 因为在链接期间

就对程序符号进行了解析. 当然同时也放弃了延时绑定所带来的好处.

总结

为了灵活利用虚拟内存空间, 所以编译器可以产生位置无关的代码.

可执行文件可以是位置无关的, 也可以是位置相关的, 动态链接库

绝大多数都是位置无关的. GOT表可写不可执行, PLT可执行不可写,

他们相互作用来实现函数符号的延时绑定. ASLR并不随机化PLT部分,

所以对ret2plt攻击没有直接影响. 为防止恶意修改got, 链接器提供了RELRO

选项, 去除got的写权限, 但也牺牲了延时绑定带来的好处.