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就不写了
来源:https://xz.aliyun.com/ 感谢【MrMeizhi】
原文始发于微信公众号(衡阳信安):iperf溢出漏洞分析_CVE-2023-38403
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论