如何发现

在源码审计的过程中，使用关键字查找、输入流跟踪等方式进行初步的审计，当到Miniwget.c的时候, 发现了此安全问题。

漏洞存在位置: miniwget.cgetHTTPResponse函数memcpy(content_buf + content_buf_used, buf + i, bytestocopy);中。

其中 bytestocopy是可以控制的, 而这次的安全问题也是出现在这, bytestocopy < 0 则会产生漏洞。我们县验证下是否会产出fault。

我们把bytestocopy 直接赋值 0×8000000。

运行结果：

发生 segmentation fault 。

我们来看下bytestocopy的整个数据流：

unsigned int bytestocopy = 0;...bytestocopy = ((int)chunksize < n -i)?chunksize:(n - i);memcpy(content_buf + content_buf_used, buf + i,bytestocopy);

然而bytestocopy 是chunksize, 我们看下chunksize的数据流：

unsigned int chunksize = 0;...for(j = 0; j < chunksize_buf_index; j++) {if(chunksize_buf[j] >= '0' && chunksize_buf[j] <= '9')chunksize = (chunksize << 4) + (chunksize_buf[j] - '0');elsechunksize = (chunksize << 4) + ((chunksize_buf[j] | 32) - 'a' + 10);}...

从中我们可以看出 chunksize 会通过一些运算来最终得到 chunksize, 而且运算也比较容易得出。

漏洞调试和验证

至此, 我们已经找到那个问题点,然后这个点也是可以控制的, 那我们如何构造这个数据让原始程序可以走到并且产生问题呢?

从源码中也可以看到chunksize 是从Body中获取的：

通过阅读他的源代码, 发现他解析的是http 的 response 响应体,并且需要有几个必须的字段：

然后是Body数据, 而我们需要控制的是 Body中的数据。

那我们如何来构造数据呢？

构造如下response 响应体：

HTTP/1.1200 OKTransfer-Encoding: chunkedContent-Length: 1Content-Type: text/htmlf<xml>test</xml>80000000Test

即可出发漏洞, 为了验证漏洞, 我吧getHTTPResponse函数进行了单独编译, 并制作成socket服务方便调试。

编译运行此文件：

使用python 编写一个POC：

运行此POC：

同样出现了 segmentation fault。

结语

最后查询了一些相关文档，发现此漏洞早已存在，并且新版本已经修复，但由于很多应用会使用低版本的miniupnpc, 同样会出现这个漏洞。漏洞的具体利用就不在阐述, 可以查看CVE-2017-8798。