The First Exploit - Pwn2Own Documentary (Part 2)

We are at Pwn2Own, one of the most prestigious hacking competitions. Eduardo Bojin and Tawan from Palo Alto Networks just demonstrated their zero-day exploit against Firefox on stage, and we are on the way to the disclosure room to hear all the details. And by we, I mean Freddy and decoder from Mozilla, who allowed me to follow them with a camera and document their experience. Mozilla is using Pwn2Own as a security fire drill to practice what happens if a zero-day is discovered in the wild. So let's see what happens in the disclosure room at Pwn2Own. This USB stick was just sold for $50,000. What could be that valuable? It's not a crypto wallet, no stolen data, and no state secrets. Just a few lines of code. Beautiful, but dangerous code. A zero-day exploit. In a back room of a hotel in Berlin, the trade went down. They are the ones who bought it. sold it, and they will make it worthless within hours. This is the story of two Firefox zero-days, the world's most prestigious hacking competition, and what it takes to keep millions of users safe. It's now 11:45, so it has been quite a while since they proved on stage that their exploit worked. They are still in the room with ZDI to confirm the bug. We do wonder why. Are there details missing? Are they not sure if it's a duplicate? Because that's one of the things ZDI looks for. It could be that it's a duplicate, and that's why it takes this long. So let's see how much longer it takes. We had to wait a little longer. Afterwards, we learned that they were missing some requirements to share with ZDI, so it took longer because they needed to fix that. But finally, the door opened and we were allowed in. We settled down. There was a little bit of small talk, but then it went pretty quick. A few things happened in parallel. So right here, Freddy was given a USB stick with the exploit on it. His job is now to share this with the team. Meanwhile, Christian got up and talked to the researchers about their bug. Yes, so it's in the SpiderMonkey JS engine, and it's related to the implementation of the Promise. allSettled function. Okay. So Promise. allSettled takes as an argument an array of promises and returns some object saying if the promises have been rejected or fulfilled, right? And it's basically possible to create a custom promise for which we define a custom resolve and custom reject function, and it's possible to change the result array before the Promise. allSettled has actually been returned. Yeah, resolved. And so the vulnerability is actually out of bounds, right? And it happens because for each time we call the fulfill or the reject function, it will get the index related to the promise argument that we are processing, and this index is stored inside the reject or fulfill, but it's mutable. Yes, yes. So what we do is actually we shift the array after we shift the array. So we can, after that, get some OOB first OOB read, and from the OOB read we can bypass. OOB reads, yeah. And it's basically based on the check that checks if the value is undefined. Then we can bypass that check and perform an out-of-bounds write. Okay. While they were talking, maybe you noticed that Freddy attached the proof-of-concept file to the Bugzilla ticket and shared the link with the team. Freddy then also tries to run the exploit in a VM because they need to confirm that it's real. And then Christian also tried to bisect it, which means he's running it against the last six months of Firefox builds, hoping to identify when the issue got introduced. We can't actually bisect this bug. Bug is too old. Bug is too old? They were able to reproduce the issue, and it turns out the issue is older. It's probably older.

Can we do preserved builds for six months? Six months. We're not aware of the fix. A JS developer confirmed. Our principal engineer in the JavaScript team explicitly says, you can thank them for providing an excellent PoC and write-up. It reproduced immediately in my local debug JS. So thank you so much. So the issue is confirmed to be unknown. That's a relief for the researchers and just the beginning for Mozilla to get this issue fixed, but that's mostly the responsibility of the engineers offsite. So Freddy and Christian can maybe relax a little bit and use this opportunity to ask the researchers a few more questions. We spent actually a lot of time on the stability because on Windows it involves a lot of GC stuff. So on Windows we had some troubles to make it work every time in the exploitation part. So basically that's our first time we also took a look at Firefox. We never touched Firefox before four weeks ago. So we spent actually a lot of time in the exploitation part because we didn't know anything, and we spent a lot of time alongside. So it's very different, but it's very interesting to see how things are different from one engine to another, and I think Firefox is very good. The implementation, the way we spent a lot of time trying to find a bug. And somehow there are some areas where it's much more difficult to swap types than things. Oh yeah. JIT types specific. Yeah, JIT. And for the JIT we try to fix type confusions holistically. Yeah. Also the object types. Yeah, because in Chrome they have this kind of mutable map, which is not the same for shapes in Firefox. So it makes the type confusion easier in Chrome. And well, that was it. This was the mysterious Pwn2Own disclosure room. Honestly, I don't know what I expected. Obviously it's just the room where some people talk about the next exploit and confirm it. No magic. But anyway, after a few more minutes, we packed our things and decided to head to the Mozilla office. We're in the taxi now, and we are going to the Mozilla office. Our team already has a copy of the sample. They are trying to take a look. It already reproduces in debug builds, which is really useful. We also know that it triggers in debug builds and is not exploitable in debug builds because there's a debug assertion. So that's first of all really powerful for testing and secondly really giving us an indication of what we believe could be wrong in a release build, and maybe it's an assertion we could just enable in release. So that's promising. I'm really looking forward. At the office, I finally had time to look at the files that the researchers shared, especially their write-up. Mozilla Firefox SpiderMonkey out-of-bounds write remote code execution vulnerability. But Freddy and decoder had other tasks to take care of. I'm managing the incident process. So that basically means filling out the document timelines, who's doing what, making sure that everyone is involved. Mozilla uses Pwn2Own to practice emergencies, a fire drill for an in-the-wild zero-day vulnerability in Firefox. So they treat it like a real incident, which you can see here. Freddy takes on the role as the incident manager. You said you're incident manager, right? I'm incident manager, yes. So that's kind of like the overall coordination for the process. By the way, these internal processes and documents around such an incident are very confidential data. So this is a really transparent insight into how a corporation like Mozilla manages incidents. I'm very grateful that I'm able to show this, and I hope other companies can take inspiration from this. So thank you so much, Mozilla. While we were sitting in this room, we also started a conference call where people could join. I'm getting the kids ready for school. And while it was currently early afternoon in Germany, in the US the day was just starting. Knows that Pwn2Own is happening. I just gave them a heads up that ESR will be affected, so they should plan desktop builds. Yep, excellent. What is ESR? ESR is our extended support release. That's the version that only updates every half year, I believe.

