Chrome Browser Exploitation: From Zero to Heap Sandbox Escape

Hello. Does it work? Yeah, I think so. All right. All right. Uh good morning everyone and thank you for being here. Um today we're going to dive into Chrome exploitation. uh we'll go through the inner workers of Chrome architecture focusing on the V8 JavaScript engine and its uh exploitation pathways. Um turn it on. Yeah. So um we'll start by exploring the Chrome architecture and the V8 pipeline to set a foundation for understanding how things work under the hood. Then we'll uh take a look at a vulnerability class named type confusion which will serve as a stepping stone into discussing the three CVs for for today. Um the first one predates the V8 heap sandbox. Um then we move to modern

sandbox there with the second CV. Um we wrap it up with the third one uh which which serves as a fresh example of present day vulnerabilities. So technology is not with us today. Okay. All right. I haven't done anything. What's going on? Yeah,

it's because I have too many slides, I guess. Nope. Um, >> we had the whole break to get this working. >> Yeah, it was working. I think >> we did. >> Yeah, but >> it's luck. Better now than later. Yeah, >> we have some. >> Oh, I I don't see. Yeah, now it's back. Can Can we try with this? >> Yep.

ICD projector. [Music] >> Yeah. >> You good? >> USB3 required for this device. Okay. >> Do you see a signal?

Uh

>> does it work? Yeah.

>> This is the tough part of having demos on >> everybody's personal >> Yeah. Yeah. >> PC, but we're in it to win it. >> Cool. Well, uh, nice, nice, nice, nice. Thanks, guys. Cool. >> It's um so hopefully it's less boring now. Um so uh as I as I was saying so we wrap it up with the third and last one CV which serve as a fresh example fresh example of present day vulnerabilities inside Chrome. So let's get it started. Uh my name is Mateo. I'm a content dev and researcher at OBSC. I'm Italian based in Norway and occasionally I play drums in a local indie band. Um so where do we start? Bit of context before uh we jump

head first into details. Um why all of this matters? So so browsers are one of the most used software worldwide, right? So they are valuable targets for attackers and they are always connected. So they allow for any bug can be exploited and then can be pivoted as remote code execution. They also demand speed, right? We always have like dozens of tabs open all the time on our browser. So they need to be fast and memory efficient. That's why we have JIT compilers and JIT compilers as we as we uh see in a second they are really complex software and we know that complex softwares leads to bugs. Um so let's get um um a brief overview

of Chrome architecture before we start. But today's focus is uh Chrome and uh it's engine jet engine is called V8 on Windows. Why Windows? Because it's the most rolled out uh operating system in target uh in um in today's enterprises. So that's why Windows um this is um that's going to have a brief overview on Chromium architecture. So as many browsers chromes run on multiple process the main process uh communicates with multiple isolated rendering process um through uh inter process communication or IPC to keep the renderer isolated um but what is a renderer process and what it does actually so each render process is responsible for rendering uh JavaScript DOM uh and CSS amongst other things. Um,

as you can imagine, the renderer process is the most vulnerable piece of the chain since it's ingesting all the untrusted JavaScript code. And to protect each renderer process, we also have the process sandbox which is outside of the scope for today talk. So, so we normally have a sandbox on top of each process which is called process sandbox. Um, but before analyzing the first bug today, let's discuss how V8 the JavaScript engine works. uh under the hood right so from a bird's eye perspective from bird's eye view that's V8 uh operation so ideally is also applies also to other JavaScript engines for other browsers but what do we have we have a parser an interpreter and an

optional compiler right so the parser is one responsible for processing the uh JavaScript source code so it breaks into token and generate an a and abstract syntax X3 the A3 um is a structure which represent the code syntax relationship and those tokens are barely like if you have a statement like X equals uh 10 each token it's a single individual representation. So the parser generate this abstract syntax tree which basically represent an hierarchical structure of the of the different code tokens. Then uh we have the interpreter which takes the a this tree as an input and generate uh bite code. Uh bite code is just an intermediate representation of the program which is designed to be

