Back to list
CVE-2015-1730: MSIE jscript9 JavaÂScriptÂStackÂWalker memory corruption details and PoC
Dec 06 2016 11:56AM
Berend-Jan Wever (berendj nwever nl)
Since November I have been releasing details on all vulnerabilities I
found in web-browsers that I had not released before. I will try to
continue to publish all my old vulnerabilities, including those not in
web-browser, as long as I can find some time to do so. If you find this
information useful, you can help me make more time available by donating
bitcoin to 183yyxa9s1s1f7JBpÂPHPmzÂQ346y91Rx5DX.
This is the twenty-sixth entry in the series. This information is
available in more detail on my blog at
http://blog.skylined.nl/20161206001.html. There you can find repros
that triggered this issue in addition to a Proof-of-Concept exploit, as
well as the information below.
Today's release is interesting, in part because it is an odd
vulnerability that I've not seen before or since: it's like a
stack-based use-after-free. The time-line is also interesting in that
ZDI first did not believe it to be exploitable and EIP thought it was a
duplicate of a bug they had already reported to Microsoft. Both turned
out to be wrong. Then I reported it to iDefense as well, who
accidentally send the details over plain-text email, causing ZDI to
reject my submission for fear of the bug leaking to the public. Luckily
for me, iDefense did end up acquiring the bug.
Follow me on http://twitter.com/berendjanwever for daily browser bugs.
A specially crafted web-page can trigger a memory corruption
vulnerability in Microsoft Internet Explorer 9. A pointer set up to
point to certain data on the stack can be used after that data has been
removed from the stack. This results in a stack-based analog to a heap
use-after-free vulnerability. The stack memory where the data was stored
can be modified by an attacker before it is used, allowing remote code
Known affected software and attack vectors
* Microsoft Internet Explorer 9
An attacker would need to get a target user to open a specially
from triggering the vulnerable code path.
MSIE attempts to handle stack exhaustion caused by excessive recursion
generating the exception, information about the call stack is gathered
does this initializes a pointer variable on the stack the first time it
is run, but re-uses it if it gets called a second time. Unfortunately,
the information the pointer points to is also stored on the stack, but
is removed from the stack after the first exception is handled. Careful
manipulation of the stack during both exceptions allow an attacker to
control the data the pointer points to during the second exception.
The vulnerable pointer points to valid stack memory during the first
exception, but it is "popped" from the stack before the second. In order
to exploit this vulnerability, the code executed during the first
exception is going to point this pointer to a specific area of the
stack, while the code executed during the second is going to allocate
certain values in that same area before the pointer is re-used.
Control over the stack contents during a stack exhaustion can be
achieved by making the recursive calls with many arguments, all of which
are stored on the stack. This is similar to a heap-spray storing values
on large sections of the heap in that it is not entirely deterministic,
but the odds are very highly in favor of you setting a certain value at
a certain address.
Further details of how to exploit this issue can be found in my blog at
* 13 October 2012: This vulnerability was found through fuzzing.
* 29 October 2012: This vulnerability was submitted to EIP.
* 18 November 2012: This vulnerability was submitted to ZDI.
* 27 November 2012: EIP declines to acquire this vulnerability because
they believe it to be a copy of another vulnerability they already
* 7 December 2012: ZDI declines to acquire this vulnerability because
they believe it not to be exploitable.
During the initial report detailed above, I did not have a working
exploit to prove exploitability. I also expected the bug to be fixed
soon, seeing how EIP believed they already reported it to Microsoft.
However, about two years later, I decided to look at the issue again and
found it had not yet been fixed. Apparently it was not the same issue
that EIP reported to Microsoft. So, I decided to try to have another
look and developed a Proof-of-Concept exploit.
* April 2014: I start working on this case again, and eventually
develop a working Proof-of-Concept exploit.
* 6 November 2014: ZDI was informed of the new analysis and reopens the
* 15 November 2014: This vulnerability was submitted to iDefense.
* 16 November 2014: iDefense responds to my report email in plain text,
potentially exposing the full vulnerability details to world+dog.
* 17 November 2014: ZDI declines to acquire this vulnerability after
being informed of the potential information leak.
* 11 December 2012: This vulnerability was acquired by iDefense.
The accidentally potential disclosure of vulnerability details by
iDefense was of course a bit of a disappointment. They reported that
they have since updated their email system to automatically encrypt
emails, which should prevent this from happening again.
* 9 June 2015: Microsoft addresses this vulnerability in MS15-056.
* 6 December 2016: Details of this vulnerability are released.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
[ reply ]
Copyright 2010, SecurityFocus