CVE-2012-1889 Microsoft XML vulnerability - Samples and Analysis by Brian Mariani and Frédéric Bourla

Brian Mariani (High-Tech Bridge htbridge.com Geneva, Switzerland) sent a very detailed and helpful analysis of CVE 2012-1889 - "CVE-2012-1889 - Microsoft XML core services uninitialized memory vulnerability" presentation - by Brian Mariani and Frédéric Bourla, which I am publishing here.

Please download the slides in PDF format. The text of the presentation is also posted below. 

I am posting two samples - a metasploit poc file and a non-metasploit malicious code sample.

CVE Information

CVE-2012-1889 

Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 accesses uninitialized memory locations, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.

Links and Information

(from the presentation)

Microsoft Security Advisory (2719615)

Microsoft Security Advisory: Vulnerability in Microsoft XML Core Services could allow remote code execution

Microsoft XML vulnerability under active exploitation

New Critical Microsoft IE Zero-Day Exploits in Metasploit

http://blogs.technet.com/b/srd/archive/2012/06/13/msxml-fix-it-before-fixing-it.aspx

http://en.wikipedia.org XML

Using Uninitialized Memory for Fun and Profit

http://www.corelan.be

Presentation Download

CVE 2012-1889 - "CVE-2012-1889 - Microsoft XML core services uninitialized memory vulnerability" -  by Brian Mariani and Frédéric Bourla

- also see the presentation text below

Download

 Exploit POC and non metasploit sample download 

1. Download samples below (email me if you need the password)

File: enkorean.htm  << non-metasploit sample

Size: 5737

MD5:  DF531CFF54C3E16B9EF3D4C8C8AAB449

File: poc.txt

MD5:  b0574ef27f05cc1bebb94b85dcd8ba88

Size: 17048

Download

 File: enkorean.htm  MD5:  DF531CFF54C3E16B9EF3D4C8C8AAB449  in action

 enkorean.htm  MD5:  DF531CFF54C3E16B9EF3D4C8C8AAB449

 enkorean.htm  MD5:  DF531CFF54C3E16B9EF3D4C8C8AAB449

Download

Presentation text

CVE 2012-1889 - Microsoft XML core services uninitialized memory vulnerability

TIMELINE 

• Before the 30th of May 2012 attackers were exploiting a new Microsoft Internet explorer 0day. 
• The 30th of May 2012 Google warned Microsoft about this vulnerability existing in the core of Internet Explorer XML services. 
• The 12th of June 2012      -  Microsoft published a security advisory with a temporary Fix-It. 
• On June 18th 2012 the Metasploit Project released an exploit module. 
• On June 19th 2012 a Metasploit update was released which proposed a 100% reliable exploit for Internet Explorer IE6/7/8/9, Windows XP, Vista, and all the way to Windows 7 SP1. 

THE FLAW

• The vulnerability exists in the MSXML3, MSXML4 and MSXML6 Microsoft dynamic-Linked libraries. 
• To trigger the flaw one must try to access an XML node (object in memory) that has not been appropriately initialized. 
• This leads to memory corruption in such a way that an attacker could execute arbitrary code in the context of the current user. 
• This category of flaw can frequently be abused by arranging the heap and stack memory areas with memory addresses previously known by the attacker before the weak code triggers the bug. 

WHAT XML IS? 

According to Wikipedia: 

• The Extensible Markup Language (XML) defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. 
• The design goals of XML emphasize simplicity, generality, and usability over the Internet. 
• It is a textual data format with strong support via Unicode for many programming languages. 
• It is also widely used for the representation of arbitrary data structures, typically in web services. 

DETAILS ABOUT THE CRASH 

• The crash is produced in the msxml3.dll module. 
• The function name where internet explorer generates the access violation is _dispatchImpl::InvokeHelper. 
• The instruction which generates the crash is a call to a pointer generated by the content of the ECX register plus the 0x18h value. 
• In the present document we analyze the whole process from the heap and stack spray, until the bug is triggered and the code execution is reached. 
• Our lab environment is a Windows XP – SP3 English operating system with IE 6. 

CRASH PROOF OF CONCEPT 

A working proof of concept could be coded in these two ways: 

THE CRASH FROM WINDBG 

Here is the crash from WinDBG debugger: 

LOADING THE VULNERABLE MODULE 

• In order to analyze this flaw we first create a simple HTML file. 
• The main purpose is to load the vulnerable module first. 
• Once the module is just loaded in memory a breakpoint is placed at the very beginning of the function _dispatchImpl::InvokeHelper. 

LOADING THE VULNERABLE MODULE 

The msxml3.dll module is now loaded at the 0x7498000 memory address. 

SOME IMPORTANT POINTS 

• Until the html page is rendered the _dispatchImpl::InvokeHelper function will be call four times, however the instruction which permits arbitrary code execution will be executed only at the fourth entry. 
• Before the _dispatchImpl::InvokeHelper function is reached the heap will be already prepared in order to contain the or al,0x0c sled which gently leads the execution of shellcode. 
• The or al,0x0C instruction does not affects any critical data. The goal is to "slide" the flow of code to its ultimate destination. 
• Since the shellcode is sitting in multiple chunks in the heap right after the or al,0x0c sled the probability of successful arbitrary code execution is very high. (see slide 13) 
• The stack will be sprayed with fake pointers 0c0c0c08 in order to successfully reach the or al,0x0c sled. (see slide 17) 

