# My theory on how the webp 0day was discovered (BLASTPASS)

## Метаданные

- **Канал:** LiveOverflow
- **YouTube:** https://www.youtube.com/watch?v=_ACCK0AUQ8Q
- **Источник:** https://ekstraktznaniy.ru/video/23412

## Транскрипт

### Segment 1 (00:00 - 05:00) []

(whoosh) it has been a while since we spoke about the webp vulnerability that I titled “a vulnerability to hack the world”. And I am Sorry about that. The past few months I decided to prioritize Hextree and I ended up not making videos for 6 months. BUT that doesn't mean I didn’t make videos. I made at least over 100 shorter videos for the Hextree courses, mainly the Android application security courses which are sponsored by Google. So if you missed me, check them out. I think they are great. But let’s come back to one of the promises I haven’t yet delivered on. Remember the webp vulnerability? “The exploit involved PassKit attachments containing malicious images sent from an attacker iMessage account to the victim. ” Well after two videos looking into it, I was left with one huge question: If fuzzing couldn’t find it. And we only found it with persistent fuzzing because we knew where to look… how did they discover this vulnerability in the first place? I actually have a theory and I will tell you about it next video. Oof even my glasses changed since then. But now is the time. Let’s talk about this and hear my theory on how this was discovered. <intro> Alright, let’s start from the beginning and build up to my discovery theory. To do that, let’s put ourselves in the position of a vulnerability researcher, or rather a whole team that wants to remotely hack iPhones. Now admittedly I have absolutely zero personal experience in that area. But I have talked to many vulnerability researchers over the years and so I have some ideas how that could work. Our goal is to attack an iPhone remotely. Which means in the end we need to exploit some software on the phone, so we have to think about all the different data inputs that exist between a random person, the attacker, and the victim’s phone. And that basically only leaves us with various communication channels. You can call a stranger with their phone number, you can send an email to a stranger if you know their address. And you can write SMS, MMS or more complex messages through various messengers such as WhatsApp, Signal or the default iMessage. So as a remote outside attacker, we need to look into those programs. And especially iMessage is of course a good target. Because it exists on every phone. There is also a perfect article by natalie silvanovich from google project zero analysing exactly that. “The Fully Remote Attack Surface of the iPhone”. Talking about SMS and email and so forth. But of course iMessage is a huge complexity target: “We then decided to look for bugs in the initWithCoder: methods of the classes that are allowed to be deserialized by SpringBoard when generating a message preview. ” Long story short. It makes perfect sense that a team interested in hacking iPhones remotely will research iMessage very deeply. You can see that for example in another excellent google project zero article about remote iOS exploitation: “In order to deliver an exploit over iMessage, one needs to be able to send custom iMessages to the target. This requires interacting with Apple’s servers and dealing with iMessage’s end2end encryption. An easy way to do this, which was used for this research, is to reuse the existing code by hooking into the iMessage handling code inside imagent with a tool like frida. ” This sentence highlights something important. This kind of research takes a huge amount of effort. Not only creatively, but also on an engineering level. You need to develop custom tooling just to be able to start looking for vulnerabilities. Which increases the economical risks a lot because you don’t know whether all this work will pay off with a vulnerability at the end. That’s one reason why these exploits are so expensive. But alright. We gonna start target iMessage. But what area are we targeting. Well, this requires more tooling and research. Here for example in this footage, courtesy of Dr. jiska, we can see a small script that hooks into the iOS Grand Central Dispatch, which is basically an asynchronous thread queue used extensively within iOS apps. And it gives you visibility, including a backtrace, about what kind of functions are getting called. And so for example when in iMessage you receive an image file. Then you see a lot of activity. And we can see references to Image I/O, which is basically THE library in iOS to parse image file formats. Now weather this particular backtrace is about our image getting parsed, or maybe just some other UI elements being handled here, we don’t know yet. Point is. You dig deeper and deeper to understand the target app. As attackers we usually always look for complexity. Because the more code there is, the more bugs there will be. And more complicated code, probably also increases the risk of mistakes. And sending an image, or another file that gets previewed in the chat, is exactly that kind of complexity. For most people sending an image doesn't feel complex. But in reality image file formats are no joke. There is lots of science like math going into the algorithms for compressions. And these algorithms then have to be implemented efficiently. So file format parsing is always a worthwhile target. And obviously

