xfocus logo xfocus title
首页 焦点原创 安全文摘 安全工具 安全漏洞 焦点项目 焦点论坛 关于我们
添加文章 Xcon English Version

MS06-055 XP-SP2 Exploit Challenge

文章提交:failwest (failwest_at_gmail.com)

MS06-055 XP-SP2 Exploit Challenge

                    To be the apostrophe which changed " Impossible "  into  " I'm possible "!

                                  1. The Brief History about MS06-055 Discovering

2006-09-19, CVE first published the 0day and named CVE-2006-4868. The web page also referenced some related reports from other famous security websites.

2006-09-19 11:14:35, US-CERT first published it and gave some brief information about the vulnerability.

2006-09-19, NVD reported it.

2006-09-20, the first public 0day exploit was published by “nop” from “xsec” and spread aboard on Internet.

2006-09-20, Chinese security company NSFOCUS(中联绿盟) reported the vulnerability.

2006-09-22, CN-CERT reported the 0day.

2006-09-26, Microsoft released security bulletin MS06-055(kb925486) for the 0day.

2006-09-29, Chinese security company VENUS(启明星辰)reported the vulnerability.

This brief history has shown a whole process of computer emergency response. I’ve heard about that Microsoft planed to release the security update on 2006-10-10 originally. As the 0day has been published on Internet, they released the MS06-055 couple weeks before the deadline.  

We can also found in the brief history that the speed of Chinese security organization focusing on 0day and computer emergency was not as fast as the org aboard except NSFOCUS. The CCERT ( http://www.ccert.edu.cn/ ) hasn’t reported any information about the 0day at all !    

                                           2 Vulnerability Analyzing and Using

We can find some brief description on US-CERT or Microsoft Tech-Website:
Microsoft IE version 5.0 and higher supports the Vector Markup Language (VML), which is a set of XML tags for drawing vector graphics. IE fails to properly handle malformed VML tags allowing a stack buffer overflow to occur. If a remote attacker can persuade a user to access a specially crafted web page with IE, that attacker may be able to trigger the buffer overflow. In addition, an attacker could deliver an HTML email message or entice a user to select an HTML document in Windows Explorer.

Follow the simple description and the exploit published by “nop” from “xsec”, I debugged the vulnerability by myself.

The problem was in vgx.dll. We can locat it in
C:\Program Files\Common Files\Microsoft Shared\VGX
If you have updated your system with MS06-055, you can find it in

We can read it with IDA first. The overflow function is
_IE5_SHADETYPE_TEXT::Text(unsigned short const *, int)

At the beginning of the function, “sub esp ,214h”, create a buffer in stack as 214h bytes. When Text() call another function Ptok(), a buffer overflow may be triggered by copy letter from HTML files to the buffer in stack.

I’ll give a concrete debug example on XP_SP2 here. First, you should create an html file like this:

<html xmlns:v="urn:schemas-microsoft-com:vml">
<!--v\:* { behavior: url(#default#VML); }-->
<v:rect style="width:444pt;height:444pt" fillcolor="black">
<v:fill method="QQQQ"/>
Then you should save it as *.html and open with IE. You can see a big black square on the screen. It was drawn by VML (Vector Markup Language).

Now let’s debug it. Open your Ollydbg and attach to IE, set breakpoint at the beginning of the function Text(). On my computer the address of the function is 0x6FF3ED46. We can use IDA got the function address and just use CTR+G go to there ,then press F2 set breakpoint : )

Refreshing the page, Ollydbg will break it at the beginning of the function. Press F8 to execute step by step. When executed to
6FF3ED92 call vgx.6FF3ECE6
Look at the stack, some Unicode letter ‘Q’ was copy to stack just after current ESP! That’s right ! The function Ptok() will copy the letter between the double quotation marks in <v:fill method="QQQQ"/> as Unicode string.

On my computer, the stack structure just looks like this:

0012BE70: Starting of the Unicode string in stack buffer
0012C070: Security Cookie
0012C074: EBP
0012C078: return address
0012C084: ESP after retn

We can easily found that the actual buffer size for Unicode string is 0x200, it is 512 bytes and 256 Unicode letters. For Ptok() function will end the Unicode string with 2 bytes 0, the buffer can hold 255 Unicode letters at most!

So, that is a typical stack overflow. We can fill more than 255 letters in html and the letter will be copied as Unicode in to stack and destroyed the return address. If you have shellcode, you can use this vulnerability to execute any code you want by IE.

By the way, If you want to develop your own shellcode, you should deal with the problem that your shellcode will be treated as ASCII letter byte by byte and changed into Unicode form word by word through Ptok() function! To exploit it there is a solution that Ptok() will pares the word like “&#37008;” as a Hex number. For example 37008 in Hex is 0x9090, so the word “&#37008;” will be copied into stack as 0x9090.

“nop” write a exploit can use it successful on WIN2K platform and the code was published on Internet. The function convert2ncr() in the exploit will help you to make your own shellcode : )

void convert2ncr(unsigned char * buf, int size)
    int i=0;
    unsigned int ncr = 0;
    for(i=0; i<size; i+=2)//read a word
        ncr = (buf[i+1] << 8) + buf[i];
        fprintf(fp, "&#%d;", ncr);

                                  3 Cookie Secure Before Function Return in XP-SP2

On Windows XP SP2 systems the vulnerable component (VGX.DLL) is compiled with the /GS (Buffer Security Check) flag. Let me found out why it is hard to hack on XP SP2.

Disassembling vgx.dll with IDA as follows, we can check the function
_IE5_SHADETYPE_TEXT::Text(unsigned short const *, int)

.text:6FF3ED46 ; _IE5_SHADETYPE_TEXT::Text(unsigned short const *, int)
.text:6FF3ED46                 mov    edi, edi
.text:6FF3ED48                 push   ebp
.text:6FF3ED49                 mov    ebp, esp
.text:6FF3ED4B                 sub    esp, 214h
.text:6FF3ED51                 mov    eax, ___security_cookie
.text:6FF3ED56                 and    dword ptr [ecx], 0
.text:6FF3ED59                 mov    [ebp+4], eax
.text:6FF3ED5C                 mov    eax, [ebp+arg_0]
.text:6FF3ED92            call    _IE5_SHADETYPE_TEXT::TOKENS::Ptok
.text:6FF3ED97                 test    eax, eax
.text:6FF3EDB1                 lea     ecx, [ebp+var_210]
.text:6FF3EDB7                 call    _IE5_SHADETYPE_TEXT::TOKENS::Ptok
.text:6FF3EDDF                 mov     ecx, [ebp+4]
.text:6FF3EDE2                    call    __security_check_cookie(x)
.text:6FF3EDE7                 leave
.text:6FF3EDE8                 retn    8

You maybe noticed that at the beginning of the function there is a memory reading instruction:
.text:6FF3ED51     mov    eax, ___security_cookie

IDA translated the memory address 0x6FF44160 as “___security_cookie”. The value was set to [EBP+4] at .text:6FF3ED59 then. At the end of the function .text:6FF3EDE2 there is a call to check the value just before EBP whether been changed:
.text:6FF3EDE2     call    __security_check_cookie(x)

This function will terminate IE process with an error if the value before EBP is different from the address of security cookie. The cookie address .text:6FF3ED59 can be located in vgx.dll data section and would be different every times when IE started. To overflow the return value, the content in [ebp+4] must be overwritten first. So it’s hard to exploit on XP SP2 platform.

However, exploits using techniques to circumvent the Buffer Security Check are publicly available. If you have some idea to challenge it on XP SP2, please contact me with failwest@gmail.com . I’m very glad to discuss with you!