Error in CSS recursive in IE 6/7/8 (CVE-2010-3971)
Not so long ago, or rather, in early December, information was discovered about a found error in CSS recursive processing in various versions of IE. The presented PoC could only drop the browser, but they could not survive something more meaningful from it until the beginning of this week, until an exploit appeared in Metasploit with the full exploitation of this vulnerability.
Initially, PoC looked like this:
The error lies in memory corruption in the HTML page parser (mshtml.dll), in the process of processing pages containing recursive CSS inclusions, the CStyleSheet :: Notify object is deleted and later this memory area can be used to transfer control to arbitrary code.
In principle, there is nothing particularly interesting in this vulnerability, but the implementation of its exploitation from the ripples from Metasploit really deserves attention. Interestingly, in addition to the standard heap-spray, the ROP (return oriented programming) technique through .NET was used, which is not typical enough. More specifically, the download feature of mscorie.dll from the .NET Framework 2.0 was used, which was compiled without a flag and is always loaded at the same base address (0x63f00000). This omission on the part of the developers allows the use of ROP techniques to call system functions from shellcode.
An example of a stack pivot gadget for ROP: Microsoft released Security Advisory 2488013 on the topic yesterday and the vulnerability will probably be closed in the next update bundle. So far, citizens from MS
recommend using EMET (The Enhanced Mitigation Experience Toolkit) to counteract ASLR bypass through the ROP vector described above.
Initially, PoC looked like this:
*{
color:red;
}
@import url("css.css");
@import url("css.css");
@import url("css.css");
@import url("css.css");
The error lies in memory corruption in the HTML page parser (mshtml.dll), in the process of processing pages containing recursive CSS inclusions, the CStyleSheet :: Notify object is deleted and later this memory area can be used to transfer control to arbitrary code.
mshtml!CSharedStyleSheet::Notify:
3ced63a5 8bff mov edi,edi
3ced63a7 55 push ebp
3ced63a8 8bec mov ebp,esp
3ced63aa 51 push ecx
3ced63ab 56 push esi
3ced63ac 8bb1d0000000 mov esi,dword ptr [ecx+0D0h] ; esi = 0x14
3ced63b2 57 push edi
3ced63b3 8bb9d8000000 mov edi,dword ptr [ecx+0D8h] ; pointer to array of CStyleSheet objects
3ced63b9 33c0 xor eax,eax
3ced63bb c1ee02 shr esi,2 ; esi = 0x5
In principle, there is nothing particularly interesting in this vulnerability, but the implementation of its exploitation from the ripples from Metasploit really deserves attention. Interestingly, in addition to the standard heap-spray, the ROP (return oriented programming) technique through .NET was used, which is not typical enough. More specifically, the download feature of mscorie.dll from the .NET Framework 2.0 was used, which was compiled without a flag and is always loaded at the same base address (0x63f00000). This omission on the part of the developers allows the use of ROP techniques to call system functions from shellcode.
An example of a stack pivot gadget for ROP: Microsoft released Security Advisory 2488013 on the topic yesterday and the vulnerability will probably be closed in the next update bundle. So far, citizens from MS
mscorie!_chkstk+0x1b:
63f0575b 94 xchg eax,esp
63f0575c 8b00 mov eax,dword ptr [eax]
63f0575e 890424 mov dword ptr [esp],eax
63f05761 c3 ret
recommend using EMET (The Enhanced Mitigation Experience Toolkit) to counteract ASLR bypass through the ROP vector described above.