构建人工智能存储架构

攻击运行时解析器

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

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

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

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

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

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

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

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

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

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

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

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!