MS11-092 -- Arbitary Memoray Write 2 NULL bytes!

I received several ZDI vulnerability bulletins that day, one of which is MS11-092. Due to the recent interest in file format vulnerabilities, PatchDiff2 compares the patch files. After comparison, the thief did not want to check whether there is a ready-made POC. GOOGLE has found some of hellok students in the snow hair "MS11-092 patch comparison analysis" this post. Oh! The enthusiasm of the brokers is so high that it is terrible! Hellok analyzed that this could be a heap overflow vulnerability, and he gave the reason --

"Memcpy (* parm3, (src_copy + 32), total_size-32); all three parameters are controllable. Writing arbitrary data at any address will eventually cause a vulnerability"

QEver said, "the vulnerability analysis seems dizzy. You can understand it only after you have manually debugged it "! So I downloaded a *. dvr-ms file and debugged the problematic code segment in encdec. dll, which is not patched on XP3. (Version: 6.05.2600.5512 base address: 0x4ADC0000 ). After debugging, I found that * The buffer pointed to by parm3 is actually allocated according to (total_size-32), so the actual cause of the vulnerability should not be overflow.

 

. Text: 4ADE5B18 add esi, 0FFFFFFE0h
. Text: 4ADE5B1B test esi, esi
. Text: 4ADE5B1D mov [ebp + var_4], eax
. Text: 4ADE5B20 mov [ebp + var_14], esi
. Text: 4ADE5B23 jle short loc_4ADE5B77
. Text: 4ADE5B25 inc esi
. Text: 4ADE5B26 shr esi, 1
. Text: 4ADE5B28 push esi; ui
. Text: 4ADE5B29 lea ecx, [ebp + bstrString]
. Text: 4ADE5B2C call sub_4ADCC694

 

This ESI is total_size, which is read from the file. That is to say, total_size is controllable by attackers. total_size marks the starting position of "Vali" in the dvr-ms file, with an offset of 0x20, for example

 

In the red box, "50 00 00 00" is total_size 0x50. In the sub_4ADCC694 function, SysAllocStringLen is called to allocate the memory Buffer1 according to the total_size, the return address is saved to the local variable [ebp + bstrString] on the stack.

 

. Text: 4ADE5B31 add ebx, 18 h; An EBX-pointed buffer with a fixed size of 0x20, which should be a struct
. Text: 4ADE5B34 push eax; EAX is the return value of the sub_4ADCC694 function, that is, the memory address allocated according to total_size.
. Text: 4ADE5B35 mov ecx, ebx
. Text: 4ADE5B37 call sub_4ADE4F1F

 

In the sub_4ADE4F1F function, SysAllocStringLen is called to allocate a block of the same size as [ebp + bstrString], that is, memory Buffer2 in total_size bytes. The result is stored at the position 0x18 in the struct with the size 0

 

. Text: 4ADE5BDC mov eax, [ebx]; save Buffer2 address in EAX
. Text: 4ADE5BDE and word ptr [eax + esi * 2-2], 0; clears the offset of ESI * 2 in Buffer2.
. Text: 4ADE5BE4 mov ecx, [ebp + total_size]; save total_size in ECX
. Text: 4ADE5BE7 mov eax, ecx
. Text: 4ADE5BE9 shr ecx, 2
. Text: 4ADE5BEC lea esi, [edi + 20 h]
. Text: 4ADE5BEF mov edi, [ebx]; save Buffer2 address in EDI
. Text: 4ADE5BF1 rep movsd
. Text: 4ADE5BF3 mov ecx, eax
. Text: 4ADE5BF5 and ecx, 3
. Text: 4ADE5BF8 rep movsb

Therefore, although total_size is controllable, the size of Buffer2 is allocated based on total_size, so no overflow will occur here. Later this morning, I carefully reviewed the vulnerability announcement, although most of them were vague. However, as long as you dig deeper, you can still dig out valuable information. For example, MS11-092 vulnerability announcement, and finally to the vulnerability submitted thanks:

 

 

Click the VeriSign iDefense Labs link, and then find a more detailed vulnerability announcement on their official website. The vulnerability description says --

"If a large length value is supplied within a certain chunk of a DVR-MS file, a heap allocation for the chunk data can fail and the return value of the allocation routine will not be checked for an error. A pointer value is calculated using the return value and the supplied length value. this condition can allow an attacker to write two null bytes to an arbitrary location in memory and this may result in the execution of arbitrary code."

 

P.S: vulnerability announcement link: https://labs.idefense.com/verisign/intelligence/2009/vulnerabilities/display.php? Id = 964

 

This probably means that if a large value is input during memory allocation, the memory allocation may fail. However, because there is no sufficient test on the returned value, attackers may write two NULL values to any address.

 

Therefore, the commands that actually trigger the vulnerability are

. Text: 4ADE5BDC mov eax, [ebx]; save Buffer2 address in EAX
. Text: 4ADE5BDE and word ptr [eax + esi * 2-2], 0; clears the offset of ESI * 2 in Buffer2.

 

If we can construct such a POC file -- "Vali" starting with 0x20 bytes, which is a large enough value to make SysAllocateStringLen fail, this malformed file can trigger the vulnerability. The sample file I used here contains several "Vali" tags, and its offset 0x20 is almost 0x50. Change "50 00 00 00 00 7F" to "00 00 00 7F"

 

 

Save 0x7F000000 in ESI

 

0x7F000000 minus 0x20

 

Calculate the current total_size 0x7EFFFFE0 (total_size-0x20) + 1)> 1 to get 0x3F7FFFF0

 

And then use the calculated result 0x3F7FFFF0 for memory allocation. The process is omitted ......

The code segment that will be triggered by the vulnerability analyzed above. Because memory allocation fails, what is saved in dword ptr [ebx] is an Invalid Address 0x00000000. then, take 0x00000000 as the base address, ESI as the index, AND 0 for the AND operation! Note that it is exactly the word ptr! So it's Arbitary Memoray Write 2 NULL bytes!

 

 

In the patch file (Version: 6.05.2600.6161), the base address in EAX is verified before the AND operation.

 

From http://hi.baidu.com/4b_4b/blog/item/104739cbe835b6059c163dca.html