PWN——ret2dl_resolve
ret2dl_resolve是栈溢出中，底层且高级的一种利用手段，这里特此做一篇笔记学习一下。
个人认为，要掌握这种方法，自己去写demo来多次调试分析是不二法门。
demo是XDCTF 2015的一道例题。
#include<unistd.h> #include<stdio.h> #include<string.h> void vuln() { char buf[100]; setbuf(stdin,buf); read(0,buf,256); } int main() { char buf[100]="Welcome to XDCTF2015~! "; setbuf(stdout,buf); write(1,buf,strlen(buf)); vuln(); return 0; }
gcc -g -o XDCTF2015 -m32 -fno-stack-protector XDCTF2015.c
为了方便调试，也可以提前关闭一下aslr
//关闭aslr echo 0 > /proc/sys/kernel/randomize_va_space //开启aslr echo 2 > /proc/sys/kernel/randomize_va_space
1.ELF文件前置知识
ELF可执行文件由ELF头部，程序头部表和其对应的段，节头部表和其对应的节组成。如果一个可执行文件参与动态链接，它的程序头部将包含类型为PT_DYNAMIC段。PT_DYNAMIC段中包含很多在动态链接中所需要的节。每个节都是一个相应的结构体数组。
借助readelf，我们可以分析这些节中的信息。readelf -d命令可以显示PT_DYNAMIC段中的信息。
下图是Bamboofox的社课中的图片，标注了几个漏洞利用相关的节
JMPREL节中存放了动态链接中的重定位信息
有.rel.plt节和.rel.dyn节。.rel,plt用于函数重定位，.rel.plt节用于变量重定位。
.rel.plt节相关的ELF32_REL结构如下：
typedef struct { Elf32_Addr r_offset; // 对于可执行文件，此值为虚拟地址 Elf32_Word r_info; // 符号表索引 } Elf32_Rel; #define ELF32_R_SYM(info) ((info)>>8) #define ELF32_R_TYPE(info) ((unsigned char)(info)) #define ELF32_R_INFO(sym, type) (((sym)<<8)+(unsigned char)(type))
/*
r_offset是该函数在.got.plt中的地址。
ELF32_R_SYM(Elf32_Rel->r_info)=(Elf32_Rel->r_info)>>8
SYMTAB节中包含了动态链接符号表。
.dynsym节相关的Elf32_Sym节构如下:
typedef struct { Elf32_Word st_name; // Symbol name(string tbl index) Elf32_Addr st_value; // Symbol value Elf32_Word st_size; // Symbol size unsigned char st_info; // Symbol type and binding unsigned char st_other; // Symbol visibility under glibc>=2.2 Elf32_Section st_shndx; // Section index } Elf32_Sym;
注：为了表示动态链接这些模块之间的符号导入导出关系，ELF专门有一个叫做动态符号表的段来保存这些信息，这个段叫做“.dynsym”段，动态符号表只保存了与动态链接相关的符号，对于那些模块内部的符号，比如模块私有变量则不保存。
STRTAB节中包含了动态链接的字符串。这个节以"x00"结尾，中间每个字符串也以"x00"间隔。
2.延迟绑定技术
程序在执行前，如果对整个动态链接库函数进行符号解析的话，是非常浪费资源的，因为一个程序不可能调用动态链接库中所有的函数。我们最好能做到只对用到的函数进行函数解析，这样可以大大提高文件链接的效率，加快程序的启动速度。
这时候，就出现了延迟绑定技术，我们通过plt表（过程链接表），在第一次调用函数的时候，来确定函数的地址，把函数的实际地址存储在got表相对的偏移处。
试想一下，在这个过程中，当我们第一次调用函数，要向got表写入函数真实地址的时候，我们是不是需要一个管理的工具？这个管理的工具就是_dl_runtime_resolve()函数。函数需要两个参数，一个是要被绑定的函数所在的模块，一个是要被绑定函数的符号名。
函数原型：_dl_runtime_resolve(link_map,reloc_arg)
注：got表实际上是分为.got表和got.plt表，got.plt表（全局函数偏移表）中存放的是动态链接库函数，.got表（全局变量偏移表）里面的偏移主要是全局变量。我们在这里讨论的是got.plt表。
.got.plt表的前三项的含义分别如下:
1.got[0],第一项保存的是".dynamic"段的地址，这个段描述了本模块动态链接相关的信息；
2.got[1],第二项保存的是本模块的ID；
3.got[2],第三项保存的是_dl_runtime_resolve()函数的地址。
lazy binding是通过plt表和got表之间巧妙的代码跳转实现的，我们通过例子来研究一下。
一个简单的demo，在gdb下用info function查看他的函数信息，看到了plt表中函数的地址。
然后查看plt表的汇编代码
以read函数为例，他这里有三条指令
jmp DWORD PTR[ebx+0x10] push 0x8 jmp 0x56556020
jmp这里表示一个跳转，综合我们上面说的，它应该是跳转到了read函数在got.plt表的偏移处，但是这里是[ebx+0x10]。我们来看一下ebx寄存器中存储的值是多少。
ebx中存储的值是0x56559000，那么我们看一下0x56559000+0x10地址处存储着什么。
0x56559010处确实是read@got.plt的地址，说明我们的猜想是正确的。我们同时看一下这里存储的值，可以看出，这里存储的是前面read函数中push 8在plt表的地址，说明跳转到got表之后，got表并没有实际地址，这时候，程序又跳转回plt表的下一条指令处执行。
这里的push 8又是什么呢，我们这里先猜测一下：8应该是read函数对应的Elf32_Rel结构体在.rel.plt节中的相对偏移。
执行完push 8之后，执行下一条语句:jmp 0x56556020。
我们现在回忆一下前面提到的_dl_runtime_resolve()函数，它有两个参数，link_map和reloc_arg。
第一条指令是将[ebx+0x4]入栈，第二条指令是跳转到0x56559000+0x8地址处。0x56559000+0x8存放的是_dl_runtime_resolve函数的地址。
算上前面的push的参数，正好push了两个参数，按照参数入栈的顺序，我们知道[ebx+0x4]就是link_map的指针，0x8就是reloc_arg的偏移。这时候，填入的正好是got表项的前三项，got[0]是0x8（reloc_arg用来计算函数重定位的入口），这个参数就是Elf_Rel条目在重定位表.rel.plt段中对应当前请求函数的偏移，动态链接器将这个值加上.rel.plt的基地址来得到目标Elf_Rel结构的绝对地址；got[1]是link_map；got[2]是_dl_runtime_resolve函数的入口地址。
_dl_runtime_resolve是在glibc-2.23/sysdeps/i386/dl-trampoline.S中用汇编实现的。调用_dl_fixup函数（call 0xf7fe37f0），通过寄存器传参。_dl_fixup是在glibc-2.23/elf/dl_runtime.c实现的。
DL_FIXUP_VALUE_TYPE attribute_hidden __attribute ((noinline)) ARCH_FIXUP_ATTRIBUTE _dl_fixup ( # ifdef ELF_MACHINE_RUNTIME_FIXUP_ARGS ELF_MACHINE_RUNTIME_FIXUP_ARGS, # endif struct link_map *l, ElfW(Word) reloc_arg) { // 分别获取动态链接符号表和动态链接字符串表的基址 const ElfW(Sym) *const symtab = (const void *) D_PTR (l, l_info[DT_SYMTAB]); const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]); // 通过参数 reloc_arg 计算重定位入口，这里的 DT_JMPREL 即 .rel.plt，reloc_offset 即 reloc_arg
//DT_JMPREL存放着.rel.plt节的地址，.rel.plt是Elf32_Rel结构体数组 const PLTREL *const reloc = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset); // 根据函数重定位表中的动态链接符号表索引，即 reloc->r_info，获取函数在动态链接符号表中对应的条目 const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)]; const ElfW(Sym) *refsym = sym; void *const rel_addr = (void *)(l->l_addr + reloc->r_offset); lookup_t result; DL_FIXUP_VALUE_TYPE value; /* Sanity check that we're really looking at a PLT relocation. */ assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT);
/*Elf32_R_SYM(Elf32_Rel->r_info)=(Elf32_Rel->r_info)>>8*/
/*eg:Elf32_R_TYPE(0x607)=7*/ /* Look up the target symbol. If the normal lookup rules are not used don't look in the global scope. */
if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0) { const struct r_found_version *version = NULL; if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL) { const ElfW(Half) *vernum = (const void *) D_PTR (l, l_info[VERSYMIDX (DT_VERSYM)]); ElfW(Half) ndx = vernum[ELFW(R_SYM) (reloc->r_info)] & 0x7fff; version = &l->l_versions[ndx]; if (version->hash == 0) version = NULL; } /* We need to keep the scope around so do some locking. This is not necessary for objects which cannot be unloaded or when we are not using any threads (yet). */ int flags = DL_LOOKUP_ADD_DEPENDENCY; if (!RTLD_SINGLE_THREAD_P) { THREAD_GSCOPE_SET_FLAG (); flags |= DL_LOOKUP_GSCOPE_LOCK; } #ifdef RTLD_ENABLE_FOREIGN_CALL RTLD_ENABLE_FOREIGN_CALL; #endif // 根据 strtab+sym->st_name 在字符串表中找到函数名，然后进行符号查找获取 libc 基址 result result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope, version, ELF_RTYPE_CLASS_PLT, flags, NULL); /* We are done with the global scope. */ if (!RTLD_SINGLE_THREAD_P) THREAD_GSCOPE_RESET_FLAG (); #ifdef RTLD_FINALIZE_FOREIGN_CALL RTLD_FINALIZE_FOREIGN_CALL; #endif /* Currently result contains the base load address (or link map) of the object that defines sym. Now add in the symbol offset. */ // 将要解析的函数的偏移地址加上 libc 基址，得到函数的实际地址 value = DL_FIXUP_MAKE_VALUE (result, sym ? (LOOKUP_VALUE_ADDRESS (result) + sym->st_value) : 0); } else { /* We already found the symbol. The module (and therefore its load address) is also known. */ value = DL_FIXUP_MAKE_VALUE (l, l->l_addr + sym->st_value); result = l; } /* And now perhaps the relocation addend. */ value = elf_machine_plt_value (l, reloc, value); // 将已经解析完成的函数地址写入相应的 GOT 表中 if (sym != NULL && __builtin_expect (ELFW(ST_TYPE) (sym->st_info) == STT_GNU_IFUNC, 0)) value = elf_ifunc_invoke (DL_FIXUP_VALUE_ADDR (value)); /* Finally, fix up the plt itself. */ if (__glibc_unlikely (GLRO(dl_bind_not))) return value; return elf_machine_fixup_plt (l, result, refsym, sym, reloc, rel_addr, value); }
3.漏洞利用
简单来想，我们要利用这种漏洞，肯定要想办法伪造_dl_runtime_resolve()函数的第二个参数。定义在动态链接库中的函数，在导入的时候，在装载阶段作为外部符号导入可执行文件。导入符号的解析需要重定位的支持，重定位项以Elf_Rel结构体来描述。这个结构的实例保存在.rel.plt段（用于导入函数）和.rel.dyn段中（用于导入全局变量），这里的重定位可以类比静态链接时候的.rel.text段，只不过静态链接的重定位都是在链接阶段完成的。
当程序导入一个正常函数是，连接器会在.dynstr段中包含一个函数名称的字符串，在.dynsym段中包含一个指向它的符号：Elf_Sym,在.rel.plt段中包含一个指向这个符号的重定位项：Elf_Rel。
dl_runtime.c中，首先分别获取动态链接符号表和动态链接字符串的基址，然后通过dl_runtime_resolve函数的第二个参数reloc_arg计算重定位入口
重定位的目标（即Elf_Rel结构中的r_offset域）将会是got表中的一个条目。GOT表保存于.got.plt段，由能够解析.rel.plt段中的重定位的动态链接器来填写。
.dynstr段是不可写的，所以我们想要覆写.dynstr段来进行任意函数的调用是不可能的。动态链接器是从.dynamic段的DT_STRTAB表中获得.dynstr段的地址的，而且DT_STRTAB地址是已知且可写的（可以通过readelf这种elf文件解析器获取DT_STRTAB和DT_SYMTAB地址）。所以图(a)中将.dynamic段中DT_STRTAB条目覆写，将.dynstr的地址写到bss段，然后再bss段布置一段假的字符串表。当它尝试解析某个函数的时候会使用不同的基址来寻找函数名，最终执行execve，这种方式非常简单，但仅当二进制程序的.dynamic段可写时有效，当RELRO部分开启的时候，.dynamic段将会被标记为只读，这时候上述方法无法使用。
图（b）中，r_info表示该函数在.rel.plt段的偏移，.rel.plt段的基址加上r_info的偏移，得到目标结构体的绝对地址，当_dl_runtime_resolve第二个参数reloc_indoex超出.rel.plt段，最终落在.bss段中时，攻击者可以在这个位置伪造一个Elf_Rel结构，并填写r_offset的值为一个可写的内存地址来将解析后的函数地址写在那里。r_info也会是一个将动态链接器导向攻击者控制内存的下标。这个下标就只想一个位于它后面的Elf_Sym结构体（我们前面说到过，这个结构体中的st_name会指向.dynstr段中对应的一个函数名称）。所以我们可以在bss段布置一个Elf_Sym结构体，然后控制st_name指向我们要构造的函数名。这是一般通用的方法，在可以绕过部分RELRO的检测。
我们用readelf和gdb查看一下dynsym节
可以看出，.dynsym节遵循16字节对齐，前四个字节就是st_name，这里Elf32_Sym[6]处保存着write函数的符号表信息，Elf32_Sym[6]->st_name=0x4c，.dynstr节的基地址再加上0x4c的偏移量，就是字符串write。
这时候，我们就可以利用图(b)中的方法进行漏洞利用。