### Segment 2 (05:00 - 10:00) [5:00]

it’s not just one image format. An app like iMessage wants to support lots of formats. And so apple’s Image I/O for example supports GIF, PNG, weird stuff I never heard about. And webp. BUT… apple has done something cool in iOS 14. After accepting the huge risks of this exploit vector, apple introduced blastdoor. Blastdoor is a heavily sandboxed security service process that actually performs the parsing. In Google Project zero’s “a look at iMessage in iOS 14” they made this graphics to showcase roughly how an incoming iMessage is processed. So your phone receives a push message. The IM agent (instant messaging) forwards the payload to the blastdoor process. The blastdoor service then parses the text and XML and deserializes some stuff. And if the message also contains some images or other data, it will be sent using the IMTranscoderAgent to blastdoor as well, to perform the deserialization and create the message preview of maybe some images. This is complex, but the idea is good, if there is an exploit in an image format or some other message deserialization, and the blastdoor service process get exploited. Then there is a heavy sandbox that an attacker hopefully cannot escape from. If you take an iOS system ipsw image. Mount the system partition and you look for files named blastdoor, you can also find this sandbox policy file. Here you can see for example restrictive rules to only allow file reading of specific paths. And heavily restrict file writing as well. That’s just one way the sandbox works. So this is the sandbox policy for the MessageBlastDoorService, which we can also find. This is the binary of that service and with otool -l we can look at the dynamically linked libraries used by this service. And there you can also find Image I/O. So I guess the image parsing of webp files within blastdoor is also done with Image I/O. Long story short, image file formats are a good target. You now can look at what Image I/O is using to parse different file formats. And start looking for vulnerabilities there. Which of course is also not a new idea, there is another Google Project Zero article about that, “Fuzzing ImageIO” by saelo. “This blog post discusses an old type of issue, vulnerabilities in image format parsers, but in a new(er) context: [... ] popular messenger apps. This research was focused on [... ] the image parsing API provided by [... ] ImageIO. Multiple vulnerabilities in image parsing code were found, reported to Apple or the respective open source image library maintainers, and subsequently fixed. ” You can see this is a very common area for security research. Image formats are also a great playground for fuzzers. and yet. The webp vulnerability was not found before. But to be fair, webp is in fact a rather new addition to image I/O as well, it came with iOS 14 in 2020. But it’s also not coming out of nowhere. Image I/O is also just using the actual library libwepp. So there is a good chance that vulnerability researchers knew this vulnerability long before iOS started to integrate the webp library. Maybe they even used it already in the wild against other targets and just adapted it for iOS when it was added. But there has been no reports about that. It’s just a possibility. Alright. We want to hack iPhones remotely, we think targeting iMessage is giving us a large attack surface, and we know that image formats are a typical source of issues. And this is again is nothing new. This is almost like how the standard iOS exploit looks like. And you can see that when looking at other known exploits. For example the incredible FORCEDENTRY exploit, that one was based on the image format JBIG2. So I think it makes sense that there are people, maybe even teams, that are very knowledgeable about the inner workings of various image parsers. And I think that is not just a theory. The FORCEDENTRY exploit using JBIG2 images was attributed to NSO. NSO was also attributed to PWNYOURHOME “the phone downloaded PNG images from iMessage. Processing these images caused crashes in the MessagesBlastDoorService process”. And NSO is also attributed to BLASTPASS, the webp vulnerability. I don’t know how certain those attributions are. They could be wrong, could be a different company or them just buying the exploits. But eitherway. You can see that image parsing is a pattern in these advanced exploits. And so they must be experts on this. People who have spend thousands of hours with their head in image parsing code. And now we slowly get to my ultimate theory. So when I looked again at the FORCEDENTRY writeup from google project zero, I noticed something familiar “decoding a huffman table”. And the vulnerability appears to be related to counting number of symbols, which reminded me a lot of the huffman table symbol stuff we have seen in the webp vulnerability. And that made it click for me. huffman tables are a common occurrence in image file formats. The huffman table algorithm implemented in webp had the vulnerability. Don’t people just copy these kind of generic

