I feel like this is a classic moment of the developers not following the golden rule called “never trust user input” because it really is just someone putting impossible values into it and it just doing what it was told without any checking if it was valid or not
Silver rule: Never trust C code. Firefox has a sandbox mechanism where it compiles libraries to wasm and then back to C, but I guess they hadn't gotten around to doing that for libwebp yet.
My thoughts exactly. I consider it common knowledge, at least to anyone worthy calling themselves professionals, that any externally provided data to any system should be checked and sanitized. There just exists no excuse for omitting that. Even less for a prolific image compression library like this one. If this vulnerability really turns out to be about completely missing sanitation of the compressed image data, then it begs the question how/why this code was ever accepted to run practically everywhere (at least on the internet). If Google is the producer of this library, they should be deeply ashamed. Potentially even be held liable, by such a blatant transgression of a fundamental software engineering rule. While the bug itself might be interesting from a technical perspective, and illustrative of how dangerous unguarded edge conditions can be, omission of input sanitation is far from that. That is just unbelievably stupid, if not outright culpable negligence. I hardly can believe that a company like Google would produce code like that, especially not for a library that is used almost anywhere were modern image formats are processed. I am still hoping I'm just getting this all wrong. I'll happily retract all I just wrote and put an official apology up here instead (if I got it all wrong). However, if it does turn out that this library did not do any input sanitation of the compressed image data, then the producers of this library (I presume the fine folks at Google) have some serious explaining to do!
Huffman coding is great! It's being replaced by arithmetic coding and asymmetrical number systems for entropy coding gains in newer codecs, but with diminishing returns :)
Excellent video. Every other resource on this topic glosses over the details but this one dives right in. This series will be invaluable for new security researchers.
"Why you should study computer science, pay attention to your data structure and algorithm classes". This dialogue made me revisit the CSLR Intro to algo book after a long time 😂
Amazing! Rally like the format, the how to get the basic knowledge for the problem, finding the keywords and also the explanation of the thought process.
I found myself that I like hacking and cyber security in general and in some days I ask my self: *)- "how the photo or image are transmitted and we see it in the phone or computer... or even how it is captured from the beginning"? And today I found this awesome video with awesome vulnerability with awesome channel. Thank you so much
Fun fact: if you also know about things like b-trees (binary trees that have multiple entries on a given level) the same reasoning applies to why huffman tables are used... cache locality!
If this vulnerability could have been found by a fuzzer, then why did no one bother to check? And if it cannot, why? What makes this vulnerability elusive to fuzzing? I hope to see an answer to this in part 2!
I recommend reading "Advanced Fuzzing Unmasks Elusive Vulnerabilities" post by Marc Heuse of Security Research Labs. It goes in depth about the possibility of finding vulnerabilities with advanced fuzzing techniques and whether those techniques could've surfaced this specific vulnerability in libwebp earlier.
The fuzzer would eventually enter the correct inputs to trigger this, but it might take forever! In theory no exploit is elusive to a fuzzer if it can be triggered by a user, but we don't have infinite time or computing power
If someone was asked to read through the code and check for buffer vulnerabilities I bet they would have found it within a few hours. Obviously nobody performed a security audit on the code (or they were incompetent). This might be a good application for an AI.
@@hung8969 It’s probably too complex of a chain to easily fuzz start to finish. You might as well put the effort into fuzzing the webp library directly.
Brilliant video! So well explained and what a curious topic. Shame you didn't take the opportunity to say "impossibilitree" though, that would have been good!!
im interested in the upcoming videos because this seems like an incredibly niche bug to find without deliberately looking for it, unlike many other bugs Super cool video!
@LiveOverflow Could you make a video about the security risks of C if programmers don't know all the intricacies of it? What comes to mind is the recent Project64 Emulator exploit and stuff like scanf for example. It would be really interesting in my opionion as there are a lot of pitfalls when it comes to C programming
Even simple task like counting battery percentage accurately isn't easy. Coulomb counting, kalman filter, exponential fitting, and least square algorithm are mixed well into one .c file, crazy! If you think that's hard, compression algorithm is a lot more crazier than that
I have a question about road map in Malverne analysis and learn exploitation I feel free with books can you introduce me some books for learned this field I want to know I continued true or false in this way
I don't know if i'm the only one but on my android tablet I cannot choose the quality of the video it is marked as unavailable in the options ... wtf and it choose a crappy one....
Some malware, spy app and virus is difficult to remove even after factory reset phone they came automatically don't know how I am in problem please help me . Not possible to change phone hard-disk
My brain hurts now after watching this video? I think, I see why this very problem...with that said though. I bearly understand any of that.😭😑 I didn't want to that job to begin with, and lucky don't because that seems like a not so fun time for me.😕 I don't even see the point of learning this.😅
good question ;) and it's almost philosophical. The image is not turned into a nonsensical array. There exists no image yet. If you see an image, it means that the bits and bytes were already interpreted and rendered! The vulnerability (and the nonsensical array) happen during the interpretation of the invalid bits and bytes.
The image doesn't need to have been created with the official WebP library, that will always generate valid results. One could write their own code to create an invalid image: a file that purports to be WebP but that doesn't follow the specification or doesn't match expectations in some way. Or they could open a valid image in a hex editor to directly edit its bytes, changing it to be invalid.
You can manually craft a file consisting of carefully picked bits that cause the decompression algorithm to generate an invalid huffman table. Then name the file with webp file type and send it to someone.
@@alonzy989 Talpiot Program is an offshoot of 8200 for the most successful red-teamers lol, it’s a promotion for them. 8200 operatives do not vilify Talpiot operations, they aspire to be recruited to them.
i beg you! please make a video on CHACHA20! ive been leanring about it for 3 months and still struggle to fully understand the 4x4..... its killing me lol
Olá, tenho um desafio pra você, tem como mudar o nome do Chipset de uma placa mãe, ou fazer com que o ryzen master não verifique a compatibilidade dela e abrir normalmente? 😂😳👉👈👍
Very interesting video, but i don't undestand one thing: how was this CVE exploited to gain root? Whether the malicious image was sent in whatsapp or iMessage or somewhere else, these apps are sandboxed just like any other IOS app - or are they not? The same applies to andoid, if you send the crafted image and it is parsed by an app, fair enough the attacker can get control of the app process, but i don't really understand how you can get root from that without other exploits to escape sandbox. So it should be either the target app runs as root or the sandbox implementation is flawed, and i can't find any info on what was the case.
Simple answer, there were other exploits to escape ;) To remotely hack a phone you have to chain multiple security vulnerabilities to exploit each step. That's why they are so rare and special.
they call it the Huffman's algorithm becoz the guy who came up with the algorithm was definitely huffing glue when he came up with this method to compress stuff !!!!
This vulnerability sounds so obvious in hindsight. It's parsing the image assuming that a correct program generated it. There must be some checks for it but clearly not enough.
There is a simple and common way to avoid this kind of problem. Any time a pointer is passed for data to be written to, always pass the maximum number of bytes that can be written and the function never writes more than that (or pass a buffer end pointer, same basic effect). Not doing that shows a serious lack of discipline on the part of the programmer(s).
Ah! I've spotted an incorrect thing in your videos, finally! 😋 At 7:08 you say that color values range from 0 - 255 and that a table would thus always have 255 entries. But 0 - 255 are 256 values :O
It's interesting to note how much money was spent to roll out this update to final platforms and how it correlates with the funds that need to be invested to create a more secure version of the app.
PNG doesn't actually compress each color independently; the color-independence comes into play on the filtering level. The lossless compression step in PNG is a single giant Deflate (i.e. zip) stream.
Maybe the exploits discussed in the 37C3 talk "Operation Triangulation" could be interesting for video? They went over a lot of stuff in that talk that you could probably break down and explain pretty well
What you're saying is HERESY... "abandoning" the format is simply impossible (the cat is already out of the bag), so any security hole must be fixed ASAP. If you still think that "abandoning" the format is possible, go convince a few million people to up and take down every last .WEBP file out there!!!
The stages involved in resolving issues related to CVE-2023-4863 include identification of the vulnerability, vendor acknowledgment, patch release, and updating affected products.
Heya, I've got a question that might be related to your past videos, but I thought it's better to ask it in your recent video. In a read world scenario, suppose I successfully manage to perform some sort of attack, let's say exploit UAF or some shellcode injection, and I get a remote shell. What can I do with this shell? In every CTF all I have to do is cat the flag file. But what can I do with a shell in a real world scenario? Could you give me some thoughts about it? Thanks!
I started following your channel when I was in university and remembered being amazed by technical depth of your videos. Few years later, I am happy that I am able to follow along! Thanks a lot for making this series.
This dude, instead of jump right into explaining the vulnerability and how it works he just goes on to ramble for the first 2 minutes. Anybody know his credentials? Listen dude people don't like spending time on youtube watching videos, how about you make all this more concise next time?
While I am normally a rust shill, keep in mind _why_ this complex allocation was done: cache locality. You could not reasonably do this in rust. I would personally prefer safety over speed though, so I'd still say rust would be a good option if this was my personal project.
This specific problem is not something Rust would nor could have prevented-this is a programmer error by not validating the source input (i.e. file). The buffer could be overflowed by crafting an image file that caused the Huffman table construction to exceed the pre-calculated buffer size. So it would've been outside any compiler's knowledge. What could potentially have caught it would have been using advanced fuzzing techniques. However, fuzzing is not a silver bullet, and this vulnerability was not caught by Google's OSS-Fuzz project. It's possible that fuzzing alone wouldn't have been enough to catch this vulnerability at all.
@@dealloc > so it would've been outside of any compiler's knowledge In other words, the compiler would insert a bounds check here and prevent the bug...
@@MrFram The vulnerability was introduced when applying a common optimization used in Huffman decoders; The decoder was optimized by pre-reading N bits to determine how many to consume and which symbol to decode. Longer symbols previously required graph traversal but were improved using an array of lookup tables. The new tables store (nbits, value) pairs; if nbits exceeds N, it's a table index, enabling efficient decoding. However, a bug emerged during table construction, risking overflow due to unanticipated table sizes. Rust's safety mechanisms might not have caught this because while it's unsuitable for unsafe code in table construction, the lookup phase often requires unsafe operations for performance. Even tools like "enough" in zlib, as explained in this video, predict table sizes under specific constraints, but when those constraints aren't met, Rust's safety wouldn't prevent a wrong table construction, potentially leading to security issues.
@@dealloc stop using chatgpt and actually think about what you just wrote. > it's unsuitable for unsafe code in table construction, the lookup requires unsafe operations for performance So table construction can be done using safe code, and only the decoding lookup has to use unsafe
@@hyronharrison8127 "iOS is more secure" secure or not, a bug still exists (existed). And I'd argue that iOS is more secure - yeah, Apple does a great job of serving updates even to old devices, but Google does the same for Android, even on other manufacturers' devices (via Google Play security updates). Disallowed sideloading on iOS is more of an obstacle than a feature. (and APK sideloading is disabled on Android by default, which is the only correct way for both security and freedom)
@@geckwwonot to mention this isn’t Apple’s fault since it’s Google format and google responsibility so Apple was just better and fixed it without knowing it was a webp thing
I only wanted to know one thing from this video and that was why fuzzing didn’t find the vulnerability. Watched to the end and… “wait for the next video.”
I feel like this is a classic moment of the developers not following the golden rule called “never trust user input” because it really is just someone putting impossible values into it and it just doing what it was told without any checking if it was valid or not
Silver rule: Never trust C code. Firefox has a sandbox mechanism where it compiles libraries to wasm and then back to C, but I guess they hadn't gotten around to doing that for libwebp yet.
My thoughts exactly. I consider it common knowledge, at least to anyone worthy calling themselves professionals, that any externally provided data to any system should be checked and sanitized. There just exists no excuse for omitting that. Even less for a prolific image compression library like this one. If this vulnerability really turns out to be about completely missing sanitation of the compressed image data, then it begs the question how/why this code was ever accepted to run practically everywhere (at least on the internet).
If Google is the producer of this library, they should be deeply ashamed. Potentially even be held liable, by such a blatant transgression of a fundamental software engineering rule. While the bug itself might be interesting from a technical perspective, and illustrative of how dangerous unguarded edge conditions can be, omission of input sanitation is far from that. That is just unbelievably stupid, if not outright culpable negligence.
I hardly can believe that a company like Google would produce code like that, especially not for a library that is used almost anywhere were modern image formats are processed. I am still hoping I'm just getting this all wrong. I'll happily retract all I just wrote and put an official apology up here instead (if I got it all wrong). However, if it does turn out that this library did not do any input sanitation of the compressed image data, then the producers of this library (I presume the fine folks at Google) have some serious explaining to do!
@@elmo2you "Culpable negligence" LOL, is it not negligence to use other people's code without understanding it fully :)
@@sheesh236 Actually in the law it could be. THIS SOFTWARE IS PROVIDED WITHOUT WARRANTY, EVEN MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Yeah that's what I thought as well, it's actually surprising it took so long and was still a zero-day...
Never thought I'd ever actually use the huffman coding I learned during dsa. Good stuff
Exactly this came to my mind seeing the chrome cve back then. I realised my information theory professor really taught something useful lol.
Huffman coding is great! It's being replaced by arithmetic coding and asymmetrical number systems for entropy coding gains in newer codecs, but with diminishing returns :)
@@emblemi6345 why did you go to info theory without interest in it
Excellent video. Every other resource on this topic glosses over the details but this one dives right in. This series will be invaluable for new security researchers.
More than the vulnerability, I really loved how the huffman tree is optimised.
"Why you should study computer science, pay attention to your data structure and algorithm classes". This dialogue made me revisit the CSLR Intro to algo book after a long time 😂
Amazing book, filters me hard!
Amazing! Rally like the format, the how to get the basic knowledge for the problem, finding the keywords and also the explanation of the thought process.
I found myself that I like hacking and cyber security in general and in some days I ask my self:
*)- "how the photo or image are transmitted and we see it in the phone or computer... or even how it is captured from the beginning"?
And today I found this awesome video with awesome vulnerability with awesome channel. Thank you so much
I hope there will be more series like this one. :)
Damn script kiddies.
@@Nunya58294 I mean for the knowledge part, not for the scripting thing. Also, at some part people needs to start.
@@Nunya58294 bro be saying this and acting like he wasn't a skid at some point
File formats and compression are specific interests of mine, the Tom Scott video and the two Reducible videos are all ones that I've watched before 😁
Wow 🤩 amazing work in explaining this.
I hit like on his videos first and then watch it! Always learn so much from him. Thanks liveoverflow
you reminded me of club mate in one of the previous videos and i bought two in the supermarket, every time i drank a bottle of it i had such a schiss
Amazingly explained. Thank you!
Fun fact: if you also know about things like b-trees (binary trees that have multiple entries on a given level) the same reasoning applies to why huffman tables are used... cache locality!
If this vulnerability could have been found by a fuzzer, then why did no one bother to check? And if it cannot, why? What makes this vulnerability elusive to fuzzing?
I hope to see an answer to this in part 2!
my thoughts as well, first thing id think of when it comes to the wallet feature.
I recommend reading "Advanced Fuzzing Unmasks Elusive Vulnerabilities" post by Marc Heuse of Security Research Labs. It goes in depth about the possibility of finding vulnerabilities with advanced fuzzing techniques and whether those techniques could've surfaced this specific vulnerability in libwebp earlier.
The fuzzer would eventually enter the correct inputs to trigger this, but it might take forever!
In theory no exploit is elusive to a fuzzer if it can be triggered by a user, but we don't have infinite time or computing power
If someone was asked to read through the code and check for buffer vulnerabilities I bet they would have found it within a few hours. Obviously nobody performed a security audit on the code (or they were incompetent).
This might be a good application for an AI.
@@hung8969 It’s probably too complex of a chain to easily fuzz start to finish. You might as well put the effort into fuzzing the webp library directly.
FINALLY SOMEONE TALKING ABOUT THIS IN RUclips! 🙏👏👏
All the hands at 5:00 xdd
Brilliant video! So well explained and what a curious topic.
Shame you didn't take the opportunity to say "impossibilitree" though, that would have been good!!
im interested in the upcoming videos because this seems like an incredibly niche bug to find without deliberately looking for it, unlike many other bugs
Super cool video!
Top-notch, as always!
@LiveOverflow Could you make a video about the security risks of C if programmers don't know all the intricacies of it? What comes to mind is the recent Project64 Emulator exploit and stuff like scanf for example. It would be really interesting in my opionion as there are a lot of pitfalls when it comes to C programming
FBI backdoor my beloved
5:00 lol love that edit where u superimpose over tom scott. Red shirt gang.
Even simple task like counting battery percentage accurately isn't easy. Coulomb counting, kalman filter, exponential fitting, and least square algorithm are mixed well into one .c file, crazy! If you think that's hard, compression algorithm is a lot more crazier than that
Game Boy: "F that, I'll just run out of battery without warning"
@@williamdrum9899 lol reminds me chinese phone that has fluctuating battery percentage
YESSS !!! This is right down my hacking ally
Where’s the second video ? I feel like the only one not seeing it ;)
Yay, webp. The format you can't right click and save without extra steps! I wish they'd just delete the format lol
Where is part 2?
I have a question about road map in Malverne analysis and learn exploitation I feel free with books can you introduce me some books for learned this field I want to know I continued true or false in this way
but writing code in c is totally a good idea!!!!1!
My hot take: Programmers who don't know assembly have no business writing C
Does it means that this can be exploited currently on ios under a certain version ?
I don't know if i'm the only one but on my android tablet I cannot choose the quality of the video it is marked as unavailable in the options ... wtf and it choose a crappy one....
Push!
Some malware, spy app and virus is difficult to remove even after factory reset phone they came automatically don't know how I am in problem please help me . Not possible to change phone hard-disk
My brain hurts now after watching this video? I think, I see why this very problem...with that said though. I bearly understand any of that.😭😑 I didn't want to that job to begin with, and lucky don't because that seems like a not so fun time for me.😕 I don't even see the point of learning this.😅
But how would an image get turned into a nonsensical array?
The image exists and it gets turned into an array. Wouldn't that array be valid?
good question ;) and it's almost philosophical.
The image is not turned into a nonsensical array. There exists no image yet. If you see an image, it means that the bits and bytes were already interpreted and rendered! The vulnerability (and the nonsensical array) happen during the interpretation of the invalid bits and bytes.
The image doesn't need to have been created with the official WebP library, that will always generate valid results. One could write their own code to create an invalid image: a file that purports to be WebP but that doesn't follow the specification or doesn't match expectations in some way. Or they could open a valid image in a hex editor to directly edit its bytes, changing it to be invalid.
You can manually craft a file consisting of carefully picked bits that cause the decompression algorithm to generate an invalid huffman table. Then name the file with webp file type and send it to someone.
amazing
Can anyone explain the part 15:38, I couldn't get why is the tree invalid.
There are only two possible codes of length 1 - 0 or 1. So you cant assign 4 symbols with a code of length 1, only 2 symbols at most.
yo this guy looks like mr robot
Q about Hextree: Signups are disabled. How may I get a signup code please?
Would this be a vulnerability still on Rust? I am a complete ignorant in memory safe stuff.
13th
Israel’s Unit 8200 getting busy again 🙄
these are ex-8200 rather notoriously known and the unit is not associated with them at all, to the point of vilifying them and calling them hired guns
@@alonzy989 Talpiot Program is an offshoot of 8200 for the most successful red-teamers lol, it’s a promotion for them. 8200 operatives do not vilify Talpiot operations, they aspire to be recruited to them.
i beg you! please make a video on CHACHA20! ive been leanring about it for 3 months and still struggle to fully understand the 4x4..... its killing me lol
2th
Hehehe first😂
Olá, tenho um desafio pra você, tem como mudar o nome do Chipset de uma placa mãe, ou fazer com que o ryzen master não verifique a compatibilidade dela e abrir normalmente? 😂😳👉👈👍
All software needs to be rewritten using rust😢
Omg i thgought it was the hentai over fl0w part 2🤣🤣🤣🤣😌
IOs != World
What about Chrome?
They literally said Android, Linux and windows as well
Very interesting video, but i don't undestand one thing: how was this CVE exploited to gain root? Whether the malicious image was sent in whatsapp or iMessage or somewhere else, these apps are sandboxed just like any other IOS app - or are they not? The same applies to andoid, if you send the crafted image and it is parsed by an app, fair enough the attacker can get control of the app process, but i don't really understand how you can get root from that without other exploits to escape sandbox. So it should be either the target app runs as root or the sandbox implementation is flawed, and i can't find any info on what was the case.
Simple answer, there were other exploits to escape ;)
To remotely hack a phone you have to chain multiple security vulnerabilities to exploit each step. That's why they are so rare and special.
Thanks for clarification!
The day I heared about that vulnerability I was hoping for coverage on the technical details. Thank you so much for that!
they call it the Huffman's algorithm becoz the guy who came up with the algorithm was definitely huffing glue when he came up with this method to compress stuff !!!!
This vulnerability sounds so obvious in hindsight. It's parsing the image assuming that a correct program generated it. There must be some checks for it but clearly not enough.
There is a simple and common way to avoid this kind of problem. Any time a pointer is passed for data to be written to, always pass the maximum number of bytes that can be written and the function never writes more than that (or pass a buffer end pointer, same basic effect). Not doing that shows a serious lack of discipline on the part of the programmer(s).
Ah! I've spotted an incorrect thing in your videos, finally! 😋
At 7:08 you say that color values range from 0 - 255 and that a table would thus always have 255 entries. But 0 - 255 are 256 values :O
buffer overflow!
He misspoke. The correct number 256 was still written on the screen (“This table always holds 256 possible Symbols”).
Don't make videos about CVE's at Christmas man... someone of us didn't get over log4j yet...
It's interesting to note how much money was spent to roll out this update to final platforms and how it correlates with the funds that need to be invested to create a more secure version of the app.
PNG doesn't actually compress each color independently; the color-independence comes into play on the filtering level. The lossless compression step in PNG is a single giant Deflate (i.e. zip) stream.
Maybe the exploits discussed in the 37C3 talk "Operation Triangulation" could be interesting for video? They went over a lot of stuff in that talk that you could probably break down and explain pretty well
Instead of fixing the bug we could abandon webp format all together. What a missed opportunity for a humanity.
What you're saying is HERESY... "abandoning" the format is simply impossible (the cat is already out of the bag), so any security hole must be fixed ASAP. If you still think that "abandoning" the format is possible, go convince a few million people to up and take down every last .WEBP file out there!!!
I look three times at the webp source code to underst their huffman table implementation and you just clarified all my questions in three seconds
When would hextree be available?
Really good video
04:58 the red tshirt overlay is too perfect 😂
Edit: I'm hyped for the fuzzing video!
The stages involved in resolving issues related to CVE-2023-4863 include identification of the vulnerability, vendor acknowledgment, patch release, and updating affected products.
Could you show us some pentesting against teamspeak server?
Strong hacking world.
Huh, could that probably what was being used by pegasus?
amazing content, as always.
LETS GO CITIZEN LAB LOVE JSR
What a cliffhanger!
third
Good thing that webp isn't in UEFI based firmware yet. Only broken GIF, JPEG, PNG and BMP parsers. :D
Yeah so we can call it butter overflow not buffer 🤣
Heya, I've got a question that might be related to your past videos, but I thought it's better to ask it in your recent video.
In a read world scenario, suppose I successfully manage to perform some sort of attack, let's say exploit UAF or some shellcode injection, and I get a remote shell.
What can I do with this shell? In every CTF all I have to do is cat the flag file. But what can I do with a shell in a real world scenario? Could you give me some thoughts about it? Thanks!
Looking forward to the next videos and maybe even an ios exploit chain demonstration in a simulator?!
the best IT tutor on the internet
thank you for the job you are doing!!!!!!
I was studying DEFLATE this days lol
I started following your channel when I was in university and remembered being amazed by technical depth of your videos. Few years later, I am happy that I am able to follow along! Thanks a lot for making this series.
ty for your videos good soul! Party Hearty 💜
8:22 was the exact moment I said “oh shit”.
Great video
I don't want to live on this planet anymore
I bet Mark Adler is laughing at this one
As if I needed more reasons to hate webp
Webp has always been bad
Kommentar für den Algorithmus ;)
15th
Cool Video. I love your content.
What's the best way to protect ourselves until this is fixed?
it's fixed
This dude, instead of jump right into explaining the vulnerability and how it works he just goes on to ramble for the first 2 minutes. Anybody know his credentials? Listen dude people don't like spending time on youtube watching videos, how about you make all this more concise next time?
my credentials:
liveoveflow@gmail.com:stfu70053r
The classic Rust would have fixed that moment
While I am normally a rust shill, keep in mind _why_ this complex allocation was done: cache locality.
You could not reasonably do this in rust.
I would personally prefer safety over speed though, so I'd still say rust would be a good option if this was my personal project.
This specific problem is not something Rust would nor could have prevented-this is a programmer error by not validating the source input (i.e. file). The buffer could be overflowed by crafting an image file that caused the Huffman table construction to exceed the pre-calculated buffer size. So it would've been outside any compiler's knowledge.
What could potentially have caught it would have been using advanced fuzzing techniques. However, fuzzing is not a silver bullet, and this vulnerability was not caught by Google's OSS-Fuzz project. It's possible that fuzzing alone wouldn't have been enough to catch this vulnerability at all.
@@dealloc
> so it would've been outside of any compiler's knowledge
In other words, the compiler would insert a bounds check here and prevent the bug...
@@MrFram The vulnerability was introduced when applying a common optimization used in Huffman decoders; The decoder was optimized by pre-reading N bits to determine how many to consume and which symbol to decode. Longer symbols previously required graph traversal but were improved using an array of lookup tables. The new tables store (nbits, value) pairs; if nbits exceeds N, it's a table index, enabling efficient decoding. However, a bug emerged during table construction, risking overflow due to unanticipated table sizes.
Rust's safety mechanisms might not have caught this because while it's unsuitable for unsafe code in table construction, the lookup phase often requires unsafe operations for performance.
Even tools like "enough" in zlib, as explained in this video, predict table sizes under specific constraints, but when those constraints aren't met, Rust's safety wouldn't prevent a wrong table construction, potentially leading to security issues.
@@dealloc stop using chatgpt and actually think about what you just wrote.
> it's unsuitable for unsafe code in table construction, the lookup requires unsafe operations for performance
So table construction can be done using safe code, and only the decoding lookup has to use unsafe
Nothing is secure by design.
The proof is "pegasus" ;)
But IOS is more secure!
Did you even watch the video? Smh
@@geckwwo i did
@@hyronharrison8127 "iOS is more secure" secure or not, a bug still exists (existed). And I'd argue that iOS is more secure - yeah, Apple does a great job of serving updates even to old devices, but Google does the same for Android, even on other manufacturers' devices (via Google Play security updates). Disallowed sideloading on iOS is more of an obstacle than a feature. (and APK sideloading is disabled on Android by default, which is the only correct way for both security and freedom)
@@geckwwonot to mention this isn’t Apple’s fault since it’s Google format and google responsibility so Apple was just better and fixed it without knowing it was a webp thing
I never trusted WebP 😒
But vuln is fixed now
@@LiveOverflow Still don't trust it 🧐
I only wanted to know one thing from this video and that was why fuzzing didn’t find the vulnerability. Watched to the end and… “wait for the next video.”
First 😎
you are the actual first!
@@ItIsJan I’m a pro speedrunner now lol
Your mom’s first
@@Wierie_ HAHAHAHA what a creative joke, you’re hilarious
This will be pinned!
If only they had rewritten it in rust.
unko