Message-ID: <b1e87ea8-d379-27b4-8bb4-76c9068a4fcb@nwever.nl>
Date: Mon, 7 Nov 2016 11:58:46 +0100
From: Berend-Jan Wever <berendj@...ver.nl>
To: fulldisclosure@...lists.org, Bugtraq <bugtraq@...urityfocus.com>
Subject: [FD] VBScript CRegExp..Execute use of uninitialized memory details
 (MSIE 8-11, IIS, CScript.exe/WScript.exe)

Throughout November, I plan to release details on vulnerabilities I
found in web-browsers which I've not released before. This is the fifth
entry in that series.

The below information is available in more detail on my blog at
http://blog.skylined.nl/20161107001.html. There you can find a repro
that triggered this issue in addition to the information below as well
as a Proof-of-Concept exploit.

Follow me on http://twitter.com/berendjanwever for daily browser bugs.

VBScript CRegExp::Execute use of uninitialized memory
=====================================================
https://technet.microsoft.com/en-us/library/security/MS14-080
https://technet.microsoft.com/en-us/library/security/MS14-084
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6363

Synopsis
--------
A specially craft script can cause the VBScript engine to access data
before initializing it. An attacker that is able to run such a script in
any application that embeds the VBScript engine may be able to control
execution flow and execute arbitrary code. This includes all versions of
Microsoft Internet Explorer.

Known affected versions, attack vectors and mitigations
-------------------------------------------------------
* vbscript.dll
  The issue affects versions 5.6 through 5.8 and both the 32- and 64-bit
  vbscript.dll binaries.

* Windows Script Host
  VBScript can be executed in the command line using cscript.exe/
  wscript.exe. An attacker would need to find a script running on a
  target machine that accepts an attacker supplied regular expression
  and a string, or be able to execute his/her own script. However,
  since the later should already provide an attacker with arbitrary
  code execution, no additional privileges are gained by exploiting
  this vuln.

* Microsoft Internet Explorer
  VBScript can be executed from a webpage; MSIE 8, 9, 10 and 11 were
  tested and are all affected. MSIE 11 requires a META tag to force it
  to render the page as an earlier version, as MSIE 11 attempts to
  deprecate vbscript (but fails, so why bother?).
  An attacker would need to get a target user to open a specially
  crafted webpage. Disabling scripting, particularly VBScript, should
  prevent an attacker from triggering the vulnerable code path.
  Enabling *Enhanced Protected Mode* appears to disable VBScript on my
  systems, but I have been unable to find documentation online that
  confirms this is by design.

* Internet Information Server (IIS)
  If Active Server Pages (ASP) are enabled, VBScript can be executed in
  Active Server Pages. An attacker would need to find an asp page that
  accepts an attacker supplied regular expression and a string, or be
  able to inject VBScript into an ASP page in order to trigger the
  vulnerability.

Description
-----------
During normal operation, when you execute the `RegExp.Execute` method
from `VBScript` the code in vbscript.dll executes the `CRegExp::Execute`
function. This function creates a `CMatch` object for each match found,
and stores pointers for all of these `CMatch` objects in a singly linked
list of `CMatchBlock` structures (Note: the vbscript.dll symbols do not
provide a name for this structure, so I gave it this name). Each
`CMatchBlock` structure can store up to 16 such pointers, as well as a
pointer to the next `CMatchBlock`. This
last pointer is NULL unless all pointers in the `CMatchBlock` object are
in use and more storage is needed, in which case a new `CMatchBlock`
object is created and a link to the new object is added to the last one
in the list. The code counts how many matches it has found so far, and
this corresponds to the number of `CMatch` objects it has allocated.

When an error occurs in this part of the code, the error handling code
will try to clean up and free all `CMatchBlock` structures created
before the error occurred. To do this, it walks the linked list of
`CMatchBlock` structures and for each structure, release each `CMatch`
object in the structure. All `CMatchBlock` structures except the last
one should have 16 such pointers, the last `CMatchBlock` structure can
have 1-16, depending on how many matches where found in total. This
appears to have been designed to count how many `CMatch` objects it has
yet to free. This counter is initialized to the number of matches found
before the error occurred and should be decremented whenever the code
frees a `CMatch` object, so the code can determine how many `CMatch`
object are in the last `CMatchBlock` structure. However, this code
neglects to decrement this counter. This causes the code to assume all
`CMatchBlock` structures have 16 `CMatch` object pointers if there were
more than 16 matches in total, and attempt to release 16 `CMatch`
objects from the last `CMatchBlock` structure, even if less than 16
pointers to `CMatch` objects were stored there. This results in the code
using uninitialized memory as a pointer to an object on which it
attempts to call the `Release` method.

Timeline
--------
* March 2014: This vulnerability was found through fuzzing.
* March/April 2014: This vulnerability was submitted to ZDI and
  iDefense.
* May 2014: The vulnerability was acquired by iDefense.
* June 2014: The vulnerability was reported to Microsoft by iDefense.
* December 2014: The vulnerability was address by Microsoft in MS14-080
  and MS14-084.
* November 2016: Details of this issue are released.

Cheers,

SkyLined




_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists