Report description

v8 memory corruption leading to in sandbox arbitrary r/w

Bug location

Where do you want to report your vulnerability?

Chrome VRP – Report security issues affecting the Chrome browser. See program rules

Which URL (or repository) have you found the vulnerability in?

https://chromium.googlesource.com/v8/v8.git

The problem

Please describe the technical details of the vulnerability

Summary

TurboFan’s optimized Promise.prototype.finally path creates the internal PromiseThenFinally and PromiseCatchFinally closures with the SharedFunctionInfo’s default constructable normal-function map. The generic builtin path creates the same closures with STRICT_FUNCTION_WITHOUT_PROTOTYPE_MAP_INDEX, so only the optimized helpers are constructable.

A sloppy onFinally callback can obtain the optimized internal helper through legacy Function.caller. After the helper escapes, JavaScript can replace Promise.prototype.then and invoke the helper with new. JSBuiltinsConstructStub returns the PromiseThenFinally builtin’s result directly, including a primitive Smi selected by the attacker.

TurboFan types every JSConstruct result as Receiver. Optimized code therefore omits checks that would reject the Smi, causing type confusion, invalid native memory access, and exploitable optimized property/element accesses.

Version

Source revision: V8 15.3.55 at commit 1ed8fce48374f15f382bb0a708eca9ce5463aa90

Chromium source revision: d712c14d603b9a96757629c6c0d61012a9665c0d

Browser validation: Chromium 153.0.7993.0 custom Linux ASAN build, SHA-256 b6e9ac14f260d01233b15e137d992ec39ff7985096786f93ee5e624838051406, ELF Build ID 18cbaf21969c3b3c.

Root cause analysis

1. The generic and optimized paths allocate different function types

The generic Promise.prototype.finally path uses AllocateRootFunctionWithContext, which hardcodes STRICT_FUNCTION_WITHOUT_PROTOTYPE_MAP_INDEX and creates nonconstructable helpers. TurboFan’s ReducePromisePrototypeFinally instead uses JSCreateClosure, whose lowering selects the map from each helper’s SharedFunctionInfo.

2. The optimized helpers retain a constructable map

src/v8/src/heap/setup-heap-internal.cc creates the PromiseThenFinally and PromiseCatchFinally SharedFunctionInfos as default normal functions and never assigns STRICT_FUNCTION_WITHOUT_PROTOTYPE_MAP_INDEX. Optimized closures therefore receive the default constructable, sloppy-function map.

3. The internal helper can escape src/v8/src/builtins/accessors.cc allows sloppy Function.caller to return the next native or user JavaScript caller. Because the optimized helper remains sloppy, an onFinally callback can obtain its PromiseThenFinally caller.

4. Construction can return a primitive

Builtin-backed SharedFunctionInfos use JSBuiltinsConstructStub, which returns the builtin result directly. PromiseThenFinally returns InvokeThen(…), so replacing Promise.prototype.then lets new leakedFinally() return an attacker-controlled Smi instead of a receiver.

5. Critical compiler assumption TurboFan assumes every JSConstruct result is a Receiver and consequently removes checks that could reject a Smi:

  return Type::Receiver();
}
                                                                                                                      if (!input_type.Maybe(Type::SignedSmall())) {
  return Replace(input);  // Removes CheckHeapObject.
}

Optimized property or element accesses then consume the Smi as a heap object. In the minimized PoC, accessing (new leakedFinally()).field after switching the construct result to Smi 1 causes a native read from address 0x1.

Bisect

The commit that starts the current uninterrupted vulnerable history is:

b158bfdc2f9b66de130b06e48f9e0cc25206c760
Reland "[runtime] Remove the construct_stub field of the SFI"
Cr-Commit-Position: refs/heads/master@{#52389}
Commit date: April 5, 2018

Reproduce

build d8 with the following config

is_debug = false
is_component_build = false
target_cpu = "x64"
v8_target_cpu = "x64"
is_asan = true
is_lsan = false
use_remoteexec = false
use_siso = false
symbol_level = 2                                                                                                       
v8_symbol_level = 2
dcheck_always_on = true
v8_enable_slow_dchecks = true
v8_enable_test_features = true
v8_enable_sandbox = true
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = true
v8_enable_memory_corruption_api = true
v8_enable_undefined_double = true

run

ASAN_OPTIONS='handle_segv=1:abort_on_error=1:symbolize=1:detect_leaks=0' \
  ./d8 \
  --disable-in-process-stack-traces \
  --allow-natives-syntax \
  ./poc_asan.js

You will see the crash log attached.

Reproduce with prebuilt asan chrome:

Start a webserver in the same folder with

python3 -m httpserver

ASAN_OPTIONS='handle_segv=1:abort_on_error=1:symbolize=1:detect_leaks=0:fast_unwind_on_fatal=1:external_symbolizer_path=./153.0.7993.0/llvm-symbolizer' \
  ./153.0.7993.0/chrome-wrapper \
  --headless=new \
  --no-sandbox \
  --disable-gpu \
  --disable-dev-shm-usage \
  --disable-breakpad \
  --disable-in-process-stack-traces \
  --user-data-dir=/tmp/promise-finally-profile \
  http://127.0.0.1:8000/poc_asan.html \
  2>&1 | tee /tmp/promise-finally-chrome-asan.txt

Exploitation

This bug is exploitable to get a shell.

Build a release d8 with sandbox off

is_debug = false
is_component_build = false
target_cpu = "x64"
v8_target_cpu = "x64"
is_asan = false
is_lsan = false
use_remoteexec = false
use_siso = false
symbol_level = 2
v8_symbol_level = 2
dcheck_always_on = false
v8_enable_slow_dchecks = false
v8_enable_test_features = true
v8_enable_sandbox = false
v8_enable_pointer_compression = true
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = false
v8_enable_memory_corruption_api = false

Then run

./d8 \
  --predictable \
  --single-threaded \
  --no-concurrent-recompilation \
  --no-concurrent-marking \
  --allow-natives-syntax \
  ./poc_getshll.js

You will get a shell

./d8 \                                                          
  --predictable \
  --single-threaded \
  --no-concurrent-recompilation \
  --no-concurrent-marking \
  --allow-natives-syntax \
  ./poc_getshll.js
building fixed-phase large-object layout
layout 1 / 1
leaked constructable Promise finally helper
warming pointer-only field path
warming optimized access paths 1 / 3
warming optimized access paths 2 / 3
warming optimized access paths 3 / 3
optimized access paths warmed
forging fake-array holders through the Promise construct confusion
packed-double map 0x100d141
arbitrary in-cage read/write self-test passed
generic addrof/fakeobj identity self-test passed
d8 base 0x5658627c6000
Shell::System 0x565864112f60
launching interactive /bin/sh through the corrupted API callback
$ echo hello
hello

Impact analysis

RCE in render process.

The cause

What version of Chrome have you found the security issue in?

commit d712c14d603b9a96757629c6c0d61012a9665c0d

Is the security issue related to a crash?

Yes, it is related to a crash.

Choose the type of vulnerability

Remote Code Execution (RCE)

How would you like to be publicly acknowledged for your report?

Zhenpeng (Leo) Lin at depthfirst