CAP是分布式理论的基础？

为了利用这个漏洞，应用程序必须显式使用一个大于目标字节数组长度的长度参数，向该字节数组中读入比分配给该数组的空间更多的数据。如果未提供长度参数，则该函数则默认使用目标字节数组本身的长度，因此，就不会发生内存损坏问题。

如果您使用的开发语言要求程序员自己负责内存管理的话，那么对于上述问题肯定不会陌生。您甚至可能认为，任何一个心智正常的人都不会做这样的蠢事。因为很明显，您不应该读取比目标缓冲区中可用的数据更多的数据，对吗?

这个案例的有趣之处就在这里：提供内存管理功能的编程语言的开发人员，通常会倾向信任该语言的实现。但是，当语言中存在诸如CVE-2014-1912之类的问题时，则可能会出现认知失调。

Python开发人员可能完全希望能够在Python解释器不受内存损坏的情况下使用s.recvfrom_into(bytearray(256), 512) 。实际上，如果您尝试这个打过补丁后的程序，它现在的表现就像您所期望的那样：
 

这是一个很好的例子，它为我们展示了Perl格式化实现的bug是如何转化为安全漏洞的。结合Webmin中的格式字符串漏洞，攻击者就能够对Webmin发动远程代码执行(RCE)攻击。

我们得出的结论是，即使在较高级语言级别上看起来似乎“只是一个bug”的问题，也需要对错误输入的较低级别处理进行深入的考察，因为它们很可能会转化为一个高危漏洞——即使人们曾经认为这样的问题实际上是不可利用的。

PHP解释器的无限潜力

从攻击者的角度来看，他们一直对PHP解释器的许多版本趋之若鹜。这是因为，攻击者通常可以从解释器控制角度和远程API输入角度对其发动攻击：对于前者，攻击者能够执行任意PHP代码;对于后者，攻击者可以向潜在易受攻击的PHP API提供恶意输入。

利用PHP解释器的一个更有趣的例子是反序列化攻击。因为攻击者曾经在PHP逻辑级别和核心解释器级别攻陷过PHP的反序列化API。

人们普遍认为，对不受信任的用户提供的数据进行反序列化是一个坏主意。在远程应用程序的上下文中，任意的对象反序列化可能会导致相对简单的PHP任意执行，这取决于应用程序命名空间中哪些类是可用的和允许的。这个主题超越了语言的界限，我们在几乎所有支持反序列化的语言和应用程序框架中都看到了同样的概念。

在攻击者实现任意PHP执行攻击后，他们可能会发现自己受到受限解释器配置的制约，这时他们通常会探索解除这些限制的方法。历史上流行的一种方法是滥用PHP解释器本身的bug。最近在 https://bugs.php.net/bug.php?id=76047中可以找到这类攻击的一个示例，其中可以利用debugbacktrace()函数中的释放后使用(UAF)漏洞来完全控制PHP解释器本身,并废除所有配置方面的限制。

有时，即使提供了受控的PHP反序列化原语，由于攻击者无法获悉哪些类是可用的，或因应用程序命名空间存在某些限制，而无法将其转化为任意PHP执行能力。这时，从上层下潜到较低的代码层，很可能就能找到突破口。

由于PHP的反序列化API中存在大量内存管理不善问题，因此，长久以来，它们一直都是模糊测试和解释器漏洞的热门研究目标。

通过利用反序列化API在解释器实现层面的内存管理不善问题，一个坚定的攻击者能够将一个原本不可利用的漏洞转变成一个完全可利用的漏洞。实际上，已经出现过许多通过该攻击面远程利用PHP应用程序的实际例子。

最近的一个例子出现在Ruslan Habolov撰写的一篇优秀的文章中，其中描述了他们如何利用低级PHP解释器错误和高级PHP API的交互，对一个著名的现实目标发动RCE攻击。

PHP反序列化在较高和较低级别实现的混合攻击面是解释型语言垂直攻击面的另一个很好的例子。

把C带入Python中：CVE-2014-1912漏洞

就本文而言，我们的第三个也是最后一个例子是CVE-2014-1912漏洞。这个漏洞存在于Python的socket.recvfrom_into函数中。

在Python2.5中引入的socket.recvfrom_into的预期用途是将数据接收到指定的Python字节数组中。但是，由于该函数缺乏明确的检查，所以无法确保接收数据的目标缓冲区的大小足以容纳指定数量的传入数据。

例如socket.recvfrom_into(bytearray(256)，512)就会触发内存损坏问题。

后来，人们通过下面的代码对其进行了修复：

（编辑：新余站长网）

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