BugTraq
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.

MSIE jscript9 JavaScriptStackWalker memory corruption
=====================================================
(MS15-056, CVE-2015-1730)

Synopsis
--------
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
execution.

Known affected software and attack vectors
------------------------------------------
* Microsoft Internet Explorer 9

An attacker would need to get a target user to open a specially
crafted web-page. Disabling JavaScript should prevent an attacker
from triggering the vulnerable code path.

Description
-----------
MSIE attempts to handle stack exhaustion caused by excessive recursion
in Javascript gracefully by generating a JavaScript exception. While
generating the exception, information about the call stack is gathered
using the JavascriptStackWalker class. It appears that the code that
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.

Exploit
-------
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
http://blog.skylined.nl/20161206001.html

Time-line
---------
* 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
acquired.
* 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
case.
* 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.

Cheers,
SkyLined
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQINBFeg3+kBEACfJ83XEx+3CXfc2pyDlZ5+DFSvhdvbSvemqEckOtrQxTYOmH/8
6WrX2B7K6eyolLCIQMi0FjXK5hjJJFYTMrhoa7pP9V9PD2f4TI+tZv+g0D8wDVam
wYsZrFB6NwzyUaBykjj4chYxxzUxTwagwCxvrGNY871tiVWV5eR3TrKRcsFwzN53
G3lhAT974YRCIBMuA6y+3Jrd8hgfODWUtYsH4WPhaLJRr9qaatN+Fnpk+rb9X62C
EqcVXhgNeIz1j/K3I3XoHqMThNu5zbv7uQrp2j+/0fZjKXxZ7HZhTKzIFTrJkrTA
jQ34iq0qgXmLltpKtOLJKhPQPb8J/N0MxOOTa34BDeSiqwlcRzkl7lYTIl7hvvCn
lSRbu+PoAW0GrD17RAA9FQoqdDDiNLHlXnjx7Jg/Tchq1EF70hKzMojcwyjPilty
HJRtPq/sZEdjwEuA5fM+3cmkmRWZYXmn93rB2KTNlGXo+7II6eXx1E6iw7MBzhV5
+mB9A/6FLPhb6TY7TrWOKC65uEtYjHArcb2WeB7/6g9r0nPcBzFiXt35U+YdbmiH
Qt4L5aivYI3WNwQh391Q8QH8i1C0DTI0TCoinzBHzySJfiQ5IP8BUmPIKJWxSeiF
Od5Fv3bz7S7DihtP+i7XyChoHVAleu9tk4/kIQlJ/PPbBpRAYFhQKwSX3QARAQAB
tCRCZXJlbmQtSmFuIFdldmVyIDxiZXJlbmRqQG53ZXZlci5ubD6JAj8EEwEIACkF
Aleg3+kCGw8FCQIDCbcHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCdHa2I
JVfFqn6TD/0aQmgvFcwoAOn52NujoEgl5LxdvcrPgDaZK10kuolsA2u/IaB4J3yY
c2Z8kTfGOg5ObCBHlq6B9qYn3ptr+C0ICuYENIVoHdcBgdK9JXscRWrOU8JI69mj
gmsKNLei+AuBGGC7LJOV6JNqYkVieukkFQkv17pvFl63GqNcVkwEXIzzeGOHYHqA
dvPR7xTZu+dA2olB2BVC9XsWJpsxJqzuX8L3wOEn1EFAhlbeSlBo2kXB04DnjUXU
qHa9M2PZ4q0xWmD+iAThTdyoB+FvSvn6+ThFhig99dOsx8ZLS/QRwMoq1qgN1Nst
YFZgCUuGqwR7d0Dr8/Vb1qzQmIPtn/JCjbFNuIssGRA3tDVwTvEmgfAhpVApuS8f
bNWGV2fQmEfLShqXOI/GfEYt8ltoozKKTYRiXt7oqsrLGWjXJ6SZAYcFHOCc9CbC
TukyDyndVIWAwJRSr9SHKyokElnJBeiGW9rMwITW4BRf7YfXNwHHOFW95esbNIEF
sL37BfzBoTNDUShajB8kVKJv0LE5OZArsQfz2yBXoU2AyvGEvbYdt0q53+FwGzX/
EtqkcFYqwKkxurjn8Nkk4x4hjoiUmXHj45G/MgwLxY8Skf6RvBr0eu4Mh7FxoTRP
LX5hIpGbCO3umoGbHNGkJcEw5S9oIQdb3ysf5HVLi7Pw6AIfJZWSfIkBHAQQAQgA
BgUCV6S2FwAKCRBf2KWWmuk+Yng/B/0f/nSDAnmXAiZ2HPi/ujfAEzFPWmahZJVv
Ih9DjuRUV6vk1B9Sh+yiPPZ3FfqOzVE0n6Eh1Kggs6MwQCWv+NfC0KE6rQwxjMce
+eOAf9dbVQ8h6H4yGyIyb4f0tJFRyGpOK8zlKwjvPj2gvTZFjcc1PaZ7cIeuwheB
Ijtw9DQWIoQoFFHZkLHxmNo8IT+r7lB19rVWoh1pu/zfuC+xjQLCpzexafFGY3TT
Fz7YdO14F61sJjrf++9twRi7RoHWGnAcFCZynG6x4jyog1u9iKMK2T2nV5yyQg21
yhw4zEV1pKDwUdHK+TwmtyD5c6oL3IjNDWaHn0aejKgfEiiLUBLe
=anIL
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYRqdmAAoJEJ0drYglV8WqQmkP/iVf/6ov+Fp0cAt6XsDBcL6y
zN/yTjhVZ1PPCTIjW8VETWDU7X/86siqWoHQSDjSI8GabnxBTYOtc062iG5DZaIt
rEuYXUeZ+bUQjttLPcZvoHG+zxPDAPT4/OK78FAAF/1H9lyPThqNSwG5FhVcilWW
fqPsKCCX/eUUJLBU5aGTf8rP1AioDwPUDvc7OT8rMbwaohFkCZN7PDQFZs5bUmuF
E55QEIbY/CADjn52WoPxw11c1PwCSueRn0253IRKnpGJHI4A8WJztyGBdu8jn+ai
9zGXHUQb2VCjwQjxx//BHMcY4Fs+5buu5yWK8Yie/sEIgsWSCGlaJKB6tT3mdrSx
ZEKNUO+dRGGeZJnR5UudKM5vmLIJYkuYO3RRvGEngDtqqP0Z1ukNf1IUDj/rbLRZ
PYzkAcCpedML6Iqk1RhPX3m5AlsCDux4VsRbpe7Zwv4XD+v80uepI8oAQJvjmMlV
SpFfFspPMrrFgXsAujbGlRStIYF8wPNt6ZvQbAwkUMngcviC/FbEkhJoxwysAyJ2
+yS8XTD7mgM9C13RNwAChvZxFvXa9ulHtsRnIuKNwhaX6NOK2WIlyzhMvxeMsbC4
j0RmjgTomFh6De6hDwJWmpfzqg4g9105SVAOzaZ2sWSfDO2R+vOa+UtlQILgJVVl
pSdbhXgDlfOz+vcLoMdb
=9uO3
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus