CVE-2017-3731：截断的数据包导致OpenSSL拒绝服务-工具盒子

前言

OpenSSL是一个流行的SSL开源库，被世界各地的各种软件和公司使用。1月份，OpenSSL发布了一个更新以修复多个漏洞。其中之一就是CVE-2017-3731，这可能导致由于程序崩溃而引发的拒绝服务。McAfee 实验室分析了此漏洞来为客户提供检测。

使用patch diff来找出修改的地方

补丁修改了一些与各种密码算法相关的文件。对于本报告，我们将检查代码e_chacha20_poly1305.c。以下代码显示此文件的修补程序，取自https://git.openssl.org/?p=openssl.git;a=commitdiff;h=2198b3a55de681e1f3c23edb0586afe13f438051 。

我们可以看到，添加了一个简单的步骤来检查变量长度的值与常量POLY1305_BLOCK_SIZE的大小关系，而紧接着下面我们看到变量"len"减去了这个常量。

如果我们查看声明就能发现，POLY1305_BLOCK_SIZE在文件poly1305.h中声明为"#define POLY1305_BLOCK_SIZE 16"。而变量len在e_chacha20_poly1305.c中定义为"unsigned int len;"。

因此，如果变量len小于16，它将导致整数下溢，也就是说，len的值将变得非常大。然后当该值被使用时，可能会导致正常程序流出现问题，因为len的值不正确。

进一步挖掘

我们可以看到在前面的图片中，这个len值被分配给"actx-> tls_payload_length"。然后调用函数chacha20_poly1305_cipher。在此函数内，actx-> tls_payload_length被分配给变量"plen"：

注意，变量plen将得到从先前的len整数下溢导致的非常大的数值。我们可以进一步看到plen的值传递给函数poly1305_Update：

Poly1305_Update调用函数Poly1305_blocks时将携带此大值：

如果我们仔细看看函数，我们可以看到变量len包含一个非常大的整数值，但是却被用来作"while"循环中的计数器：

我们还可以看到对函数U8TOU32的调用，该函数读取* inp（指针）的值，并且在循环的每次迭代中，* inp的值加上一次POLY1305_BLOCK_SIZE。因为len的值非常大，最终* inp将指向不可读的内存。尝试读取将导致访问异常错误 - 导致OpenSSL崩溃。

从网络中利用漏洞

要利用此漏洞，客户端需要使用chacha20_poly1305加密套件（或另一个加密漏洞，可从补丁diff中看出），并发送加密的握手消息，其中记录长度小于16个字节（在使用chacha20_poly1305加密套件的情况下）。这将导致整数下溢致使OpenSSL崩溃，我们可以在以下图像看到运行中的OpenSSL和Gnu Debugger：