-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add MS13-069 (CVE-2013-3205) IE ccaret object use-after-free #2399
Conversation
This module exploits a use-after-free vulnerability found in Internet Explorer, specifically in how the browser handles the caret (text cursor) object. In IE's standards mode, the caret handling's vulnerable state can be triggered by first setting up an editable page with an input field, and then we can force the caret to update in an onbeforeeditfocus event by setting the body's innerHTML property. In this event handler, mshtml!CCaret::`vftable' can be freed using a document.write() function, however, mshtml!CCaret::UpdateScreenCaret remains unaware aware of this change, and still uses the same reference to the CCaret object. When the function tries to use this invalid reference to call a virtual function at offset 0x2c, it finally results a crash. Precise control of the freed object allows arbitrary code execution under the context of the user. The vuln works against IE8 on Win 7, but the current version of the custom spray doesn't actually work well against that target. More work is needed before we can add that target for sure. The reason a custom spray is needed is because the document.write() function erases the typical spray routines we use like js_property_spray, or the heaplib + substring one. Tried using an iframe too, but onbeforeeditfocus event doesn't seem to work well in an iframe (does not fire when innerHTML is used.)
Processing! |
@wchen-r7 , your branch is giving me problems with the tape_engine_8A file, looks like your branch wasn't sync with rapid7 when you did your changes. Do you mind to mind to merge from or rebase to master? My filesystem can't handle it atm :( anyway, reviewing!
|
[ | ||
'corelanc0d3r', # Vuln discovery & PoC (@corelanc0d3r) | ||
'sinn3r', # Metasploit (@_sinn3r) | ||
'juan vazquez' # socket fix (@_juan_vazquez_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it isn't needed ... really :P
Working:
|
That's annoying. Let me see if I can figure it out. Yeah, when I started this branch I still had that problem. |
Ended up starting a new branch instead. Please move on to that one, and then I'm closing this. |
have you tried connecting to it with Win7 IE8 ? IIRC it threw an error on my box (object nil or something like that) |
The exploit shouldn't fire against Win 7. Trigger should still work though. Because it was a last minute decision to strip Win 7 target. |
This module exploits a use-after-free vulnerability found in Internet Explorer, specifically in how the browser handles the caret (text cursor) object. In IE's standards mode, the caret handling's vulnerable state can be triggered by first
setting up an editable page with an input field, and then we can force the caret to update in an onbeforeeditfocus event by setting the body's innerHTML property. In this event handler, mshtml!CCaret::`vftable' can be freed using a document.write() function, however, mshtml!CCaret::UpdateScreenCaret remains unaware aware of this change, and still uses the same reference to the CCaret object. When the function tries to use this invalid reference to call a virtual function at offset 0x2c, it finally results a crash. Precise control of the freed object allows arbitrary code
execution under the context of the user.
The vuln works against IE8 on Win 7, but the current version of the custom spray doesn't actually work well against that target. More work is needed before we can add that target for sure. The reason a custom spray is needed is because the document.write() function erases the typical spray routines we use like js_property_spray, or the heaplib + substring one. Tried using an iframe too, but onbeforeeditfocus event doesn't seem to work well in an iframe (does not fire when innerHTML is used.)
Demo of the exploit: