As soon as Microsoft had released patches for security bulletin MS12-037 (which patched 13 vulnerabilities for Internet Explorer) Google published information (Microsoft XML vulnerability under active exploitation) about a new zero-day vulnerability (CVE-2012-1889) in Microsoft XML Core Services. Sometimes vulnerabilities are discovered at a rate that outpaces the patching process and so a temporary fix is needed. That is what Microsoft has provided in this case: a ‘Fix it’ patch. We recommend that you install the patch because exploits for the vulnerability are already in the wild.
Furthermore, a few days ago an exploit for CVE-2012-1889 was made public through publication in the Metasploit Framework repository (New Critical Microsoft IE Zero-Day Exploits in Metasploit). ESET products already detect the CVE-2012-1889 vulnerability as JS/Exploit.CVE-2012-1889. However, you should still install the patch if you are using software that is affected, as detailed in Microsoft Security Advisory 2719615.
Now for the technical details: CVE-2012-1889 exploits memory corruption issues in Microsoft XML Core Services when trying to access an XML Node that hasn’t been initialized, using the get_definition API call, which may corrupt memory and allow remote code execution. The ‘Use-after-free’ class of vulnerability is quite commonly found in programs developed in the C/C++ languages.
Vulnerability CVE-2012-1889 is simple to exploit in all known versions of Internet Explorer. An attacker can make a CLSID-identification request by calling MSXML library methods and create an object identifier in order to try to access a non-existent object. Proof of Concept code for causing a crash looks like this:
Figure 1
This code looks simple, but generates memory corruption and crashes Internet Explorer. The exploitation code tries to request a non-initialized object, but reference to memory region already exists. Memory corruption takes place in the helper function _dispatchImpl :: InvokeHelper() in the MSXML library. It’s possible to execute remote code on execution of the following instruction:
call dword ptr [ecx+18h]
So if an attacker modifies stack values this code transfers control to the shellcode. In order to modify the stack attackers can use a heap-spray technique and as result can control execution process according to the following steps.
Figure 2
Figure 3 demonstrates backtrace of all stack frames after Internet Explorer crashes:
Figure 3
On the stack it is possible to track the moment at which the XML Node object is handled:
Figure 4
At the next step of execution the shellcode receives control and is executed, and as a result it is possible to effect malicious operations on the affected machine.
Figure 5
Of course on Windows 7 or Vista attackers need to bypass ASLR, DEP and other security mechanisms built into the operating system. But in the lab we already have many examples of real exploits that can make use of this mechanism, and there is no universal method of stopping attackers at this moment. What is worse, there are ways in which it is possible for an exploit to make use of .DOC files: the known affected Microsoft Office versions are 2003/2007. We strongly recommend that you install the ‘Fix it patch’ on the system so as to mitigate this attack vector.
The next version of Microsoft Internet Explorer will include a new security check for stack frames and mechanisms for mitigation of attacks that transfer control to a shellcode address (Enhanced Memory Protections in IE10).
Aleksandr Matrosov, Security Intelligence Team Lead