executed by the interpreter virtual machine and the interpreter originally could just execute wherever JavaScript locally. So from the VM it could just generate machine code and via the virtual machine and generate it. So back in the days browser just had the interpreter mainly. Um but suddenly uh we need as we anticipated we need speed we need um um good memory footprint right so we need a better way to optimize the machine code that's why we have compiler so and um some of these compiler are just in time compilers which means they are generating um optimized machine code at uh in runtime right um this is a more actual uh view of the V8 pipeline from 2022, so two years ago.

Um what do we have? We have the parser which again uh output an abstra sign tree and it gives it to ignition which is the interpreter. Um then we have as I said we have we can have just local context execution from the uh interpreter. However, one of the responsibility of the interpreter nowadays is to generate statistics and data about what's going on, which kind of function are executed and this is done through the profiler. Um the profiler uh sends uh and marks as hot code whatever function is executed multiple times. So let's say we have a function that is executed like 10,000 multiple times even more and then uh at that point the function is marked as hot

code. or hot function and this is signal to the JIT compilers. Uh in two two years ago we had two different JIT compilers uh turbopan and spark plug. So uh spark plug is the nonoptimized compiler and turbopan it's the optimized one. We'll see what's the difference in a in a second. So basically whenever we have an a hot code so a function that might takes might be executed a lot of time then um we kick in with the JIT compilers they do their optimized code and then the function gets executed sounds simple and so this is the actual uh today's pipeline so there's a new actor called uh magalv so in December 2023 last year Google introduced um a

new gif compiler called maglov that acts as a as a compromise between spark spark plug and um and turbopan. So actually we have a four tiers pipeline. So we have four actors that can uh execute code ignition in a in a more uh simple way and then we have the three jit compilers. uh all three they um can generate different kind of optimized machine code but they are uh fast and optimized in in a in a different way. So for instance tuban is one that is uh generated the most optimized machine code but it's also the the one that takes a lot of time to produce that code. So in case we have some uh some

JavaScript code that requires to be optimized quicker then we might use spark plug or magv according to our needs. Um so let's get now a brief overview on javascript types byte code and the entire jit compilation pipeline. Um so how actually javascript gets executed in uh in v8. Um as we say as we say ignition is not optimal. So the uh the interpreter it just execute JavaScript code through the virtual machine. So it's not optimize at all the machine code that it it that that produces. Uh but anyways let's see how JavaScript code works behind the scene. Um so the interpreter as we said just takes bite code as as an input and execute it via the JavaScript virtual

machine right and the virtual machine is responsible for executing the uh the final byte code right so but what is actually uh byte code in the end so this is a simple example of byte code um we have a function that adds uh two to the um to whatever property right we are we are we are sending in. So we are calling the add to function and the function takes property x of an object and adds to to it. So uh the first line uh is responsible for loading an smi. What is an smi? It's a small integer into the accumulator. So in um JavaScript virtual machine we have virtual registers since as a virtual machine one of those

register it's the accumulator which is not an actual physical register as you would have in a in a CPU the accumulator is just a virtual register but this is very handy to do uh short operation. So in this case we load two in the accumulator on the first line then we store um the value in the accumulator into R0. store store a into r0 and get and then on third line we uh call get name property which uh basically we load the function argument a z so the first one into the accumulator next we add whatever we have in the in in r0 in this case two and whatever we add it to the accumulator value in this case 13

because we are uh passing 13 as a as an argument then we we will return on the last line 15 to the um from the accumulator to whatever calling function we had that was just a simple uh bite code example. So we also have just in time compilation as me as mentioned. Um so the uh the interpreter generated code is not optimal right uh when functions are executed too often. And how do we solve this? Um with just in time compilation right um so but first off we need to to solve some some issues with uh with JavaScript with the JavaScript language. So how do we store type information? Um as JavaScript is a dynamically typed

language, the engine must store type information with every runtime value. Um this is in V8 this is accomplished through a combination of pointer tagging and the use of dedicated type information objects that are called maps. Uh here we have all the different kind of object that we can have in the in the g engine. Basically we have uh smi basically small integers and everything else is a is a hip object. So uh the the engine treats everything as a heap object right and among these object we also have something called map which is really important for our focus today. Um in the end um the engine is marking as a least significant bit zero anything

