Pages

Thursday, June 16, 2011

Patch Tuesdays kill bugs. This post is about a bug that I had independently found and written an exploit for that was killed last Tuesday with bulletin MS11-050. I'm not sure which CVE this vulnerability has been assigned, all I know is that [UPDATE] It's definitely CVE-2011-1260 - see Jose's (of spa-s3c.blogspot.com) blog post about it (he originally submitted it to ZDI (ZDI-11-194) -> MS). MS11-050 has fixed the vulnerability I was using to achieve RCE on IE 7 and 8 (6 and 9 are also affected, but I didn't make a working exploit for them). This blog post goes over some of the details of the vulnerability, as well as the exploit that I've made for it. Note that all examples in this post were made with IE 8.

The Vuln

What

The vuln is a use-after-free vulnerability in Internet Explorer. This occurs when invalid mshtml!CObjectElements are handled. When an invalid <object> element exists in a web page that is covered by other visible html elements (due to their positioning or styles), formats get computed on a previously-freed mshtml!CObjectElement. If other data has happened to be written over where the object element used to be in memory, invalid values may be used when the freed object is handled (such as a vtable pointer).

Now that you know a little about the crash, you want to know more or less what's going on, right? After some initial sleuthing, I set the breakpoints below to print out the type of objects that were being allocated and freed by printing out their vtable pointer.

ebx in this instance is the pointer to the object that IE is calling the Doc function on, eax then becomes the vtable pointer, and edx is supposed to be the valid function on the CObjectElement that is supposed to be called:

My guess of the overall flow of things leading up to the crash is that the <object> element was initially added to some list of elements to be displayed. The object element then gets deleted because it is invalid and has nothing to display, but it isn't removed from the list. Something happens with the layout where formats need to be recalculated, and IE tries to call a method on the freed object, leading to the use-after-free.

The Exploit

The basic plan for exploiting this vulnerability should be to cause the <object> element to be freed, get data that we control to overwrite the freed object, and then do something that would cause functions to be called on the object element. Simple enough. The exploit for IE7 and IE8 with DEP disabled involves your basic heap spray (nops + shellcode) and overwriting the CObjectElement with 0c0c0c0cs. Once the mshtml!CElement::Doc function is called, code execution should go something like this:

The exploit for IE8 with DEP enabled required a ROP payload: the CObjectElement is overwritten with 0c0c0c0cs, a second heap-spray should land the ROP stack at 0c0c0c0c, and a third heap-spray should land the nops + shellcode at 0x23000000. Once everything is all setup, the ROP stack should be found at 0c0c0c0c and should look like this:

Can somebody Jose or d0c_s4vage or both provide plain HTML exploit version of this exploit too, maybe with a basic bind_shell or calc in the unescape() format.Would be really helpful to test it.Thanks and Keep the Good Work up !

@d0c.s4vage: "Something that I didn't mention in the post is that there's a _ton_ of ways to trigger this vulnerability. They all require use of the object tag though. "Jose didn't seem to have mentioned it to ZDI either as evident in the title of the vulnerablity, which is probably where the confusion about it only affecting IE8/9 originated.

Is there special meanning about the script that you list~~ I try (change the order, change some param, delete some param) , and find that some still will cause the bug but some will not. So how do IE really work about this script ? How did you find the bug ?

Have Anyone else work out a exploit on IE9? In IE9, it can also trigger this vulnerability, but the internals seems have changed greatly! After set 3 breakpoint learned from this post, I even didn't find that the CTreeNode::Release is invoked.