See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in
This commit changes how os_name and os_flavor are handled
for client-side exploits, matching recent changes to the
server-side exploits and scanner fingerprints.
This commit also updates the client-side fingerprinting to
take into account Windows 8.1 and IE 9, 10, and 11.
I didn't even realize we already added this in server.rb. So instead
of just escaping the OS parameter, we also encode the data in base64.
I also added prependmigrate to avoid unstable conditions for the payload.
* Period at the end of a description.
* Methods shouldn't be meth_name! unless the method is destructive.
* "Setup" is a noun, "set up" is a verb.
* Use the clunky post module naming convention.
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.
Alan Foster