 Jonathan. Wonderful. Good morning. You're going to tell us about the last 12 months on what you have done. So your talk is called From Zero to Zero Day. This is Jonathan Jay from the MSRC in Israel, a division of Microsoft. And the stage is yours and that is your applause. Thank you. So hi everyone. My name is Jonathan and I'm a security researcher in MSRC in Israel. On my free time I play CTFs with Team Perfect Blue and I also do research on my own. I'm just an 18-year-old and I started doing security related stuff last year. So the first part of this talk is going to be about what I learned in the past year and how I learned it. So if you're just starting off in security and you want to learn what to pick up what I did and learn from what I did, this could be helpful for you. And for the more experienced security researchers in the audience, the second part of this talk is going to be about a zero day I found in Chakra, a jit-type confusion. So we're going to dive deep into that. And even if you're just starting in security, a basic understanding in programming is probably going to be enough to follow up. There's going to be a lot of code but it's fine. It's not too complex. And last but not least we're going to finish up with a demo, hopefully working one. So yeah, let's start off. So why vulnerability research? Vulnerabilities are for me some sort of riddles. There is some sort of very challenging riddles that we have to find some flaws that the developers did not consider. This is very challenging and very interesting for me at least and I found it awesome to do. So what is a vulnerability? There are a lot of definitions to it and when you want to understand something, you start a job on Wikipedia. There are a lot of definitions as you can see. It's some more weird like the probability that an asset will be unable to resist the actions of a threat agent. I don't know what that means. Yeah, for me a vulnerability is some sort of flaw in a program that allows you to change the intended flaw of the program. That's what I consider as a vulnerability and the definitions we've just seen do not really tell me how I find them. So how do we find vulnerabilities? So when I started, I had some knowledge in programming. I wasn't the best developer out there. I was just a decent one and on a good level and see and assembling and always internals to understand how things actually work in Python to actually write some code. So I wasn't the best developer but I had some knowledge. For example, I read the C programming language, which is a great book and will give you all the C knowledge you need to know in order to actually get into vulnerability research. The next thing I did was to explore myself through vulnerability research basics. So I read online about some basic vulnerabilities like classic stack buffer overflows, like integer overflows and so on. And then I tried to practice my knowledge and that was through war games. War games are some challenges that are offline and you can try to solve them. They're security related challenges like you have to find some vulnerability and exploit it. So that's what I did next and at first I failed like badly but it's okay because I read the solutions, I read the write-ups and I learned how to actually approach the solutions and actually how to solve them. So it comes with time and it's okay to fail because we all do. The next thing I did was to explore myself through CTFs. Now CTFs are captured at flag contests and they're basically competitions where you have to solve some challenges and compete against other teams. This is a team effort and you play with other players, your friends. And this is how I met my teammates. So we met through CTFs through IRC and we played together and sometimes we fail like miserably but sometimes we actually do well and we got to qualify to some finals and we actually got to travel the world because when you qualify to finals they sometimes pay for the trip. So we actually got to see some cool places and yeah that was awesome and I actually think CTFs are a great way to get into security. So next thing I did was I dove into the dipwater. So once you know the basics it's important to not stay there for too long. You have to expose yourself to harder things. I was afraid to see and try to solve the harder challenges at first but with time I managed to understand that nothing too bad would happen even if I fail. So I tried to solve challenges and I failed but with time I managed to pick up the tricks and the ways to solve the harder challenges and I think this is very important to not be afraid to solve things because even if you fail you learn from other people's solutions and it's fine, it's totally okay. A great tweet by LiveOverflow which also should be in the audience or in the conference and basically says what I really believe in which is move away from the basics as soon as possible and expose yourself to harder things which you don't understand. This will make you understand things that you thought you understood but you actually didn't and also it's important to learn from different resources. This way you learn different tricks and different ways to approach problem solving and it's very important in my opinion. So yeah LiveOverflow also has a great YouTube channel which I also watch and he talks about vulnerability and security research and I really recommend watching his videos as well. So after I had some knowledge in CTFs and wargames I practiced and I practiced a lot. So it's really important to practice and solve challenges on your own because this way you actually get to pick up those tricks that you have to understand in order to solve some challenges. So some vulnerabilities have patterns in them and the way you catch on those patterns is by seeing them quite a few times and a great way to do that and to pick that up is by solving a lot of challenges. This is where I also expose myself to actual real-world vulnerabilities. I did that through like a lot of websites there is Project Zero bug tracker which you have you can read the vulnerabilities and about exploits and all and so on. So this is where I also expose myself to real-world vulnerabilities and I also realized that there is a great connection between vulnerabilities in CTFs and in real world. So vulnerabilities are essentially bugs and they exist both in CTFs and in real life and the main problem that you think you have when you actually try to do real-world research is that you think that the code base is huge and stuff like that but even if the code base is huge bugs are still out there. So don't be afraid to look at it because the odds of vulnerabilities running out just when you're starting to look at something are very low. So you can start to try and solve things and by solving things I mean looking at actual code bases. After doing some practice I realized that how do we find our vulnerabilities and once we actually start and repeat the process of solving challenges and practicing we notice that vulnerability research is about identifying bugs and we do that by looking at code. So looking at code is essentially understanding the code and we have to find vulnerabilities in it right because we want to find them and that's through actually auditing the code and that comes with practice. So practice is really important in vulnerability research and once we master that even though I'm not a master and I'm not near or nearer that I still think that practice is important. So how do we actually find vulnerabilities? So after as I said before vulnerabilities have patterns in them and patterns are something that you catch up with time and we might I wasn't doing that for so long I'm doing it just for a year so how did I catch it up that was basically through a practice as I said before practice can be it can cover the time that you're not doing that for so long. So I managed to notice that vulnerabilities have patterns in them for example programming errors like integer overflows and and sign this issue these are bugs that actually exist because people make mistakes and we're all humans and humans make mistakes we're not perfect. A great example for such a mistake is the following code so on the third line we have an integer overflow which a lot of developers know and know about the existence of this vulnerability yet they still make this mistake it's it's as I said before it's about it's because we are all humans and human make mistakes so don't be afraid to look at actual code bases because these these kind of bugs actually exist in actual code bases not only in CTFs so don't be afraid to look at actual vulnerabilities you can find simple ones as well so there is a great difference between CTFs and real-world vulnerabilities and CTFs usually when you find the vulnerability you know what you need to do with it you know what you have to progress with it you know what you need to have what you need to exploit how you need to exploit it so sometimes you have a stock buffer overflows you need to override some variable the return address or you can override a function pointer there are you mostly when you see a vulnerability in CTF you know what you need to do with it in real-world you usually have a set of weird states a set of primitives that you have primitives are essentially capabilities we have as attackers so you usually have some primitives that we can chain together to do something greater and that can later lead to vulnerability and as such example of that will be the vulnerability I found in chakra which is basically a bunch of primitives together chain together to make an actual vulnerability so this is basically everything I knew about vulnerability research and security research before I started looking in chakra so yeah let's dive into some JavaScript so JavaScript engines I didn't say I learned JavaScript because I didn't and JavaScript is a very readable language it's once you have learned a few programming languages reading JavaScript would probably be more smooth and more smooth process so doing that would not be too hard now just engines are basically what's capable of running the code that you write as a JavaScript developer they have a lot of parts to them and the one the most important one for us is the JIT compiler now JIT stands for just-in-time compiler what it essentially does is when some function gets hot and it's being called a lot of times it compiles this function to machine code to improve performance now this compilation is this just this JIT compiler is also incapable is also responsible off doing optimizations for the code it has a lot of assumptions about the code and doesn't want assumptions to be broken so we'll see just how that works later and about JIT compiler vulnerabilities so about JavaScript basics so JavaScript is a dynamically type language and it's fairly readable you can make arrays in different ways you have you can have a raise with different types of elements and you can have console log to actually print stuff so JavaScript has prototypes prototypes are essentially something that you can in some way you can inherit features from other objects so for example in our case we have a parent object and a child object so the child object if it the prototype of it is the parent object then it will inherit some features in this case the properties x and y so this actually is very fairly important to us in the exploit and the vulnerability I found and you can modify the prototype by accessing the proto the proto property. JavaScript also has something called proxy now our proxy is an object that can wrap another object and redefine basic basic operations like getters and setters so in our case we redefined the getters so we redefined the getter in which we're supposed to get x to be one three three seven but due to the fact that the proxy redefines the behavior what happens is the getter handler is actually being called so we redefined the basic the basic operation of the getter and in this way we actually trapped a function the function called to the getter of this object so JavaScript has arrays as we've seen but chakra has arrays with types so the first time we're going to talk about is called the JavaScript native interay and it is the way chakra calls integer array basically it's an array that stores integers which are which are four bytes per element and they're basically integers. JavaScript also has a native float array which is essentially floats and unlike the C definition for float this this float is actually eight bytes and they store floats and they're eight byte pile elements and we have JavaScript arrays which are object they store objects essentially pointers and they are also eight bytes per element so let's see about about how we can convert between the types so if we start off with an array of integers and we add a float to it what happens is we convert the array to a float array and if we add a object to it the conversion that takes place is a conversion to a JavaScript array if we have both floats and integers the outcome is a float array so if we have both floats and integers and some objects and mixed array what happens is this array is considered to be a JavaScript array and the most weird conversion that takes place is this one and you usually don't see this when you see about conversions in JavaScript engines but this is very crucial for our talk so when you have two arrays and you assign one of them to be the prototype of another one the prototype one is directly converted to a JavaScript array now this is going to be very important to us later so keep that in mind and this basically the conversion takes place right when this what right when the assignment takes place so let's see about how array layout actually looks like in memory so when we have an array for example in this case a JavaScript array it has some flags which indicates some some things about the array and it's called array flags we have the length of the array and we have the head now a head is a pointer essentially to a segment and a segment is a continuous memory region which has elements in this so it has some of the elements in the array and it stores another pointer to the next segment so what what comes out is essentially a linked list of segments that start off with the head pointer in the JavaScript array so let's see how that actually looks in memory we have the simple example where we have two point two two values in this case integers and we have an array with two values so and let's see how it actually looks like in memory so in red we have the JavaScript array properties so we can see the initial array value which is the array flags value and we have in in green we have the actual segment so we can see the segment has a length and the size and in blue we can actually see the memory layout of the segment and if you notice on the right bottom we have the two elements we defined so we actually can see this in memory and this is how it looks like so what is the array flags I was just talking about so array flags basically some flags that indicate some things about the array in our case it's and it's defined in it as an enum and the interesting field for us is there has no missing values flag and so if we did that for for those of you who noticed the the initial array value that was defined as our array flags is actually composed of two different flags it's composed of the array object array flags tag and it has no missing values tag so the the first one is not really important for our talk so we'll focus on the second one which basically means that the array doesn't have any holes in it now what does they all mean so we can create an array and have some values between the like we have for in this case we have three elements but the middle one is missing so it's important to say that the values I put there are the way the way they're represented in memory is by those constants and I try I chose them because it will be easier for us to see them to actually notice them when we see the memory layout as we've seen before so as you can see this one has a hole and the array flags doesn't have there has no missing values on which means we have a hole in the array and things actually make sense but when we look at the memory layout we see some weird thing so as you can see we have the dead beef and the four one but between them where the missing value where the hole was we have some magic constant now makes sense that this constant would represent a missing value or a hole in the array but as we've seen before the there's already something that rep that tells we tells us when we have holes in your a it's there has no missing values flag so we know that there is one way to indicate holes in the array and it's the flag we've seen before but it seems like there is another way to tell if there is a hole in there's holes in a raise so that's kind of weird that raises a lot of questions we have basically have here we potentially can have here two things that indicate should indicate the same state we have the flag of the array which is there has no missing values flag and we have the content of the array which we've seen before and is the FFF constant so if we can what happens with if they're if they're like mismatched what if what happens when if we can if we can do that get the has no missing values to be set to true and therefore it says that we don't have any holes but we actually have a missing value in the array also we mix we some sort of mix data and metadata together because if the constant is being used in a control flow that could be that could be interesting for us if we can fake it and it actually is very interesting and we can it turns out that we can actually fake a missing value and this was a vulnerability find by Loki hard and sort of my bad and you got CVE for it so basically what they did is they faked a missing value by putting the constant we've just seen before into a float array so we could beforehand the value was not the same one that we've seen and it was something that you could actually represent is a valid float number so you could actually put it in and this could be turned to a vulnerability now this would mitigate it in a few ways and it the constant changed so you couldn't represent it as is and what have also happened is they added a few more checks to harden to harden things so we'll talk about how this can be turned into it out this weird state can be turned into a vulnerability and we can and how we can actually exploit it but before that we actually want to talk about something interesting so as I just said the exploit the vulnerability sort of my bad and Loki are found was in native float array so apparently JavaScript arrays don't store floats as native as actual floats they first do something called boxing so they first XOR these values with this constant you can see here so before you put the float into the array this value is being XORed with the flows you're trying to put in so the question that comes up next is whether we can actually have missing values in JavaScript array and if so does the constant change because as we see here we change the way we represent values and therefore we can represent new values so theoretically we should be able theoretically the engine should change the constant otherwise we could potentially get there and actually represent it and it turns out that the constant does not change therefore we can actually represent it by first boxing it so what we did is we first boxed it and XORed the constant with the FFF we've just seen here so that in turn gives us the ability to have the constant as the original constant value why you're wondering because this property of XOR so when you have XOR of three elements and two of them are the same then they cancel out and they give you the first the other one so if we have two of them to be the the if you have two of them to be the this value so and they one of them to be the magic value what happens is we actually get in turn the magic value and therefore we actually can represent it and this is exactly the vulnerability I found which is truly truly have heavily relies on the fact that we have basic understanding of JavaScript engines this boxing is one of the first things we learn when we learn about JavaScript engines so we use this idea of boxing things and turned in supposedly unexploitable state to be a vulnerability so basically what we did is as you can see here we first box it and then we put it into an array that has just that is a JavaScript array and not a float array so how do we turn this one this weird state into a vulnerability so when what what happens first thing we need to understand is how vulnerabilities look like so jit stands for just in time as I already explained jit bugs are usually what we see today are usually type confusions so type confusions are essentially confusion between two types that the the machine the program thinks something is of one type but actually of the other type so jit actually the most common ones are due to side effects now side effects are some things that take place in the jitted code now jitted code I refer to the machine code that is emitted when the jit compiler compiles the hot function so in our case in the usual case I mean what happens is you have some function let's call it foo which changes a type of some some object let's let's think of it as an array and then the function that got jitted doesn't know about this conversion so it thinks that everything's still the same and nothing has changed so it's gonna work with it as if as if as it did before and this leads to a type of vision so let's look at an example so first thing we do when we have such vulnerability is we make the function hot as I explained before to make the function be compiled into machine code we first has to make it hot we do that by calling the function a lot of times and this is this can be done by a simple loop and the next thing okay so also it's important to to say that jit the jit compiler has a lot of assumptions these assumptions are on some types on some things that take place during the execution of the function so for instance when we call foo and it thinks that foo doesn't do anything it it knows that it doesn't need to check things again because if foo doesn't change any state of the program why would we check something again because that would make the function way more slower and jit compilers are all about making things faster so it has a lot of assumptions that are there to improve performance so once we do that and we have something that break the assumption we can we can eventually get to a weird states weird states and from there we can turn this into a vulnerability so in this case once we call the function and we make it be compiled into machine code and we actually call the function again but this time we want to trigger the type confusion so what happens here is foo will change the type of the array and therefore the assumption that foo doesn't change anything breaks that this gives us the ability to to have the jit compiler think that nothing happened but we actually change something this is very important because jit compiler bugs are very complex sometimes and this one is not too complex what happens here we essentially made the made the jit compiler for yet don't to not know about the the conversion that happened so if foo converts array to a javascript array something happened but the jit compiler doesn't know about it so it's very crucial to understand that and the assumption essentially break because we change something in the function that we called so this is basically about jit type confusions we have we essentially have some function to make it hot and then we have another function which gets gets emitted to machine code and in that function we call some other function which will have side effects side effects are things that the jit compiler is not aware of so let's actually move on to my vulnerability so to turn the the mismatch between the flags if you remember we had a flag that indicates it has no missing values and we also had the array content so once we have the mismatch and we actually managed to fake a missing value to turn that into a vulnerability it's quite interesting so the way lucky heart and so my bet did that was basically through calling this function con cat which had an ass hat which relied on has no missing values and also relied on the content of the array this allowed the mismatch to be to to get us into a weird states which shouldn't happen because in normal case why would we have the the missing values and the content of the array to have not met a mismatch between them so in our case and in lucky hearts case they got the array flags tag they got the array flags to be mismatched with the content of the array and they called con cat now the way con cat was called was once we make a fake array let's call it buggy and the buggy has a fake missing value in it but the the flag that indicates if there are any missing values is not set to true so we set this fake array and we call con cat with it now the first thing that happens when we call con cat is we get to this code now this is the part with that where we have a lot of code now bear with me it's not too hard it's just a lot of code so first thing we get is we get to this function this function essentially is called con cat args and a item in this case is the fake array the buggy we have it's called we invoke is filled from prototypes and we would essentially want fill from prototypes return false in order to get into that if statement now it's filled from prototypes essentially checks the following things first thing it checks is that there's only one segment in the array and that check is through the fact that it checks that the next had the next segment of the header had segment is null and the another thing that it checks is that the length of the array is equal to the length of the segment therefore the segment is the only segment in the array so these are the first this is the first thing that it checks and the second thing that it checks is that the flag has no missing values is set to true now this can be easily bypassed because we've already seen that we can fake a missing value and set the flag to true by doing that we can actually get is filled from prototypes to return false and we can actually successfully get and get into the if statement next thing we reach is this else statement which calls copy array elements with our array as an argument as you can see it's the PRM array once we reach copy array elements is essentially copying an internal function and which does the following now this part is very is very interesting for us so first thing that happens is they make an enumerator out of the array a numerator will enumerate every single element in the array and will increase the counter every time it engages in you element now let's see how this enumerator is actually implemented so this is a code for the move next function and as we can see on the red box when we encounter a value that is actually a missing value we actually skip it so what happened here is that every time we we got into the sorry every time we got into the while loop and there was a missing value it skipped it therefore the count that we had there is not equal to the amount of elements in the array this is because every time when we we get we find a missing value it doesn't increase the counter and therefore we can actually get into this if statement and call internal fill from prototypes now this also is very interesting function for us because it basically first thing it does is loop through the prototype chain now if you remember the prototype chain is basically if the prototype is basically some object that we inherit features from so we can have our prototype to have another prototype and therefore we forge a prototype chain so this thing this function first loops through the prototype chain and then what it does it called it calls this long function name with our prototype as an argument so if you remember prototype is actually directly converted into a javascript array when assigning a prototype remember from the conversion slide so essentially what happens here it knows that the prototypes or should know that a prototype is a javascript array and we loop through it so every time we get in here what happens is the prototype is being passed through the object argument and is then converted to a javascript array through the insurance native array so as you can guess insurance very basically ensures the array is not of a native type and therefore it's a javascript array and this is the interesting part for us so what we've seen so far is so to quick recap okay so what we happen so far is we managed to get concat to convert some array into a javascript array and there is nothing that indicates this conversion it's important to know that once we fake an missing value and we call the prototype we call the concat the all of the prototype chain is being converted to javascript array now as we've seen before prototypes in the prototype chain are not native types so we shouldn't be able to put there any type because it should be javascript array so it turns out that we actually can do that so remember proxy proxy can wrap a an existing functionality and redefine its functionality in our case we can and it's pretty fun that we can do that is we can redefine the functionality of get prototype so what this allows us is whenever we call get prototype we redefine a behavior so remember that prototype chain so what we do here is basically redefine this prototype chain loop and by doing so we allow us to return to call an arbitrary function now if we call an arbitrary function of our choice for example in any function what happens is the the jit compiler checks if this function is marked as having side effects or not if the function is marked as having side effects the whole function that got jitted is marked as having side effects and it's not good for us because we don't want the jit compiler to know that some side effect took place because we want to get a tag on fusion so what we do is we use an existing function which is called value of and is marked as not having side effects this basically allows us to return any object in the prototype chain by calling get prototype so let's see an example for that this is the proof of concept code and we'll go through every single part of it and I'll explain everything so first thing we do as I explained before we loop through the top we loop through this first loop to make the function hot and therefore you get it gets compiled to machine code next thing we do is redefine to arrays bug array which is going to be the array we fake a missing value inside of it and an array which is called error and is going to be our target for a type confusion now it's important to notice that the target which will be converted to a JavaScript array is not buggy it's array so notice that next thing we do is we redefine the get prototype off so get prototype off is basically the get prototype function and by doing by calling by redefining it to be value off whenever the function get prototype is called on ARR we redefine the implementation and get it to return the ARR itself this allows us to return ARR whenever get prototype is called this is huge because if we define a proxy what happens is we essentially made the get prototype loop to return us a JavaScript native float array so if you notice on the line before whenever get prototype is called we call value off and if we loop through the prototype chain and value off is the get prototype the return the return value is going to be ARR which is a JavaScript native float array as you can see here this allows us to essentially have a native float array even though there shouldn't be any of those in the prototype chain next thing we do is we redefine we define the missing value constant and by doing so we still have the has no missing values flag for buggy set to true this is the interesting part because this is where the mismatch takes place so we have a missing value but we don't have the flag set to true so next thing we do is we call the jitter function so this is the the key part here so when we call this function what happens is this function is this code is being grand so first thing we do is redefine the temporary and we define the first element of the array object the array array to be a float this makes the jit know that whenever it gives us array and no conversions happened it still thinks it's a JavaScript float array and then we call the temp we call the contact function and we give it the buggy as an argument this will essentially loop through all of the prototype chain and one of the prototype in the prototype chain is the proxy as we can see here and when we call the neck the get prototype for the proxy we get the ARR and when we call the get prototype for the ARR we get we sorry when we get we call the prototype for the buggy we get proxy when we go we call the get prototype for the proxy we invoke the get prototype for ARR which will return us the ARR and therefore what happens is ARR is converted to a JavaScript array whenever the prototype chain loop takes place afterwards in the last line of the jit function we basically write some value into the array and therefore make write a float into some array that was converted to JavaScript a float JavaScript array so array is the same array that is in a prototype chain and therefore we still overwrite we overwrite some pointers with a float which in our case is one two three four so last thing we do is call console log and we crash because we have a object which is defined for this address and it's not mapped so this is essentially the proof of concept code and what we do here is fairly simple we're first thing we do is we make a function hot and by doing so we make it be compiled into machine code next thing we do is we redefine the behavior of the get prototype function and we allow it to return an arbitrary object whenever we call get prototype then we invoke the jit then we fake a missing value and we call the jit jitted function which in turn allows us to convert in all of the prototype chain to be some JavaScript arrays now even though one of most of them are JavaScript arrays one of them the array one is not because we redefined the implementation for get prototype this in terms of out this in turn allows us to have a JavaScript float array converted to a JavaScript array and we can still act with it still operate with it as if it were a JavaScript float array and therefore the last line here allows us to write a point a number as a pointer and therefore we have what we called in the beginning a type confusion so we essentially had a type confusion between a float and a pointer because the jit did not understand that some conversion took place now this is essentially the bug and to exploit it we actually had to do a few things so first thing we did with was we targeted a fake object primitive now what is the fake object primitive this thing we've just seen was that we faked an object at an arbitrary address in our case it was faked in that is one two three four as seen here but the thing is we actually can fake an object at an arbitrary address the object we decided to fake was a data view object which has some fields of it which are a pointer you can read from and write to this in turns gives us a read write primitive and from there what we did was to use a known trick which is to find a stack address and overwrite it to run to execute our code in rope so to do all that we use that a great lever which is called ponjs and we use that we had to fix a few things but it did most of the work what it did was basically do what we explained we it it requires us to have a read write primitive and then what it does is to scan the the program to find a stack pointer from there it overwrites the stack with whatever we want because we got an arbitrary read write primitive and then what happens is we can execute code in rope now we first exploited it on edge but to actually execute our own code what to sorry when we actually execute our own code we had we executed it in the sandbox context so it wasn't any nice for a demo because it would not allow us to pop a calculator or something but so what we did was we actually compiled chakra core for Linux and we exploited it for Linux the exploit for Linux was similar because we still overwrite this overwrote the stack with some things we controlled as we had a read write primitive and from there we basically executed code in rope so that's basically what we did to get a poc a crashing proof of concept to actually execute our own code so let's see a demo for that let's hope it actually works one second second no so let's let's hope everything works so basically this we have a chakra core compiled for Linux and this is how it looks like so to execute it we actually have to give it a source file so in our case we give it an exploit and our exploit so notice this is going to be very fast to exploit because chakra is super fast and it has super optimizations because why not so it's going to be super fast so beware and therefore we have okay we have a shell so to prove them we actually got code execution let's draw rest let's run a calculator oops oops and we have a calculator as well so we actually can actually execute code and everything works as expected so a few things about let's get back to the talk oops wait sorry so what we've seen here sorry what we've seen here was basically we had some code we're okay so the demo shows us a very simple thing we first did what we did in the proof of concept we got the jet compiler to not be to not be to not know that some side effect took place this side effect in our case was some conversion that allowed us to convert summary into a JavaScript array and then in turn allows us to write floats as point as pointers and this basically gave us a top confusion primitive which we exploited by having by faking an object which gives us a read write primitive and therefore we continue to write our code and rock so I really hope that my talk was helpful for so so for those of you who want to get into security research and I hope it was entertaining for those of you who just wanted to hear about the technical stuff and I want to thank everyone who helped me out with the talk and with the slides and for you to come for you for coming here and seeing my talk I know there's a lot of great competition and there's way cool talks probably but you still came to mind so thank you for that and yeah thanks for coming Jonathan do we have some time for questions yeah sure okay was it the first talk you held for such a big audience yeah I never spoke more for more than 10 people for Christ's sake that was good we have a couple of microphones over here so if you have questions for Jonathan please line up over there and shoot the questions we could start with one from the internet do we have one oh okay don't we have any questions over here people are good where's here number five here we go so thank you for the excellent talk I was surprised to see that the JavaScript engine for edge was open source so is this something that the moving towards more open source components I think that the open sourcing is cool but I don't know how actually out of future will will be and if we all open source more things I actually don't know then we continue with microphone number two hey thanks for your very interesting talk so obviously jet compilers are a pretty in-depth subject so my question is when you got started with all of this how much prior domain knowledge of did compilers and dynamic language runtimes that you have and when you then got to chuck the call how much did you have to just read through the whole thing before you could actually start looking for a vulnerability in there so what I did was when I started to look get into chakra I read a lot of by reports and I have seen that there's plenty of vulnerabilities there so I read most not every one of them but I read a lot of them and I try to understand what they do and why they exist and this is basically what got me into looking for my own bug as well so basically I had understanding of JavaScript engines in general and then I read about how chakra works and read about specific vulnerabilities in chakra and over to microphone please you mentioned the process in windows runs in a sandbox so you weren't able to calculator would this stop the exploit in the wild or is there a way this could be dangerous even in the sandbox so to actually execute your arbitrary code you have to escape escape the sandbox there's things you can do with the sandbox but they're pretty limited I didn't exploit I didn't find a sandbox escape yet I hope I will find one day but to actually execute interesting stuff you need to do a sandbox escape because there's plenty of mitigations nowadays and specifically for edge does a lot and I don't know specifically if you could do anything you could do anything interesting without a sandbox escape but you could actually run code so you could do it you could do stuff I'm not sure if it's interesting enough to to to actually do something in the wild and over to microphone number two hey great research and work and how much time did you work on it so I worked on chakra for about I think from July I think I when I started I started reading about chakra in July but I had understand I had some knowledge about JavaScript engines before for about like two two months I think so not enough I mean the more the more important part for me that was to actually read about examples and see examples more than spending a lot of time on it like I think it comes with practice as I explained before what I do believe in is practice and my practice was through reading a lot of research and a lot of internal stuff about chakra so it's about I think from July and maybe two months before all right nobody's queuing up on the microphone so have I overseen someone Jonathan excellent thanks that's it that's your applause that was Jonathan Jay from zero to zero day thank you very much