And Tom specifically mentioned that he informed the Tor Browser people. Thomas works for the Tor Browser, and they are also affected, but they use the ESR. decoder is trying to help Jan with bisection. So he's trying to identify when this bug was introduced and what was the oldest version where the exploit still works, but that turned out to be not so simple. So I'm trying to build the JS engine right now. It's funny that I first had to install Python 2. 7 in order to be able to even run the configure script. But I believe there's still some errors in the build process that I will look at. And I actually managed to build the JavaScript shell from six years ago and reproduce it on the earliest build that we have where this API was actually added. After they resolved all these issues, there was not too much that we could do anymore. Jan, being the engineer, was working on the patch, and we spent some time looking at the exploit. We were theorizing over why fuzzers didn't find this issue earlier and what could be improved in fuzzing to find similar issues like that in the future. And for example, we were also trying to make sense of the exploit itself. For example, what the shellcode inside the WASM code really does. Because there was not much going on anymore, I was also asked by the Mozilla social media team to record some stuff for their Instagram. It was fun. I'm always curious how that regular influencer and marketing stuff works, but I cannot watch the result. They sent me the video for review, but I'm just cringing too much at myself that I didn't watch it. When I can create a script for a video like this here, I'm totally fine. But when I have to improvise and just speak afterwards, my brain will be stuck on thoughts like why did I say this or why didn't I say that. Anyway, you can find the link below and maybe tell me how bad it was. After a while, we got an update from Jan. I have a patch that fixes the proof of concept in JS shell, but still looking through similar code elsewhere. We have a prototype patch that may help fix the vulnerability. We don't have full confidence that it fixes all of the reasonably existing variants of the vulnerability. So currently we're trying to look at the code, seeing if there are other issues in other promise functions to make sure that we can definitely ship out a patch that doesn't put any kind of pointers or add any additional exposure to other parts of the codebase that may be similarly affected. As you can imagine, we were basically just sitting around. Now there is theoretically a fix, but you need to keep in mind that you cannot push this out immediately. First of all, Mozilla Firefox is open source. So once the patch lands, it basically becomes public. Also, they are not sure if there are variants of this issue. We want to make sure we have confidence in the variants. Exactly. Often times our code is open source. Often times people look at the commits, and especially if there's just one commit going into a new release, people know it's usually a security bug and they try to find variants or adjust their fuzzers, just as we adjust our fuzzers when we find new bugs. And so in this case it would be important to get the fixes for the variants out as well rather than just emergency. Yes, that's definitely the desire. And this is where the real in-the-wild zero-day maybe differs from the one at Pwn2Own. A real zero-day is already confirmed and known publicly. Well, this Pwn2Own bug is still private. So you have to do some risk assessment. On one side, you want the fire drill to be as realistic as possible, but on the other side, you don't want to actually introduce new risks or break Firefox just for a test. Also keep in mind, tomorrow is day two of Pwn2Own, where maybe there's a second exploit requiring a patch as well. And so they decided to take the time and check for variants and wait for the other exploit tomorrow. Once they have that, they can go through the entire release pipeline with QA and do everything else that is necessary. So there was not much to do anymore. The time just passed, and Freddy eventually handed off being the incident manager to Diana Smith, who is a senior release manager, and she is in a different time zone so she can take care of it over the night. And yeah, I went home, and I was ready for the next day of Pwn2Own where Manfred Paul is up to hack Firefox. Will he be successful? If you don't want to miss part three, subscribe on YouTube and follow me on Twitter or Instagram. If you're interested to learn more about hacking, check out also our online courses on hextree. io. We primarily have Android, web, and some hardware hacking videos right now. But if you're just interested in my free YouTube courses, you still should head over to hextree. io because we put all my YouTube videos into a huge map as well. Here you can explore all my backlog of hundreds of videos in a more organized way and explore all the different topics that you might find interesting.