VBScript CRegExp::Execute Uninitialized Memory Use
Posted on 08 November 2016
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") %>
