深入考察解释型语言背后隐藏的攻击面，Part 2（三）

接上文：

• 《深入考察解释型语言背后隐藏的攻击面，Part 1(上)》
• 《深入考察解释型语言背后隐藏的攻击面，Part 1(下)》
• 《深入考察解释型语言背后隐藏的攻击面，Part 2(一)》
• 《深入考察解释型语言背后隐藏的攻击面，Part 2(二)》

在本文中，我们将深入地探讨，在通过外部函数接口(ForeignFunctionInterface，FFI)将基于C/C++的库“粘合”到解释语言的过程中，安全漏洞是如何产生的。

决定最终的漏洞利用策略

为了弄清楚如何在触发我们的堆内存覆盖之前对data_数组进行最佳定位，我们需要检查一下堆的状态。到目前为止，我们有两个感兴趣的目标：png_ptr结构体和运行时解析器正在使用的动态链接器数据。

如果我们检查png_ptr结构体数据所在的堆分块，我们就会发现，它是一个大小为0x530的main arena分块。

此前，我们已经研究了png_ptr结构体本身，以及如何利用它来颠覆node进程，现在，让我们仔细考察_dl_fixup，以及在解析器代码中发生崩溃的具体原因。

当我们触发崩溃时，我们注意到：

这意味着，我们已经破坏了用于解析png-img库函数的linkmap。实际上，linkmap是一个数据结构，用于保存动态链接器执行运行时解析和重定位所需的所有信息。

下面，我们来看一下linkmap堆块和数据结构未被破坏之前的样子：

当我们检查png_ptr chunk和linkmapchunk的地址和大小时，注意到它们所在的内存不仅是相邻的，并且是连续内存。png_ptrchunk位于地址0x2722ef0处，而大小为0x4e0的linkmapchunk则位于它之前的地址0x2722a10处。由于是连续内存，因此，两者之间不存在分块。

当从攻击者的角度评估堆状态时，我们总是同时考虑连续内存布局和逻辑内存布局(例如链表)。

因为linkmap和png_ptr的内存在我们开始影响目标node进程之前分配的，并且在漏洞利用过程中都处于使用状态，所以，我们似乎不太可能在这两个分块之间挪动我们的data_chunk，以畅通无阻地破坏png_ptr数据。此外，我们貌似可以通过例如PNG文件大小来影响早期的堆状态，但这似乎无法得到可靠的结果。

这意味着我们将必须对linkmap进行破坏，以获取对node进程的控制权。

攻击运行时解析器

作为攻击者，我们经常要从系统代码中提炼出非预期的、但有用的行为。这里的挑战是：不要被那些我们不关心的东西所干扰，而要专注于那些在特定的漏洞利用场景中可资利用的行为。

那么，运行时解析器代码的哪些行为可能对攻击者有用呢?

要回答这个问题，我们必须了解运行时解析器是如何使用linkmap的。简而言之，它将从linkmap中抓取已加载的库的基地址，然后检查各种二进制段，以确定从库的基地址到要解析的函数起始地址的正确偏移量。一旦计算出这个偏移量，把它加到库的基地址上，用解析函数地址更新函数的GOT条目，然后跳转到解析函数的起始地址即可。

作为攻击者，我们从中提炼出以下有用的原语：向动态链接器的运行时解析器提供一个精心设计的linkmap，将它们加在一起，然后将执行流重定向到生成的地址处。加法的第一个操作数是直接从linkmap中得到的，而加法的第二个操作数可以通过linkmap中提供的指针从二进制段中获取。我们注意到，根据包含在某个解除引用的二进制段中的数据，在执行被重定向之前，解析的值将被写入一个内存位置。

实际上，通过破坏动态链接器来发动攻击并不是一个新主意，其中，所谓的“ret2dlresolve”攻击就是一种流行的方式，它可以在不知道libc本身在内存中的位置的情况下，将执行重定向到所需的libc函数中。在Nergal发布在Phrack上的“Theadvancedreturn-into-lib(c) exploits: PaX case study”一文中，就公开讨论过这个概念。

当PLT处于目标二进制文件的已知位置时，就像非PIE二进制文件的情况一样，ret2dlresolve攻击就是一个非常有吸引力的选择，它可以将执行重定向到任意库偏移处，而无需知道所需的目标库实际加载到内存的具体位置。这是因为解析器代码会替我们完成所有繁重的工作。

滥用运行时解析器的主流方法，通常会假设攻击者已经能够重定向进程的执行流，并通过PLT返回到解析器代码中，以便为_dl_runtime_resolve提供攻击者控制的参数。因此，这种方法被称为“ret2dlresolve”(即returntodlresolve的缩写形式)。他们的想法是，随后可以利用解析器与现有的或精心制作的linkmap数据和重定位数据的交互，推导出攻击者控制的偏移量，即到达内存中的现有指针值的偏移。例如，他们可以欺骗解析器，让解析器将攻击者控制的偏移量应用到一个已经建立的libc地址上，以便从那里偏移到一个任意的libc函数上，比如system(3)。在不知道libc基地址且无法直接返回libc的情况下，上面这种方法的一个变体是使用解析器逻辑来解析libc函数。

