VBScript CReg­Exp::Execute use of uninitialized memory

(MS14-080 and MS14-084, CVE-2014-6363)

Synopsis

A specially crafted 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 web-page; 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 web-page. 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 on-line 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.

Repro

Below are three repro files that trigger the issue in Windows Script Host (repro.vbs), Microsoft Internet Explorer (repro.html), and Internet Information Server (repro.asp).

Description

During normal operation, when you execute the Reg­Exp.Execute method from VBScript the code in vbscript.dll executes the CReg­Exp::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 CMatch­Block structures (Note: the vbscript.dll symbols do not provide a name for this structure, so I gave it this name). Each CMatch­Block structure can store up to 16 such pointers, as well as a pointer to the next CMatch­Block. This last pointer is NULL unless all pointers in the CMatch­Block object are in use and more storage is needed, in which case a new CMatch­Block 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.

The following pseudo-code represents these two structures:

CMatch­Block {
  00 04 CMatch­Block* po­Next­CMatch­Block
  04 40 CMatch* apo­CMatches[16]
} // size = 0x44 (x86) or 0x88 (x64)

CMatch {
  00 0C void** apap­VFTables[3]              
  0C 04 DWORD dw­Unknown_0C
  10 04 DWORD po­Unknown­Object_10
  14 04 DWORD po­Unknown­Object_14
  18 04 DWORD po­Unknown­Object_18
  1C 04 DWORD po­Unknown­Object_1C
  20 04 DWORD dw­Unknown_20
  24 04 BSTR s­Value
  28 04 INT[]* pai­Match­Start­And­End­Indices
  2C 04 INT i­Count­Match­And­Sub­Matches
} // size = 0x30 (x86) or unknown (x64)

When an error occurs in this part of the code, the error handling code will try to clean up and free all CMatch­Block structures created before the error occurred. To do this, it walks the linked list of CMatch­Block structures and for each structure, release each CMatch object in the structure. All CMatch­Block structures except the last one should have 16 such pointers, the last CMatch­Block 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 CMatch­Block structure. However, this code neglects to decrement this counter. This causes the code to assume all CMatch­Block 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 CMatch­Block structure, even if less than 16 pointers to CMatch objects were stored there.

The below pseudo-code represents how the real code works:

po­CMatch­Block = po­First­CMatch­Block;
do {
    if (i­Total­Matches­Count < 0x10) { // Note 1
        i­Matches­In­CMatch­Block = i­Total­Matches­Count;
    } else {
        i­Matches­In­CMatch­Block = 0x10; // Note 2
    }
    for (i­Index = 0; i­Index < i­Matches­In­CMatch­Block; i­Index++) {
        po­CMatch­Block->apo­CMatches[i­Index].Release(); // Note 3
    }
    po­Old­CMatch­Block = po­CMatch­Block;
    po­CMatch­Block = po­CMatch­Block->po­Next­CMatch­Block;
    delete po­Old­CMatch­Block;
    // Note 4
} while (po­CMatch­Block);

For example: if the code finds 17 matches before an error is triggered, 2 CMatch­Block structures will have been created: the first will contain 16 pointers to CMatch objects and the second will contain exactly 1. The error handling code will run with i­Total­Matches­Count set to 17 but never decrements it (Note 4 shows where that decrement should happen). The loop is executed twice, once for each CMatch­Block structure. On each do...while-loop i­Total­Matches­Count will be larger than 17 (Note 1) and thus i­Matches­In­CMatch­Block will be set to 16 (Note 2). This causes the for-loop to try to free 16 CMatch objects from the second CMatch­Block structure, in which only one was stored. This results in the code using uninitialized memory as a pointer to an object on which it attempts to call the Release method.

To fix this, the following code would have to be inserted at Note 4:

    i­Total­Matches­Count -= i­Matches­In­CMatch­Block

Exploitation

An attacker looking to exploit this bug will commonly attempt to allocate memory blocks of the same size and on the same heap as the CMatch­Block structure and fill these blocks with certain data before releasing them. If done correctly, the heap manager will then reuse these memory blocks when the CMatch­Block objects are allocated, causing these structures to contain the attacker supplied data. Once the vulnerability is triggered, this attacker supplied data is then used as pointers to CMatch objects, and when the code attempts to call the Release method of these objects, they are treated as pointers to a list of virtual function tables, from which the code retreives an address to call to execute that method. Control over these pointers therefore gives an attacker control over execution flow.

Heap Feng-Shui, a common technique used to manipulate the heap in MSIE, can not be used in this case, as it uses strings to manipulate the heap. Strings in both Java­Script and VBScript are allocated through OLEAUT32, whereas the CMatch­Block structures are allocated through msvcrt, which uses a different heap. The Trident rendering engine also uses a different heap to allocate various potentially useful memory blocks.

To find out if there was a way to allocate and free memory in order to manipulate the heap an control what the uninitialized memory contains, I logged all allocations made while executing the CReg­Exp::Execute method. This showed that it allocates a block of memory through msvcrt to store the indices of the start and end of a match and each of its sub-matches. The size of this block depends on the number of sub-matches in the regular expression and the contents of the block depends on where the matches are found in the string. Both are attacker controlled, allowing for the creation of memory blocks of near arbitrary size and content.

To exploit the bug, one can execute a regular expression that generates the desired sub-matches and free them in order to manipulate the heap before executing another regular expression that triggers the issue. This should cause the code to use attacker supplied values for the uninitialized CMatch object pointers. The Proof-of-Concept exploit below attempts to do this and execute memory under an attacker's control. As this is a simple Po­C sploit, nothing is done in order to attempt to bypass mitigations such as [DEP] and the "shellcode" is simply a bunch of INT3-s.

Time-line

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