Chrome Exploitation: An old but good case-study
Since the announcement of the @hack event, one of the world’s largest infosec conferences which will start during Riyadh Season, Haboob’s R&D team submitted 3 talks. All of them got accepted.
One topic in particular is of interest for a lot of vulnerability researchers - browsers exploitation in general, and Chrome exploitation in particular. That said, we decided to present a Chrome exploitation talk which focuses on case-studies we’ve been working on. A generation-to-generation compression on the different era’s chrome exploitation has gone through. Throughout our research, we go through multiple components and analyse whether the techniques and concepts to develop exploits on Chrome has changed.
One of the vulnerabilities that we looked into, dates back to 2017. This vulnerability was demonstrated at Pwn2Own, specifically CVE-2017-15399. The bug existed in Chrome version 62.0.3202.62.
That said, let’s start digging into the bug.
But before we actually start, let's have a sneak-peak at the bug! The bug occurred in V8 Webassembly, the submitted POC:
Root Cause Analysis:
Running the POC on the vulnerable V8 engine triggers the crash, we can observe the crash context:
To accurately deduce which function triggered the crash, we print the stack trace at the time of the crash:
We noticed that the last four function calls inside the stack were not part of Chrome or any of its loaded modules.
So far, we can notice two interesting things, first, the instruction that triggered the bug was accessed on an address that is not mapped into the process. Which could mean that its part of JavaScript Ignition Engine. Secondly, the same address that triggered the crash is hardcoded inside of the Opcode itself:
These function calls were made from two RWX pages and got allocated during execution.
Since the POC uses ASM, the V8 compiles the asmJS module into an opcode using AOT (Ahead of Time Compilation) which is used to enhance performance. We notice that there’s hardcoded memory addresses that potentially could be what’s causing the bug.
A Quick Look Into asmJS:
For now, lets focus entirely on asmJS, and on the following snippet from the POC. We change the variables and function names in a way that could help us understand the snippet better:
The code above gets compiled into machine code using V8, its an asmjs which is basically a standard specified to browsers on how asmJS gets parsed.
When V8 parses a module that begins with use asm, it means that the rest of the code should be treated differently and then compiled into WASM (Webassembly Module). The interface for the asmJS function is:
So asmjs code, accepts three arguments:
stdlib:The stdlib object should contains references to a number of built-in functions to get used as the runtime.foregien:used for user defined functionheap:heap gives you an ArrayBuffer which can be viewed through a number of different lenses, such as Int32Array and Float32Array.
In our POC the stdlib was a typed array function Uint32Array and we created heap memory using WASM memory using the following call:
memory = new WebAssembly.Memory({initial:1});
So, the complete function call should be as the following:
evil_f = module({Uint32Array:Uint32Array},{},memory.buffer);
Now, V8 will compile asmjs module using the hard-codded address of the backing store of JSArrayBuffer for memory.
JSArrayBuffer is std::shared_ptr<> which is counting the references but the address it self was already being compiled into an offset inside the machine code generated. So the reference isn't counted when it's a raw pointer access.
Based on wasm specs, when a memory needs to grow, it must detach the previous memory and its backing store and then free the previously allocated memory. memory.grow(1); // std::shared_ptr<BackingStore> and we can see this behaviour in the file src/wasm/wasm-js.cc
Now the HEAP pointer inside the asmjs module is invalid and pointing to a freed allocation, to trigger the access we just need to call the asmjs.
if we look inside DetachWebAssemblyMemoryBuffer we can see how it frees the backing store:
after that, if we call asmjs module it will trigger the use after free bug.
The following comments should summarize how the use after free occurred:
WebAssemblyMemory
To investigate further into our crash point and attempt to figure out where the hardcoded offset comes from, we tracked down the creation of WasmMemoryObject JSObject that got created in WebAssemblyMemory. Which is a C function that got called from the following javascript line.
evil_f = module({Uint32Array:Uint32Array},{},memory.buffer); // we save a hardcode address to it
We set a break point at NewArrayBuffer which will call ShellArrayBufferAllocator::Allocate, this trace step was necessary to catch the initial created memory buffer (0x11CF0000h), afterwards we set a break on access on it (ba r1 11CF0000h) to catch any accessing attempt that will let us observe the crashing point before the use after free bug occurs.
After our on access break point was triggered, we inspected the assembly instructions around the break point. Which turned out to be the generated assembly instructions for the Asmjs f1 function in our original POC. We can see that it got compiled with Range checks to eliminate out of bounds accesses. We also noticed that the Initial memory allocation was hardcoded in the Opcode.
Executing memory.grow() will free the memory buffer but since it’s address was hardcoded inside the asmjs compiled function (dangling pointer), a use after free bug will occur. Chrome devs did not implement a proper check in the grow process for WasmMemoryObject, They only implemented a check for WasmInstance object and since in our case is asmjs, our object was not treated as WasmInstance object and therefore did not go through the grow checks.
Now we have a clear UAF bug and we'll try to utilize it.
Exploitation
Since the UAF bug allocated memory falls under old space, we needed a way to control that memory region. As this is our first time exploiting such a bug, we found a lot of similarities between Adobe and Chrome in terms of exploiting concepts. But this was not an easy task since that memory management is totally different, and we had to dig deeper into the V8 engine and understand many things like JsObject anatomy for example. The plan was layout on the assumption that if we created another Wasm Instance and hijack it later for code execution is gonna work, so our plan was like the following:
Triggering UAF Bug.
Heap Spray and reclaim the freed address.
Smash & Find Controlled Array.
Achieve Read & Write Primitives.
Achieve Code Execution.
Triggering UAF Bug:
Triggering the bug by calling memory function Grow() for the buffer to be freed. Doing so results with the freed memory region falling under old space, this step is important to reclaim the memory and control the bug. We allocated a decent size for WasmMemory to make sure that the v8 heap will not be fragmented
Heap Spray:
Thanks to our long journey of controlling Adobe bugs, this step was easy to accomplish but the only difference is we don't require poking holes into our spray anymore, since the goal is reclaiming memory. Using JsArray and JSArrayBuffer to spray the heap for achieving both Addrof and RW primitive later on.
Smash & Find:
In order to read forward from the initial controlled UAF memory, we first need a way to corrupt the size of our JsArrayBuffer to something huge. With the help of asmjs we can corrupt them and make a lookup function for that corrupted JsArrayBuffer index, and since we filled our spray with the number ‘4’ then it will act as our magic to search for in the asmjs. Writing an asmjs code is really hectic because of pointer addressing but once you get used to it, it will be easy.
We implemented a lookup function to search for a magic values in the heap:
A simple lookup implementation in JS could look like this, where we are looking for the corrupted array with value 0x56565656 in our spray arrays:
Now that we have an offset to an array that can be used to store JSObjects, we can achieve addrof primitive using the asmjs AddrOf function and use it to leak the address of JSObjects to help us achieve code execution. Please consider that you may need to dig a bit deeper into an object's anatomy to understand what you really need to leak.
We implemented our addrof primitive using the following wrappers:
Achieving Read & Write Primitives:
We are missing one more thing to complete our rocket, which is RW primitives and what we really want is corrupting JsArrayBuffer’s length to give us a forward access to the memory. Since the second DWORD of JsArrayBuffer header contains the length we searched for our size (0x40) and corrupted its length with a bigger size.
Achieving Code Execution:
At last, the final stage of the launch requires two more components. First component is as an asmjs function to overwrite any provided offset and this will help us achieve a primitive write by changing the JsArrayBuffer backing store pointer to an executable memory page:
The second is a wasm instance to allocate PAGE_EXECUTE_READWRITE in v8 to be hijacked by us. A simple definition could look like this:
Putting things together with a simple calc.exe shellcode:
That’s everything, we started with a simple PoC and ended up with achieving code execution :D
Hope you enjoyed reading this post :) See you in @Hack!