that is an SMI and with one anything that is a heap object. So the least significant bit plays a crucial role in how the engine treats object or small integer. Um yeah so but um so we we mentioned that JavaScript is a loss uh type languages so the compiler doesn't know uh the data types in advance but it learns from the past round and guesses how the code will be used in the future uh and it makes optimization based on those assumption like creating faster code assuming the types will stay the same. Um, as we mentioned, how actually does JavaScript keeps track on on data types? More on that in a second. But in C++, for

instance, we have this simple function that adds to integer and we can produce fairly consistent assembly code, right? Because it's um um it's a language with with strong types, right? JavaScript, however, on the on the other end, it doesn't. So we don't know which values will be passed to the this function at uh beforehand right so we need to keep tracks of data types how we do that with maps um there's a really uh key feature in V8 in the JavaScript engine but they also referred as hidden class in the JavaScript specification or uh shapes in spider monkey which is the JavaScript engine for Firefox or butterfly structures in JavaScript core in Safari or hidden types in Chakra

which is the old uh edge. So really not confusing at all. Um so but in this case maps uh so V8 and Chrome they use maps. So we we will stick with this terminology for now. And in this example we have an object with two properties one and two. So two small integers. So let's see how they uh they do look like in memory. So when we need whenever we need to debug something in um in V8 in the JavaScript engine and we compile it, we don't need to compile the whole Chromium project because by the ways it takes like five hours on a beefy even even more on a beefy PC today. So it

takes a lot of time compiling the whole Chrome. We just need to compile V8 and it comes with an handy tool called D8 which is debugging engine. So we can debug V8 through D8 which can print a lot of different values and normally we wouldn't be able to. In this case we are printing object one and in the green box we have the um the array right with all the elements of set and then in red we have the map okay at that address. Uh let's add a second object with similar types with same types values but different values actually same type different values. So guess what? We just print object to in memory and we have

the same map. Meaning that uh object with the same maps, they will share also the same map in memory. This is a way for VA to be efficient. So we don't create a new map for for object that that share the same types, right? And they also share the same fixed array. Um so we mentioned turban in the beginning with it which is the optimized JIT compiler in V8. Let's see how it does look behind the scene, right? Um, so it's the optimized JIT compiler. We have three JIT compiler now. We have spark plug, we have maglov, and then we have turbopan. And it basically takes a bite code from the interpreter and it creates an intermediate um custom

representation also IR which is a graph basically with nodes which are code operation contraflow edges and data flow edges which are the input and output of the bite code. Um so how it does operate actually um an air graph is built by analyzing bite code and type profiles formulating speculation about types and possibly guarding them with speculation guards. More on that later on speculation guards. So once the uh the JIT compiler is happy with the with the graph building it starts with the important phase of optimization. So the JavaScript is improved and the memory footprint is is reduced. And then we have the last phase which is lowering. So it basically push the optimized machine code to

memory for optimal execution. Cool. So we mentioned speculation guards. What are speculation guards? Um so there's no guarantee we have no guarantee that the maps will stay the same for a given object in time. Right? So JavaScript is a dynamic dynamic language. So that's changes. Um so um ignition the interpreter generates feedback which is used by turbopan to make um speculation about about the time the type right of of a given property for instance and then turbopan use something called speculation guard to make sure that we don't have bugs at must at much as we as we can. We don't have bugs that are hitting type right of of a property. So in this case we have

two example of uh not sure if the pointer works but it the first one it's the uh it's a speculation guard that makes sure that the we have we are dealing with an SMI we mention at the beginning that every Smi has at least significant bit zero we're making sure that if not we bail out so we test the actual property is a is a small integer if not we bail out what does mean we bail out we don't crash the pro the process obviously Otherwise it wouldn't be reliable. What we do here is we s simply deoptimize the machine code. So we we go back to the uh interpreter and and tell the interpreter okay just uh generate

not optimized code because clearly we have something wrong going on and we cannot risk of using a map that is not what it what is actually that is not representing the type the correct type. In the second example, we actually checking the uh pointer pointer pointed by RDI on a given map and if that pointer is not matching the given map, then again we bail out and deoptimize the code. That's in general. Um so let's move on to JIT. So everything is uh nice and fun. We have JIT compilation and we mentioned that we can have something called hot function in the beginning. We have something here as an example of a hot function. So it's

