From object transition to RCE in the Chrome renderer

[Collection]

In this post, I’ll exploit CVE-2024-5830, a type confusion bug in v8, the Javascript engine of Chrome that I reported in May 2024 as bug 342456991. The bug was fixed in version 126.0.6478.56/57. This bug allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site.

Object map and map transitions in V8

This section contains some background materials in object maps and transitions that are needed to understand the vulnerability. Readers who are familiar with this can skip to the next section.

The concept of a map (or hidden class) is fairly fundamental to Javascript interpreters. It represents the memory layout of an object and is crucial in the optimization of property access. There are already many good articles that go into much more detail on this topic. I particularly recommend “JavaScript engine fundamentals: Shapes and Inline Caches” by Mathias Bynens.

A map holds an array of property descriptors (DescriptorArrays) that contains information about each property. It also holds details about the elements of the object and its type.

Maps are shared between objects with the same property layout. For example, the following objects both have a single property a of type SMI (31 bit integers), so they can share the same map.

o1 = {a : 1};
o2 = {a : 10000};  //<------ same map as o1, MapA

Maps also account property types in an object. For example, the following object, o3 has a map different from o1 and o2, because its property a is of type double (HeapNumber), rather than SMI:

o3 = {a : 1.1};

When a new property is added to an object, if a map does not already exist for the new object layout, a new map will be created.

o1.b = 1; //<------ new map with SMI properties a and b

When this happens, the old and the new map are related by a transition:

%DebugPrint(o2);
DebugPrint: 0x3a5d00049001: [JS_OBJECT_TYPE]
 - map: 0x3a5d00298911 

Note that the map of o2 contains a transition to another map (0x3a5d00298999), which is the newly created map for o3:

%DebugPrint(o3);
DebugPrint: 0x3a5d00048fd5: [JS_OBJECT_TYPE]
 - map: 0x3a5d00298999 

Conversely, the map of o2 (0x3a5d00298911) is stored in this new map as the back pointer. A map can store multiple transitions in a TransitionArray. For example, if another property c is added to o2, then the TransitionArray will contain two transitions, one to property b and another to property c:

o4 = {a : 1};
o2.c = 1;
%DebugPrint(o4);
DebugPrint: 0x2dd400049055: [JS_OBJECT_TYPE]
 - map: 0x2dd400298941 

When a field of type SMI in an object is assigned a double (HeapNumber) value, because the SMI type cannot hold a double value, the map of the object needs to change to reflect this:

o1 = {a : 1};
o2 = {a : 1};
o1 = {a : 1.1};
%DebugPrint(o1);
DebugPrint: 0x1b4e00049015: [JS_OBJECT_TYPE]
 - map: 0x1b4e002989a1 

Note that, not only do o1 and o2 have different maps, but the map of o2 is also marked as deprecated. This means that when a new object of the same property layout is created, it’ll use the map of o1 (0x1b4e002989a1) instead of that of o2 (0x1b4e00298935) because a more general map, the map of o1, whose field can represent both HeapNumber and SMI, is now available. Moreover, the map of o2 will also be updated to the map of o1 when its properties are accessed. This is done via the UpdateImpl function:

Handle

Essentially, the function uses the back pointer of a map to retrace the transitions until it reaches the first map that does not have a backpointer (the RootMap). It then goes through the transitions from the RootMap to check if there already exists a suitable map in the transitions that can be used for the object (FindTargetMap). If a suitable map is found, then ConstructNewMap will create a new map which is then used by the object.

For example, in the following case, a map with three properties becomes deprecated when the second property is assigned a HeapNumber value:

obj = {a : 1};
obj.b = 1;
obj.c = 1; //<---- Map now has 3 SMI properties
obj.b = 1.1 //<----- original map becomes deprecated and a new map is created

In this case, two new maps are created. First a map with properties a and b of types SMI and HeapNumber respectively, then another map with three properties, a : SMI, b : HeapNumber and c : SMI to accommodate the new property layout:

In the above image, the red maps become deprecated and the green maps are newly created maps. After the property assignment, obj will be using the newly created map that has properties a, b and c and the transitions to the deprecated red maps are removed and replaced by the new green transitions.

In v8, object properties can be stored in an array or in a dictionary. Objects with properties stored in an array are referred to as fast objects, while objects with properties in dictionaries are dictionary objects. Map transitions and deprecations are specific to fast objects and normally, when a map deprecation happens, another fast map is created by UpdateImpl. This, however, is not necessarily the case. Let’s take a look at a slightly different example:

obj = {a : 1};
obj.b = 1;    //<---- MapB
obj.c = 1;    //<---- MapC

obj2 = {a : 1};
obj2.b = 1;  //<----- MapB
obj2.b = 1.1;   //<---- map of obj becomes deprecated

Assigning a HeapNumber to obj2.b causes both the original map of obj2 (MapB), as well as the map of obj (MapC) to become deprecated. This is because the map of obj (MapC) is now a transition of a deprecated map (MapB), which causes it to become deprecated as well:

As obj now has a deprecated map, its map will be updated when any of its property is accessed:

x = obj.a; //<---- calls UpdateImpl to update the map of obj

In this case, a new map has to be created and a new transition is added to the map of obj2. However, there is a limited number of transitions that a map can hold. Prior to adding a new transition, a check is carried out to ensure that the map can hold another transition:

MapUpdater::State MapUpdater::ConstructNewMap() {
  ...
  if (maybe_transition.is_null() &&
      !TransitionsAccessor::CanHaveMoreTransitions(isolate_, split_map)) {
    return Normalize("Normalize_CantHaveMoreTransitions");
  }
  ...

If no more transitions can be added, then a new dictionary map will be created via Normalize.

obj = {a : 1};
obj.b = 1;
obj.c = 1;

obj2 = {a : 1};
obj2.b = 1.1;   //<---- map of obj becomes deprecated

//Add transitions to the map of obj2
for (let i = 0; i < 1024 + 512; i++) {
  let tmp = {a : 1};
  tmp.b = 1.1;
  tmp['c' + i] = 1;
}

obj.a = 1; //<----- calls UpdateImpl to update map of obj

As the map of obj2 cannot hold anymore transitions, a new dictionary map is created for obj after its property is accessed. This behavior is somewhat unexpected, so Update is often followed by a debug assertion to ensure that the updated map is not a dictionary map (DCHECK is only active in a debug build):

Handle