本文是针对ASX to MP3 Converter进行的漏洞分析

背景概述

本来是浏览学长博客ASX TO MP3本地代码执行漏洞感觉这个洞比较好入手，思路也比较清晰，就想着简单复现一下，但是在实际分析之中发现与博客原文写的有较大出入，于是自己一路分析上去，想搞清楚差异的地方探究真正的漏洞原因。

实验环境与原博中一样：

Asx to MP3 Converter 3.1.2（原博中写的是3.0.0，但提供的下载链接是3.1.2，是否是分析出现差异的原因？）

Windows xp sp3

Windbg

IDA pro

OD

软件下载地址：https://www.exploit-db.com/apps/b31a84e79d9941d89336b6708ef52a20-ASXtoMP3Converter_3121.exe

SEH攻击原理简述（详情可参考0day2）

为了保证系统在遇到错误时不至于崩溃，仍能够健壮稳定地继续运行下去，Windows会对运行在其中的程序提供一次补救的机会来处理错误，这种机制称为Windows异常处理机制。S.E.H即异常处理结构体(Structure Exception Handler)S.E.H链表指针和异常处理函数句柄，共计8个字节。

S.E.H结构体存放在系统栈中，线程初始化时，会自动向栈中安装S.E.H作为默认的异常处理。当异常发生时，操作系统会中断程序，并首先从T.E.B的0字节偏移处取出距离栈顶最近的S.E.H中的异常处理函数进行处理。

利用思路基本是：

1. 通过溢出覆盖栈中SEH，将指向下一条记录的指针覆盖为shellcode地址；
2. 触发一个SEH；
3. 应用程序处理SEH时调用了指令，将指向下一条记录的指针作为EIP内容；
4. 跳到shellcode地址，执行shellcode。

原博中的分析思路复现

利用poc生成一个畸形m3u文件，播放器打开文件，程序崩溃

PoC:

原文理想中的情况应该是：

1.使用windbg到达漏洞现场，使用kb发现堆栈调用全是系统dll的调用，无法回溯漏洞发生前的关键函数，于是更改思路；

2.想到该漏洞是一个文件格式的poc，那么在主程序中很有可能会通过fopen调用这个poc打开，以读取其中的文件从而触发文件格式的漏洞，于是想办法通过fopen函数来定位到漏洞发生前的函数；

3.在IDA Pro中找到5个fopen的字符串函数，在这几个地址处用windbg打断点；

4.发现在加载漏洞文件后windbg调用了fopen两次，第一次正常，在第二次时将畸形的文件格式读入到缓冲区中，而此时没有对文件的长度进行任何检查，而是直接读入缓冲区；

5.继续运行再调用后续函数时，返回地址被覆盖，导致出现一个错误，调出SEH，而SEH已经被覆盖，最终程序结束；

最终得出结论：由于对于filename的长度检查不严格，导致直接作为参数回调到外层函数中，因此当外层函数结束时，程序返回到一个不可读的地址，从而触发了异常处理流程，因为文件畸形内容，导致了SEH指针被覆盖，程序可控。

我按照此思路复现实际遇到的情况：

1.使用windbg达到漏洞现场，发现可以回溯漏洞发生前的关键函数，断在了00430402的位置

2.在IDA中同样搜寻到5个fopen的调用并在windbg中对应打了断点，但是在实际调用中加载漏洞文件后windbg调用了fopen仅1次而不是2次，之后又会断在00430402

3.使用OllyDbg分析程序崩溃位置也与原博不同，原博程序是在执行到最后ret 4时，跳转地址被覆盖为414141不可读出现错误，实际调试过程中并未执行到该函数段最后，而是在过程中读写错误崩溃的，具体原因是：

0042BD1D |mov ecx,dword ptr ss:[esp+0xAA48] ；堆栈 ss:[000DBFB4]=41414141

0042BD26 |push ecx ；堆栈000D1568 41414141 AAAA

004303E9 | mov ebx,dword ptr ss:[esp+0x10] ；堆栈 ss:[000D1568]=41414141

004303FE | mov esi,ebx ；ebx=41414141

00430402 |rep movs dword ptr es:[edi],dword ptr ds:[esi] ；ds:[esi]=[41414141]=???

在执行rep movs操作中由于414141地址不可读导致出错，并且此时SEH已然被覆盖了

此时的疑问

1.既然没有第二次fopen依然崩溃，问题可能并不出在fopen操作，那么问题出在哪？

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课