simple function that adds to property of the of an object and execute that function uh several times 10,000 times here and we assign I to both property AB at runtime. Right? So at this point the interpreter should be smart enough and signal turbopan hey we have a not function. So this stuff gets executed a lot of time. We we have to do something. We have to produce optimize code. I have I'm not capable enough to optimize in code, right? So um one of the optimization feature of the JIT compiler tuban for instance is something called redundancy redundancy elimination. In this case again we have a function named fu that returns the sum of two properties. Um these um features

basically um it's a class of uh optimization for in turopan that aims to remove safely checks from emitted machine code if it's thinks it's unnecessary. Basically here we have uh the check on um on the object right the check heap object and check map two times right on the first block on the second block. Um so Turboan just decides okay why don't we remove the second check it's just repetition it's uh it's unnecessary. Um however are we really sure that we cannot have any possible side effect in between elimination. What can possibly go wrong here? Um right let's introduce a block class called type confusion vulnerabilities which is fairly new uh vulnerability class. So um ganges are complex because compiling

at runtime requires balancing speed optimization and secure coding back bugs arises uh during JIT compilation due to missing checks. That's basically what our type confusion. So as we said, Jet engines are highly complex systems. Uh so we have high chances of bugs. Uh the Jet engine assures that data is one uh of one type at compile time. Okay. However, due to side effects, unforeseen side effects of JavaScript operation at sometimes at runtime that that data uh type changes without the related type checks. So we are missing the right speculation guards for instance. And then we can have something that goes wrong here. So um type confusion might lead to out of bound read and write and ultimately code

execution. So the important key takeaway here is that we have a logical bug that turns out to be a memory corruption bug which can open also discussion on Rust on safe uh programming languages and so on. Uh but uh let's not digress. Let's discuss one of now the first one of the three bugs. Um so um the first uh the first bug here is a very typical type confusion and predates the heap sandbox. So we can get a sense of how V8 bug can get exploited without extra mitigation. So uh this is a bug that's been filed by Samras from project zero um which is by the way is the he's also the author of

the modern v V8 heap sandbox. Um in line this line the the yellow part is basically the root cause of the bug. So here the ko write operator states that the engines assumes that um this operation will not have any observable side effects. Right? So um basically the objects map here change without becoming a prototype. So what's what's happening here is that we uh call the map get get object create map. Uh so what this function does basically generates a new map for a given object. Uh however the newly created object is converted to a prototype object which also change the object associated map. Uh this is a kind of unforeseen side effect that the GI compiler hasn't taken

into account. Um so we have something also called maps confusion. It's just my definition but it's also a specific type confusion when you're actually confusing maps which happens a lot of time in JIT engines. Uh in this case we are analyzing the debuggy code the bugging V8 version. So we print the object, we invoke the vulnerable function object create and then we print again the object and see what happens. So the first time we print the object we have a map of fast property types. The second time the map changes magically it's dictionary properties. Now that's not good because we should have a deterministic map as much as we can. If the map change we we

are and the type is not checked we are able to uh abuse this um this situation. So um I'm not going to cover all the exploitation steps because that will require a lot of time for each bug. But uh from high level whenever we end we have obtain uh whenever sorry whenever we obtain um relative read and write primitives from that we can obtain arbitrary read and write primitives. Um and then what about code execution? So we are able to write and read in the V8 heap arbiterally. So how can we execute our shell code? um especially because the V8 heap is has NX. So we cannot execute code here. Page are read write but not executable.

What do we do? Uh let's enter web assembly and specifically web assembly shell code. So web assembly is an in browser uh client side aid for lower um language type like C uh lower level uh support for C or C++. It's compiled by another entity called a liftoff in in the chromium. And we also to reference web assembly code in V8 we have something called jumpstable. Basically they are jump stable to WASP function to web assembly function and those pages are rewrite executable. So yay. So we can basically execute one shell code and reference it from va tip. So that this is the first demo which is pre-recorded. Uh here we can uh just test the same the whole

