Understanding the Root Cause of CVE-2021-21220 – A Chrome Bug from Pwn2Own 2021

I covered lines 3 through 5 in our first blog. Lines 4 and 6 simply use “console.log” to print data. Let’s see what happens in the first and second line:

Line 1: Constructs a Uint32Array (a typed array that can hold 32-bit unsigned integers). The array contains just one element, having the value 2³¹ (2,147,483,648 in decimal or 0x80000000 in hex). The array is assigned to variable arr.

Line 2: A function called “foo” will take the first element of arr (which is 2³¹), XOR it with a constant integer 0, add a constant integer 1, and return the result.

There are some interesting points in these two lines:

        1 - 0x80000000 has its most significant bit set. This is known as the sign bit when handling signed integers.
        2 - XORing any value with zero will return the original value unchanged. If this XOR does not have any effect, then why was it necessary to include it? We will answer this soon.

Save this PoC as “poc.js” and run it with the following command:

$ ./d8 --allow_natives_syntax '/home/lab/Desktop/poc.js'

The only change is inside the function InstructionSelector::VisitChangeInt32ToInt64, found within the file src/compiler/backend/x64/instruction-selector-x64.cc. There is also a nice comment, which can provide us an educated guess. As mentioned in the first blog, a JITted function will be compiled to assembly to achieve maximum speed. Before the patch, on the x64 platform, if there was a load of a signed int32 into a 64-bit register, the kX64Movsxlq opcode would be selected. Conversely, when an unsigned int32 was loaded into a 64-bit register, the kX64Movl opcode would be used. This choice between two opcodes is intended to ensure that the upper 32 bits of the destination register are set properly by the load: When loading an unsigned 32-bit value, the upper 32 bits in the destination should be set to all zeros, whereas when loading a signed 32-bit value, the upper 32 bits in the destination should all be set to match the sign bit of the source value. After the patch, the kX64Movsxlq opcode is used in all cases. As the function name denotes, it expects a signed int32 input, so the kX64Movsxlq opcode is always the correct choice.

Apparently, though, the PoC somehow managed to provide an unsigned input to this function! How is this possible? This is what we must investigate next.

Deep Blue Sea of Nodes

To find the root cause of this vulnerability, we can pass the “--trace-turbo-graph” argument to d8 to see generated turbofan graphs:

./d8 --allow_natives_syntax --trace_turbo_graph '/home/lab/Desktop/poc.js'

This is what we see:

• LoadTypedElement: This shows loading the element from our typed array. The type is Unsigned32.
• SpeculativeNumberBitwiseXor: For the XOR operation. The type is Signed32.
• NumberConstant[1]: For the constant number 1.
• SpeculativeNumberAdd: For adding 1 to the result of the XOR.

All types make sense. Let’s move on to a later phase called “simplified lowering”:

After the simplified lowering phase this becomes:

• LoadTypedElement: Type is still Unsigned32.
• Word32Xor: Type is still Signed32.
• ChangeInt32ToInt64 (#31:Word32Xor): This node is new. It takes the result of the XOR and converts it to Int64. Remember that the patch fixed this vulnerability by changing the InstructionSelector::VisitChangeInt32ToInt64 function. That means this node will be important in our analysis. For now, it seems OK as this node takes a Word32Xor node that is signed.
• Int64Constant[1]: For the constant number 1.
• Int64Add: For adding 1 to the result of the XOR.

The “--trace-turbo-graph” output shows how the engine optimizes the graph by performing numerous transformations. During the early optimization phase, the execution flow reaches a function called MachineOperatorReducer::ReduceWordNXor within v8/src/compiler/machine-operator-reducer.cc to deal with the XOR operation in our PoC:

Let’s have a quick look at the XOR in our PoC again. We XOR arr[0] by 0, and we know that XOR by 0 has no effect and returns arr[0]. Now check the highlighted section in the picture above. Here the engine checks if the right operand is provably equal to 0 and, if so, it replaces the XOR operation with the left node (arr[0]). In this way, the engine removes the no-op XOR to achieve better speed. How cool! Unfortunately, there is a small problem: the replaced XOR operation had an output type of Signed32, but arr[0] has a types of Unsigned32. The EarlyOptimization phase output shows this clearly:

The nodes now are:

When you compare this output with output of simplified lowering phase, we can see 2 major changes:

         1 - The Word32Xor node is not available anymore. It has been replaced.
         2 - The ChangeInt32ToInt64 (#31:Word32Xor) node has been changed to ChangeInt32ToInt64 (#45:LoadTypedElement). This is where the vulnerability occurs. ChangeInt32ToInt64 needs a Signed32 node. This was ok before, because Word32Xor was signed, but now it gets a LoadTypedElement node, which is unsigned.

As a side note: Now that we know the root cause of this vulnerability, we can develop some variants. For example, we can replace the XOR with a SAR using the “>>” operand (check the “MachineOperatorReducer::ReduceWord64Sar” function) or a SHL using the “<<” data-preserve-html-node="true" data-preserve-html-node="true" operand (check the “MachineOperatorReducer::ReduceWord64Shl” function).

Later, execution reaches the vulnerable function InstructionSelector::VisitChangeInt32ToInt64:

It checks if it is a signed load, but we changed the type to unsigned, and thus kX64Movl is chosen.

How can this cause a problem? The kX64Movsxlq opcode translates to an Intel movsxd instruction, while the kX64Movl opcode translates to an intel mov instruction. For a 32-bit source value with the most significant bit not set, there are no differences between these two. However, if the source has a 1 as the most significant bit, these deliver two very different results. Recall that the value stored in the array is 0x80000000, which has the most significant bit set. Let’s illustrate the difference between movsxd and mov by doing a small experiment in x64dbg. We will perform a ‘movsxd’ of a 32-bit value 0x80000000 to ‘rbx” and ‘mov’ of the same 32-bit value 0x80000000 to rcx. Here are the registers before the move instructions:

As you can see, the value of rbx is very different than rcx. As opposed to the mov instruction, the movsxd instruction sign-extended the value. Now if the engine chooses the wrong instruction, it may load incorrect value into registers causing various problems.

Before finishing this blog, I would like to clarify one more point. Why is it needed to have an “add 1”? In fact, if you remove it, this vulnerability is not triggered anymore, and the PoC does not reach to the vulnerable function! Why is that?

To answer this question, we can remove the “add 1” from the PoC and examine the effect on the graph.

First, the graph if the “add 1” is removed:

By including an “add 1” operation, the result of XOR (which is Signed32) needs to be first converted to int64 using a ChangeInt32ToInt64 node in preparation for the addition. Note that 1 is an Int64Constant. After the add, the result is changed to a tagged value and returned.

Therefore, we conclude that the “add 1” is needed to trigger insertion of a “ChangeInt32ToInt64” node.