ANALYSIS OF THE VULNERABILITY (1) 

• After the _dispatchImpl::InvokeHelper function is first called, this is the status of the call stack. 
• At this point the heap is already arranged with the 0r al,0xc pattern. 

ANALYSIS OF THE VULNERABILITY (2) 

• It is possible to observe the copy procedure of the dword values 0c0c0c0c into the heap area. 
• The copy routine is executed from the msvcrt!memcpy function which was called by the jscript.dll module.

ANALYSIS OF THE VULNERABILITY (3) 

After finishing the aforementioned copy procedure, the heap is properly arranged: 

ANALYSIS OF THE VULNERABILITY (4) 

This is the call stack when the function _dispatchImpl::InvokeHelper is hit the second time: 

ANALYSIS OF THE VULNERABILITY (5) 

 Here is the call stack after the vulnerable function is thirdly reached: 

ANALYSIS OF THE VULNERABILITY (6) 

.Finally, we can visualize the call stack after the  _dispatchImpl::InvokeHelper function has been called for the fourth time: 

 At this point the fake pointers were already written into the stack, as is shown in the next slide. 

ANALYSIS OF THE VULNERABILITY (7) 

The fake pointers copy procedure is being executed by the memcpy routine called from the jscript module.

ANALYSIS OF THE VULNERABILITY (8) 

Here is the status of the stack after finishing the aforementioned routine. 

ANALYSIS OF THE VULNERABILITY (9) 

As said before, from this point the vulnerable code will finally lead to arbitrary code execution. 

The function prolog is executed as usual. 

At the 0x749BD6C3 address 0x10C bytes are reserved for the local variables, thus we can better observe the previously injected fake pointers. 

ANALYSIS OF THE VULNERABILITY (10) 

.At the address 0x749BD6C9 other arguments are pushed in order to call the SetErrorInfo function from the Oleaut32.dll module. 

ANALYSIS OF THE VULNERABILITY (11) 

After returning from the SetErrorInfo function the routine FindIndex is also called: 

ANALYSIS OF THE VULNERABILITY (12) 

When the code returns from the FindIndex function the EAX value is set to zero. 

Thus, the conditional jump at the address 0x749BD6FC (InvokeHelper+144) is not performed. 

ANALYSIS OF THE VULNERABILITY (13) 

The flow of code continues until it reaches the instruction “lea eax, [ebp-0x1c]” which loads the EAX register with one of the fake pointers. 

This starts to be interesting :] however we have not hit the bug yet. 

ANALYSIS OF THE VULNERABILITY (14) 

Later, the code flow calls the Oleaut32!VariantInit function. 

We will not go deeper into this function as this is not interesting for this analysis.

ANALYSIS OF THE VULNERABILITY (15) 

After returning from the Oleaut32!VariantInit function the code pushes the EBX register which was previously set to zero. 

Later, the code loads the EAX register with a pointer of injected dword values. 

However the low word was partially corrupted during the execution. 

Nevertheless this will not affect the arbitrary code execution. 

ANALYSIS OF THE VULNERABILITY (16) 

The code continues running until it reaches a call to the pointer of [esi+0x20] which resolves to the DOMNode::_invokeDOMNode function. 

We are not going deeper into all the subsequent calls from this point, however the next slide shows the call stack until reaching the last function into the process of creating the XML node. During this phase the “get_definition” function is finally reached. 

ANALYSIS OF THE VULNERABILITY (17) 

The Node::get_definition function is called. 

ANALYSIS OF THE VULNERABILITY (18) 

When the code returns from the DOMNode::_invokeDOMNode function the value of the eax register is set to 1. 

So the conditional jump JL at the address 0x749BD74B is not executed. 

ANALYSIS OF THE VULNERABILITY (19) 

After the non-taken jump the code takes a dword from [ebp+0x14] and 

moves it into the EAX register. 

EAX now holds the 0x0c0c0c08 value. 

ANALYSIS OF THE VULNERABILITY (20) 

But wait… The value is directly moved it into the eax register! … What was really the previously moved value? 

Decompiling the msxml3.dll module with IDA show us that the value matches with a local variable that was not properly initialized. 

ANALYSIS OF THE VULNERABILITY (21) 

Later… because of the comparison between eax, ebx (0x749BD754) registers the JZ jump at the address 0x749BD758 is not taken. 

The code continues… and lastly, the content of the eax pointer is transferred into the ecx register. 

ANALYSIS OF THE VULNERABILITY (22) 

From the address 0x749BD75F the following instructions will not modify the ECX register, thus the call instruction at the address 0x749BD772 will successfully reach the or al,0x0c sled. 

ANALYSIS OF THE VULNERABILITY (23) 

The or al,0x0c sled is successfully executed until it finds the shellcode. 

ANALYSIS OF THE VULNERABILITY (24) 
Shellcode execution is achieved.

SOME TEMPORARY MITIGATIONS 

• Microsoft created a new workaround in the form of a Fix-it. 
• The Fix-it package makes a minor change at runtime to either of msxml3.dll, msxml4.dll or msxml6.dll modules every time Internet Explorer is loaded. 
• This modification causes Internet Explorer to properly initialize the previously uninitialized variable which is the main problem of this vulnerability. 
• Deploy the Enhanced Mitigation Experience Toolkit. 
• Configure Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and Local intranet security zone. 

www.htbridge.com