exploit and get um reverse shell from our Kal Linux. Cool. That's the first one. Uh moving on second CVE. This is um modern era uh sandbox bug from last year. It affects magv. We mentioned the new compiler magv. Uh this bug has been discovered by manu from GitHub research. Um so as anything new uh with with any software it will brings bugs to it right but before analyzing the bug itself let's first explore what is the purpose of the hip sandbox uh which is one of the goals of our presentation. So we mentioned the process sandbox at the beginning right the process sandbox is the sandbox that is actually protecting the entire renderer process or other chrome

processes. This has nothing to do with that. So this is a sandbox that is supposed to protect the actual heap in the renderer. So um so up until now we needed just two vulnerabilities to get system foothold via a browser exploit. So we need two basically uh vulnerabilities. One on the renderer and one to escape the process sandbox, right? And we could get on the host. Now the situation is a little bit complex more complex. So we need three vulnerabilities or like two bugs and one bypass. So again the renderer then we need the hip sandbox bypass and then the process sandbox. So it the cost for attackers is definitely increased. Um how does it work? How the V8 heap is

actually working. So um has been rolled out like around 2022 three years ago. Um it's software based and it runs in a isolated hip. So the V8 heap is contained basically in the sandbox referred also as a cage or Uber cage which is a predefined memory region that is defined at startup. Um and we have something called pointer table which is the uh essence of these uh sandbox basically. So objects inside the heap are referenced via offset and and index into an a pointer table that exists outside the V8 heap. So what's the deal with that? Basically, we don't have full pointers anymore in the hip. So what were possible in the past that we normally in

a typical bug like the the first one we we mentioned today, we had something called um backing store pointer in an array buffer. This is an array buffer dump. In yellow, we have in the in the first output, we have something called the backing store pointer. So we have a full pointer that can be abused to obtain arbitrary read and write primitives. And with a hip sandbox, we don't have it anymore. We just have a 45C which is an offset to the jump table. Uh not how it's called um the pointer table. Sorry, not jump jump table. However, we have an offset not a not a full pointer anymore anymore. So we cannot do much, right? So we just

have an offset. So one of the goal of the heap sandbox is to remove all the pointers in the V8 heap. So attackers even though even though they get uh read and write access into the sandbox, they cannot abuse it that much, right? Um so let's go back to the the second CV and its analysis. Um we mentioned that magv is is a new compiler rolled out last year. is mid-tier compiler that balance efficiency between a spark spark plug and touan. Uh it generate less optimized code but it does it quicker than turbopan. So in some cases you want to you want to use uh mag lev instead of tuban. This is just done behind the scene by v8. You

don't have to configure anything but this is a logic that is implemented in the engine. Um the bug itself is a failure check while creating a default receiver object. Um again the same map is used for a different type. Sounds familiar. Again maps conf maps confusion which leads to type confusion. Um okay. Uh what's the what's the deal for us? So standard web assembly shell code is not possible anymore due to heap sandbox. So we cannot reference it any anymore. Um but we can still read and write some function pointers right because we mentioned that the heap sandbox has been rolled out two years ago but until recent times it wasn't fully completed so they rolled it out but it wasn't as

uh as perfect as it is today. It's not perfect today but it's better. Um so back then last year not every pointer was actually an offset. That's the whole point right? So um g compile function pointers are represented as full pointers in the from from the heap perspect from the v8 heap perspective. So we can still abuse those pointers. Um how we do that? Um we can modify those function pointer to jump right into jetpring shell code. So what the heck is jetpring shell code? Let's see what it is. Uh it's fairly new technique. um like it has one or two years old something like that. So basically what do you have here? We have

a fun an empty function that is just returning three floats 1.1 2.2 and 3.3 right then we uh jet compile that function and as a last statement we just print the function and see how does it look in a debugger. Let's see how does it look. Um so this is from uh windbg. So that's the um g optimized code from that function, right? And what we see here in the in the red uh in the red block is that basically that number is moved to R10. And we have the same for the other two numbers. So likely those are those our floats, our three floats. And if we convert that value into double, that's 1.1. So that's the our

