Date: Tue, 6 Dec 2016 12:56:15 +0100
From: Berend-Jan Wever <berendj@...ver.nl>
To: fulldisclosure@...lists.org, Bugtraq <bugtraq@...urityfocus.com>
Subject: CVE-2015-1730: MSIE jscript9 Java­Script­Stack­Walker memory corruption details and PoC

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

Download attachment "0x2557C5AA.asc" of type "application/pgp-keys" (2036 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists