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

看到了公开的 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)

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

环境部署

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

iperf server启动

./src/iperf3 -s

利用

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

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

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

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

具体exp就不写了

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