### Segment 3 (10:00 - 14:00) [10:00]

algorithms from another? This must exist in similar form in other image formats as well. So I started looking. And here for example on the left, I found a jpeg XL library (jxl) implementing the huffman table decoding, which looks basically the same like the libwebp implementation. There is a count array, it’s looping over it, decrementing the count. And then it’s moving a table pointer forward. I mean it’s a huffman table implementation. Of course they look the same. And so is that one vulnerable as well? Well I tried to fuzz it and didn’t crash. There is some table resizing going on as well. But to be honest. I lack the skill. Maybe there is a zero day here or not. Maybe somebody else can check. But still. This is intriguing. And so I thought there must be more. The mistake webp made was trusting the output from the tool enough. c to calculate the maximum possible table size. From the webp source code above the hardcoded table sizes, the comment says: “All values computed for 8-bit first level lookup with Mark Adler's tool, enough. c”. And so are there other image formats, or compression tools, that trust this output? I went to the GitHub search and started to look for C code where that tool shows up in comments. And look here. Here for example is the zlib implementation talking about the table size calculations. Which makes sense because that is where the enough. c tool is from. But I kept looking around, and I found brunsli. A practical JPEG repacker by Google. And in the jpeg_huffman_decode header file I found the following. Maximum huffman lookup table size. Hardcoded to 1024. Referencing enough. c. BUT… “Enough. c works with an assumption that Huffman code is “complete”. Input JPEG files might have this assumption broken. It is assumed that the sub-table of each “size” might be almost completely be filled with repetitions. ” “Input JPEGS might have this assumption broken”. To me it sounds like the author of this comment KNEW that enough. c calculates only table sizes for correct tables. But input JPEGs, so maliciously supplied JPEG files might be malformed. And if we look at the git blame of this file, we can see that three years ago this changed comments was added. And if we go back to before that, this huffman lut size was smaller. And did not contain this warning. And I think that’s curious! Unfortunately the commit that apparently patched this was just labeled “Fix MSVC compilation warnings”. And it contains lots of different changes. So it’s kinda a weird commit. And it’s not clearly tied to some kind of security fix. But I could imagine that an internal fuzzer or just a developer during testing, figured this out. Leading to this code change and this comment. And now imagine you are a vulnerability researcher who is looking at all these different file formats for a long time. You have setup fuzzers, you audited code by hand. You wrote your own parsers to understand the file formats. This is just your niche you are working in. You are always looking into implementations of new image parsers. Looking for new code, new bugs. It’s just a theory. But I can see how a vulnerability researcher focusing on image formats came across this comment and in a very similar way how it clicked for me, it could have clicked for them. “Input JPEGs might have this assumption broken”... you cannot trust enough. c for this. And then you remember this other image format, webp, that also mentioned the table size calculated with enough. c… mhh… Well, if you then setup a fuzzer like we have done in the previous episode, specifically only fuzzing the webp huffman table implementation. Then you would immediately find this crash. And yes, It’s just a theory, but to me it’s a satisfying theory. I can now say, yes I see a realistic path to discovery, without it being crazy black magic. And well, tell me what do you think? Comment below. Or do you have another theory? Also if you happened to be the researcher who found this vulnerability in the first place. Please leak the real discovery method to me. Anyway… thanks for watching. See you soon. If you want to learn more about hacking, checkout our courses over at hextree. io. We just recently published an entire Android application security course sponsored by Google. Google wants more bug hunters to look at their Android app bug bounty. Google has hundreds of apps in scope. And so these courses should teach you everything you need to know to get started finding real bugs. So head over to hextree. io and maybe start your Android app hacking career.