VBScript CRegExp::Execute Uninitialized Memory Use

`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  
  
Repro.vbs  
  
Set oRegExp = New RegExp  
oRegExp.Pattern = "A|()*?$"  
oRegExp.Global = True  
oRegExp.Execute(String(&H11, "A") & "x")  
  
Repro.html  
  
<html>  
<head>  
<meta http-equiv="X-UA-Compatible" content="IE=10">  
<script language="VBScript">  
Set oRegExp = New RegExp  
oRegExp.Pattern = "A|()*?$"  
oRegExp.Global = True  
oRegExp.Execute(String(&H11, "A") & "x")  
</script>  
</head>  
</html>  
  
Repro.asp  
  
<%  
Set oRegExp = New RegExp  
oRegExp.Pattern = "A|()*?$"  
oRegExp.Global = True  
oRegExp.Execute(String(&H11, "A") & "x")  
%>  
  
  
  
  
`