[典型漏洞分享]YS VTM模块存在格式化字符串漏洞,可导致VTM进程异常退出【高危】
2014-12-25 19:19
781 查看
YS VTM模块存在格式化字符串漏洞,可导致VTM进程异常退出【高危】
问题描述:
YS VTM模块开放对外监听端口(8554和8664),此次使用sulley fuzzing框架对监听在8664端口的私有二进制协议进行测试,以检测可能发生的各种问题。在该协议中,客户端会向8664端口发送一个二进制+文本格式的报文,对该报文格式的各个字段进行fuzzing,发现当向服务端的VTM进程传入格式化字符串时会崩溃并退出。测试步骤:
1、 分别在客户机和服务器安装sulley fuzzing框架并为私有二进制协议编写相应测试脚本,此时服务器端上的VTM进程正常工作,如图所示:![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/3229dad82e77eacee60c6c733e0dceb1.jpg)
2、 在服务器端通过sulley分别启动VTM进程监听和fuzzing数据的网络抓包,如下图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/f5a09a4ad9c095ed590970e87e7e9b2e.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/b5bb1ba12628fdf17fde399cfe480cd9.jpg)
3、 在客户机启动sulley fuzzing测试,sulley将根据我们自定义的协议脚本进行数据变异,并发送到服务器的VTM进程,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/e781197a715c96972f49b1f168ea99f0.jpg)
4、 观察服务器端的sulley进程监听窗口,发现出现异常信息,如图:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/d058a3e7149c6b90843b5a3da11cd824.jpg)
5、 观察服务器端的任务管理器,发现VTM进程已经退出,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/43f5e425e471f0c492011a11496e1ed7.jpg)
6、 观察服务器端的sulley网络抓包窗口,发现问题出现在第109个fuzzing用例,如图:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/a141544eaf11f5c09be5ddc85616d05f.jpg)
7、 该用例数据包为pcap格式数据包,由sulley自动抓取并保存在C:\crash目录下,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/996f56c5a8faf90cc460640f74c28f54.jpg)
8、 使用wireshark打开该用例数据包,发现sulley在tts请求的IP字段填充了由多个”%n”组成的格式化字符串,该数据是导致VTM异常退出的主要原因,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/43a1f32f552db816621f35fdf414a4e6.jpg)
9、 由于字符串是由多个”%n”字符组成的,因此我们需要进一步判断到底是字符串的超长溢出还是对特殊格式化字符解析错误导致的进程异常退出,为此,我们使用python脚本进行手动验证。
10、 打开wireshark,并启动抓包功能,设置过滤条件为tcp.port == 8664,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/33fba197035c31324925024922e0368b.jpg)
11、 编写python脚本,模拟步骤8的数据包格式,向tts请求的IP字段填充200个’A’字符,并进行发送,并通过wireshark抓包确认发包准确,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/5c27b58b8a4383a3f97ebe43ad2aab25.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/7137d303d043f79c6c00e19796e1ab36.jpg)
12、 观察服务器端的VTM进程,并未发现异常,如图:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/120749c4220f0a081e7ef1ba2266d909.jpg)
13、 模拟步骤8的数据包格式,重新向tts请求的IP字段填充200个’%n’字符,并进行发送,并通过wireshark抓包确认发包准确,结果发现VTM进程异常退出,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/a5f128dae2ec53ad6dcd55a303becce4.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/87a103d0e2d095a730edc1f4fa21c13a.jpg)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/c2760b727eea1a672d29741598449f53.jpg)
14、 以下为VTM进程异常退出时,使用ollydbg抓取的调用栈信息,如图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202010/27/51538bd867babbb115af74f51ca8450a.jpg)
15、 根据步骤13,不断调整向服务器发送的”%n”字符串的个数,发现当”%n”字符>=6个时,VTM进程就会崩溃,因此,可以确定并非缓冲区溢出造成的进程崩溃,而是进程在对格式化字符串进行解析时出现的异常。
问题扩展:
1、 通过不断的验证和测试,发现tts请求的其它字段也同样存在类似问题,比如port字段,talk字段等等,只是针对不同的字段在重现问题时所需要的”%n”字符串的最少个数是不一样的,此外,不同的字段产生的异常栈信息也不一样。2、 除了使用”%n”字符串可导致VTM进程异常以外,”%s”字符串亦能重现此问题,可能还存在其它的格式化字符或特殊字符能够导致该问题,应平行排查.
相关文章推荐
- [典型漏洞分享]YS忘记密码机制设计存在缺陷,导致任意用户口令均可被修改【高】
- [典型漏洞分享]YS的防暴力破解设计存在缺陷
- [典型漏洞分享]一个典型的XSS盲打漏洞可导致全网用户cookie被盗取
- [典型漏洞分享]结合YS业务分析使用oauth协议的风险
- Dive Into Python 学习记录1-函数/模块导入/字典/列表/元组/字符串分割、连接、格式化/映射list/
- postfix邮件杀毒模块clamav进程异常死掉产生的报警信息
- IE7漏洞蔓延 所有IE浏览器均存在高危漏洞
- ZFS 存在严重安全漏洞 ,可导致系统引导失败
- 进程异常退出,信号量没有得到释放
- Linux Kernel ext3消息记录格式化字符串漏洞
- 详谈UNIX环境进程异常退出
- 管道连接异常 --- 另主线程退出了,其他线程仍在转,导致进程不退出。
- Linux 2.6.* 内核Capability LSM模块进程特权信任状本地权限提升漏洞
- PHPCMS V9 视频分享模块SQL注射漏洞分析
- PHPCMS V9 视频分享模块SQL注射漏洞分析
- linux下实现进程异常退出后自动重启
- 分享一个自己写的字符串工具:字符串格式化拼接
- 详谈 UNIX 环境进程异常退出
- xEyeTS.dll移植到新的架构下,每次进程退出时都出现异常。
- 详谈 UNIX 环境进程异常退出