0x00 前言

最近看到一个二进制的漏洞，特写此篇分析记录一下下。

0x01 漏洞信息

看到了公开的 issue和commit为

https://github.com/esnet/iperf/issues/1542
https://cwe.mitre.org/data/definitions/130.html
https://github.com/esnet/iperf/commit/0ef151550d96cc4460f98832df84b4a1e87c65e9
https://downloads.es.net/pub/iperf/esnet-secadv-2023-0001.txt.asc
https://bugs.debian.org/1040830

从公告中基本可以判断漏洞点在此处

作者也给了相应的poc

print(b'\x41'*37+b'\xff'*4+b'\x41'*50)

不过没有详细讨论近一步具体的触发利用

0x02 一些准备

环境部署

git clone https://github.com/esnet/iperf.git 
git checkout b4878b3fc61f456584292ff7380c9145a0af4a1f
./configure
make

0x03 漏洞复现

iperf server启动

./src/iperf3 -s

利用

下图可以看到在exp打过去之后直接爆出corrupted top size错误并出现程序崩溃。

0x04 一些细节

问题主要出在，calloc分配的长度大小可以由攻击者控制并且程序在申请堆块之前对传入的长度值+1，这意味着如果传入的值是0xffffffff,那么+1之后就变成了0，即最后得到了一个空指针。当空指针被再次调用的时候，将引起程序崩溃。

所以在新版本的补丁中，加入了长度值的判断，如果长度值+1为0，则不进行内存分配。

0x05 遇到的一些问题

在确定触发的入口点的时候，跟不少代码，所在函数是JSON_read，因此大概率跟json解析相关的功能有关，看了下help命令，并没有直接解析json的功能。只能从网络层面，正常wireshark抓包进行确定。即在将要解析这一段json的数据流中发生的问题,前面的字符串的长度刚刚好与作者给出的poc中的37个字节相吻合。

具体exp就不写了

0x06 后记

第一次做二进制漏洞方面的分析，如有错误师傅们指出，轻喷。