当然，这个技术还存在其他变体，例如在内存中的已知位置提供一个完全精心制作的linkmap，用相对寻址来伪造重定位和符号数据。这里的目标同样是滥用运行时解析器，从已知的内存位置偏移到攻击者想要转移执行的位置。

然而，虽然在我们的例子中，我们能够提供一个精心制作的linkmap，但我们并不能控制运行时解析器的参数。此外，我们也还没有掌握执行控制权，而是旨在“策反”运行时解析器，通过我们精心制作的linkmap数据，以绕过ASLR机制并实现执行重定向。由于堆的基地址是随机的，而且我们是通过PNG文件来攻击进程的，所以，我们没有办法泄露linkmap的位置，因此我们只能基于非PIE节点二进制文件来进行内存布局和内容假设。

为了更好地了解如何实现攻击者的目标，让我们来看看_dl_fixup的工作原理。在这里，所有的代码引用都来自glibc-2.27。

复杂，但我们只需要关注以下几点：_dl_fixup是如何通过与我们控制的linkmap中的三个主要指针进行交互，来解析和重定位函数地址的，所有这些指针都是从linkmap的l_info数组中提取的：

• l_info[DT_SYMTAB]，指向符号表的.dynamic条目的指针。
• l_info[DT_STRTAB]，指向字符串表的.dynamic条目的指针。
• l_info[DT_JMPREL]，指向PLT重定位记录数组的.dynamic条目的指针。

Elf二进制文件中的.dynamic段用于保存解析器需要获取的各个段的信息。在我们的例子中，.dynstr(STRTAB)、.dynsym(SYMTAB)和.rela.plt (JMPREL)段都是解析和重定位函数所需要的。

动态条目(Dynamic entry)的结构如下所示：

用于访问l_info条目的D_PTR宏定义为：

请注意，在大多数情况下，D_PTR只是从.dynamic段条目中获取d_ptr字段，以检索相关段的运行时重定位地址。例如，const charstrtab= (const void ) D_PTR (l,l_info[DT_STRTAB]);将按照提供的指向.dynstr(STRTAB)段的.dynamic条目的指针，在l_info数组的索引DT_STRTAB处，获取上述条目的d_ptr字段。

在指针方面，这里比较让人头疼，但我们只要记住一点就行了：我们并不是通过控制linkmap中的l_info数组来提供直接指向解析器所需要的各个段的指针，而是指向(假定的).dynamic条目的指针，这些条目在偏移量+8处应该包含一个指向相关段的指针。

前面，我们介绍了如何通过精心制作的linkmap数据为解析器提供伪造的二进制段，接下来，我们快速了解一下_dl_fixup中的实际解析和重定位逻辑。

在我们的测试平台上，重定位记录的定义如下所示：

在我们的测试平台上，这些符号的定义如下所示：

我们再来回顾一下_dl_fixup的代码，注意在[1]处，_dl_fixup的reloc_arg参数重定位记录表的索引，来读取重定位记录。这个重定位记录提供了一个reloc->r_info字段，该字段通过宏分为高32位的符号表索引和低32位的重定位类型。

在[2]处，_dl_fixup利用reloc->r_info索引从符号表中获取相应的符号条目，在reloc->r_info处的ELF_MACHINE_JMP_SLOT类型断言和sym->st_other处的符号查找范围检查之前，实际的函数解析以一种非常简单的方式进行。首先，通过将linkmap中的l->l_addr字段和符号表项的sym->st_value字段相加来解析函数地址。然后将解析后的值写入rel_addr中，rel_addr是在[3]处计算出来的，也就是l->l_addr和reloc->r_offset相加的结果。

linkmap中的l->l_addr字段是用来存放加载库的基地址，任何解析的偏移值都会被加入其中。

综上所述，sym->st_value + l->l_addr是解析函数的地址，l->l_addr+reloc->r_offset是重定位目标，也就是GOT条目，将用解析函数地址进行更新。

所以，从我们攻击者的角度来看，既然我们控制了l->l_addr，以及指向符号表和重定位记录的.dynamic段的指针，我们就可以将执行重定向到对我们有利的地方。

小结

在本文中，我们将深入地探讨，在通过外部函数接口(ForeignFunctionInterface，FFI)将基于C/C++的库“粘合”到解释语言的过程中，安全漏洞是如何产生的。由于篇幅过长，我们将分为多篇进行介绍，更多精彩内容敬请期待!

本文翻译自：https://securitylab.github.com/research/now-you-c-me-part-two

鸿蒙官方战略合作共建——HarmonyOS技术社区