first float. But what's the deal? Why it's helpful this? Well, what if we could treat this float data as a code and not data? So, let's change those three values or float value in something completely um that doesn't make sense apparently and three random floats and see how this looks like in memory. So, we dump the same value and instead of dumping the value we disassemble it and guess what those floats are converted to assembly. So we have one break point and a few knobs. So the idea here we can basically jump over those floats value that are suddenly are interpreted. We can interpreter as um instruction of our shell code and we jump over those unnecessary uh

v keywords instruction that are not necessary. So basically we jump between chunks of shell code of our choosing. Uh the only caveat here is that we can only encode six byt at a time. So we have six byt or shell code and then the jumps instruction. But uh we can generate that shell code pretty easily with the pone tools. I haven't found a better ways to do that. Sorry. But uh that's what we have pone tools. We can write the shell code as a as always as assembly and then print it out as JavaScript uh floating points right values and then then we replace the um this shell code inside our our exploit. So we have a tool that can

generate that we can we don't have to do that manually. So let's demonstrate the second exploit with the second demo. Um yeah, here we're getting cal because yeah I was lazy enough to get a full reversal but yeah that's code execution uh on Windows. So the last um CV that I'm going to present today is pretty recent from the right apps were for August. Yeah, cool. Um this is um another type confusion found by Manu Mo again from GitHub research. Um so this is another type confusion in maps uh via the prepare for data property. Uh basically when an object structure changes like property edition a new map is created and it occurs the bags happen while

transitioning uh from from one map to another without the the expected checks. That's again similar to what we saw earlier but in a different piece of code. Um so how do we perform the sandbox escape? So previously we used uh Jet uh JIT compile pointers but now in this latest version of the heap sandbox the uh web assembly pointers are gone. So we cannot abuse those anymore. Uh we have something else in in Chrome called blink which is responsible for rendering web pages like it process HTML, CSS, layout and DOM but lives outside V8. So this is not part of the Jeet engine. Um however um inside V8 heap we can uh reference we reference

those object by embedder fields in the heap. Obviously those objects are referenced as offset as we saw in the um heap sandbox definition. So we don't have full pointers but we just have offset. So what if we can cause a second level type confusion by swapping those offset and yeah so we basically have rewrite primitive outside the vip. So we are not actually um bypassing the V8 V8 sandbox per se but we we just leave by the rules and yeah apply the readr primitives by the offset not the full pointer. So with that basically we we are um leaking the trusted cage base which is the heap sandbox base address. So we can get full right primitives and

um locate the address of the git compile web assembly through the import target. So we have uh the import target function in the dispatch table and then we hijack the code pointer of dome rect x basically the properties of this object which is one of the object from blink that uh blink we are abusing which is lives outside v8. So basically in the end we are hijacking uh wm jit code um when the exported function is called in the end. So under normal circumstances calling a a web assembly function alone will let it just execute it inside the W. So sort of sandbox with no interaction with the rest of the system. But this way we are creating time

confusion inside uh external V8 objects. Uh so for the last demo I decided to do it live on a box that it's home. Let's see if it works. It's a bit risky. Let's see. How do I share this? I think I need to stop presenting

H. Cool. How do I share a second?

Give me a Sorry. Give me a second.

Okay. Maybe

Yes. Okay. Cool. All right. Can you see anything? Yes. So, um, we have our Kal Linux listening on port 443. We have a web server in Python that's serving the exploits. And then we have the official Chrome build. A thing that I didn't mention that here to the back the whole exploit we couldn't just have V8 we we had to compile the entire thing the entire chrome because the object that we are abusing in the end they are from blink. So let's start chrome with the no sandbox option meaning that we are not going to test the process sandbox. So what we do here is that surf on the vulnerable server and the vulnerable Yeah. And then

and then we get a shell on Kali. Yes, that's a full reverse shell. Yes. Thanks. So uh a few key takeaways from from this. U as we said browser are complex high valued uh targets for attackers. uh type confusion bugs will likely persist in V8 due to G enginee because it's a complex piece of software. We're going to have um bugs no matter what. Uh however, V8 heap sandbox increase the attacker's cost but as we saw it's not bulletproof. So we're going to have bypasses likely until it's going to be rolled out with full hardware support likely. Now the end result that three bugs are now required to get a full system shell. Uh all the parks for today you can find

it on on this website. Thank you. [Applause]