one of the craziest exploits i've ever seen

did you know you could get hacked by a picture yeah if I served this malicious picture here to you and it rendered in your browser there was a long period of time where it would be able to crash your browser or even give me remote code execution on your browser and this bug was actually being used by the NSO group to remotely exploit iPhones with a zero click exploit that took advantage of a bug in the lib webp library now this bug is so crazy and I haven't made a video about it so I wanted to talk to you guys about it today it is literally one of the most most insane bugs that I've ever seen from a couple perspectives and we'll talk about those in this video also hi my name is l learning I make videos about programming and software security and cyber security so if you like those things or you want to just hang out with me hit that sub button I really appreciate it when you open a picture what happens the picture has to be interpreted by some piece of code to render it onto your screen at the end of the day a picture is just a binary file format that will render an image to the screen the binary file format contains things like the data of the picture that are compressed into different blobs things about the encoding of that color maybe metadata about the picture itself or comments in that picture as well as a number of other things you can actually go look at the JPEG and the PNG format and go read about all the different features that those specs have and for every spec there is there has to be a piece of software that parses it and just like any piece of software that software can have software vulnerabilities now the lib webp library is meant to parse the webp file format a newer format for images and video that allow you to encode more data effectively into a better compressed format and just like anything else code that is new typically has vulnerabilities that haven't been found yet now an interesting feature of the webp format and ultimately the source of the bug is the ability to do lossless compression the idea being you have a bunch of data that's really really large and you're able to compress it down to a smaller size now in a lot of file formats there is lossy compression where the compression of that data results in the loss of information you're able to remove information to make your file format smaller but you can't expand that data back to what it used to be there is loss in your information by using an algorithm called Huffman coding the lib webp format is able to do lossless compression on information stored in the image now the way it does this is via a very complex algorithm that I'm not going to spend a lot of time talking about in this video what Huff encoding allows you to do is store the statistical likelihood of a particular data value to occur and assigning a code to it by doing this you're able ble to inform the decompressor of what codes mean what thing and allow you to store more information into a compressed file format for example in this example hu and coding here we have the character space who appears seven times in the in the data so we assign this code to it here it means every time you see the bit sequence 111 or seven you replace that with the 8bit value of space which is hex2 by doing this you're able to save a lot of room in your file file format now the problem with this is that if we included all of the statistical information about the image in one tree that in and of itself would be very big and in order to do that in a way that is lossless would contain a lot of size there' be a lot of room required to store that tree inside the image so the web live webp format recursively takes the tree and then compresses that down via Huffman encoding and does that a couple of times over and over again to a point where you have it as small as you can get it to recreate the think about like Marista dolls uh those you know those trees and produce the image as the way that it was found before it got compressed now the issue with this the reason that there's a bug here is that when you build a Huffman table there is no length check on the buffer size where you're storing the table so effectively if you're able to create the right Huffman encoding table that once it recursively unpacks itself to the correct size using the correct tree values and again this is not a simple algorithm if you're able to do this you're able to create a buffer overflow in the BSS of the lib webp library now this buffer overflow eventually leads to a double free which is a very common Heap exploitation technique that allows a user to take over the status of the Heap and use that to enable remote code execution now you're probably wondering how did we miss this bug like what went so wrong that no one saw this bug in public like we have plenty of projects that are doing open source software analysis the biggest one that's most well known is Google's OSS fuzz it's open source software fuzzing if you're not familiar with what fuzzing is fuzz testing is basically this way of taking software and essentially screaming at it and just making sure that when it fails it fails gracefully if you hand it data that is not meant to process it handles the error values in a way that does not expose the user to remote code execution via either memory corruption or some kind of logic error and there are literally hundreds of projects that are integrated into open source fuzz where effectively you produce a project you put it into OSS fuzz and then on the cloud it is consistantly fuzzing throwing bad data at it and it will inform the developer if it finds a issue in your code now what makes this bug so insane is the amount of things that have to go right to get the exploit to work and the amount of things that have to go wrong for this bug to have been caught in OSS fuzz and I think why it was able to remain unseen for so long and if you go back to the story of how this bug got caught it only got caught because there was a lab that detected suspicious behavior on the iPhone of an individual employed by a Washington DC based Civil Society organization basically the NSO group was doing political Espionage and a uh threat research organization saw their iPhone being exploited but if it hadn't been caught in the wild kind of like the XZ bug this bug could have just sat in code for a long time now how did we not catch it in osss fuzz well the reason is that it's such a difficult bug to reproduce it's almost impossible to produce a Huffman en coding table that when it's unpacked over and over and over again to the top level it overflows this table and you'll even see in Ben Hawk's write up of how they went through and did the technical triage of this bug they recognized that there was an issue they saw that there was no bounce check on the buffer that they put the Huffman table into but how do you create a Huffman and coding table in an image in a way that allows you to effectively recursively unpack to get the to get the buffer overflow condition to happen and so he and his team had some really cool visualization tools here one of them being it's they're showing the huff and en coding table and B basically they're trying to visualize how can they make the Huffman en coding table as large as possible by expanding out this graph structure uh and how can they use that to Leverage The buffer overflow and the reason this bug got missed for so long is because of how hard it is to create a Huffman and coding table that enables a buffer overflow researcher Misty mint cop I guess uh wrote this piece of code here called craft. C that allows us to create an image that is able to exploit the buffer overflow rate if you look at the amount of code here required to do the math to actually produce a Huffman en coding table that violates this constraint it's non-trivial like there is a significant amount of code I'm only halfway through it right now to produce a Huffman encoding table that when recursively unpacked creates the xplay condition so you can see here at the very very end they show how if they make this the table here the ultimate un impact size is 414 and 526 which is bigger than the uh size of the array which is pretty interesting so what are we left with a simple one pixel by one pixel image that has no actual image data but contains a Huffman encoding table that when expanded enables a buffer overflow that later could be used to create a double free and eventually take over your computer absolutely insane of a bug I have not been able to stop thinking about it since it happened now this bug is from September last year it has been patched so likely if you're updating your browsers like you should be you have a new new version of Chrome new version of Firefox you are not vulnerable to this but it begs an interesting question about libraries that sit dormant in certain projects I know from personal research that there are projects still on the internet right now maybe image converter libraries for example I want to convert this webp to a PNG that haven't been touched in a long time and are still using the vulnerable version of lib webp from a couple months ago anyway that's it for now I hope you found this bug as in as I did and I hope that you're able to stop thinking about it because I personally can't if you like this video do me a favor hit the sub button and then go watch this next video that I think you'll like as well thanks

Channel: Low Level Learning

Views: 367,364

Keywords: raspberry pi, pico, rpi, microcontroller, arduino, maker, craft, hobby, electronics, wires, temperature, safety, project, board, electric, leds, led, thonny, python, micropython, os, ide, onewire, ds18b20, circuitpython, review, launch, measure, probe, rp2040, specs, specifications, how to, guide, programming, Pico emulation, retro games raspberry pi pico, etaprime, eta prime, raspberry pi pico, arm cortex m0+, low cost

Id: 89ysXVYH2Sk

Length: 8min 40sec (520 seconds)

Published: Tue May 07 2024