A Vulnerability to Hack The World - CVE-2023-4863
Вставка
- Опубліковано 11 чер 2024
- Citizenlab discovered BLASTPASS, a 0day being actively exploited in the image format WebP. Known as CVE-2023-4863 and CVE-2023-41064, an issue in webp's build huffman table function can lead to a heap buffer overflow. This vulnerability is very interesting and I'm excited to share with you what I learned.
Want to learn hacking? Signup to hextree.io (ad)
Buy my shitty font: shop.liveoverflow.com/ (ad)
WebP Fix Commit: chromium.googlesource.com/web...
Citizenlab: citizenlab.ca/2023/09/blastpa...
Ben Hawkes: blog.isosceles.com/the-webp-0...
Software Updates
Apple support.apple.com/en-gb/106361
Chrome chromereleases.googleblog.com...
Firefox www.mozilla.org/en-US/securit...
Android www.mozilla.org/en-US/securit...
Whose CVE is it Anyway? adamcaudill.com/2023/09/14/wh...
References:
2014 bug introduction github.com/webmproject/libweb...
• How Computers Compress...
• Huffman Codes: An Info...
• How PNG Works: Comprom...
• Huffman coding step-by...
stackoverflow.com/questions/1...
web.archive.org/web/202302042...
enough.c github.com/madler/zlib/blob/d...
Thanks to:
/ mistymntncop
/ benhawkes
Chapters:
00:00 - Intro to CVE-2023-4863
01:32 - Most Valuable Vulnerability?
03:02 - Heap Overflow Related to Huffman Trees
03:58 - Learning about Huffman Codes
06:24 - What are Huffman Tables?
10:24 - Hardcoded Table Sizes (enough.c)
12:21 - Code Walkthrough - BuildHuffmanTable()
13:04 - The code_lengths[] and count[] Arrays
15:14 - Difference Between Compression and Decompression!
17:04 - Outro
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
2nd Channel: / liveunderflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Streaming: twitch.tvLiveOverflow/
→ TikTok: / liveoverflow_
→ Instagram: / liveoverflow
→ Blog: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
More than the vulnerability, I really loved how the huffman tree is optimised.
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
The day I heared about that vulnerability I was hoping for coverage on the technical details. Thank you so much for that!
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 book, filters me hard!
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.
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.
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 !!!!
Amazingly explained. Thank you!
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
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
I loved the way you researched. I joined. I will take a look more on your educational stuff. Cheers!
Top-notch, as always!
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
amazing content, as always.
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!
The stages involved in resolving issues related to CVE-2023-4863 include identification of the vulnerability, vendor acknowledgment, patch release, and updating affected products.
the best IT tutor on the internet
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 😁
ty for your videos good soul! Party Hearty 💜
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
thank you for the job you are doing!!!!!!
FINALLY SOMEONE TALKING ABOUT THIS IN UA-cam! 🙏👏👏
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”).
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).
Really good video
04:58 the red tshirt overlay is too perfect 😂
Edit: I'm hyped for the fuzzing video!
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
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
What a cliffhanger!
All the hands at 5:00 xdd
8:22 was the exact moment I said “oh shit”.
Great video
YESSS !!! This is right down my hacking ally
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.
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!
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!!
FBI backdoor my beloved
Looking forward to the next videos and maybe even an ios exploit chain demonstration in a simulator?!
LETS GO CITIZEN LAB LOVE JSR
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!
Strong hacking world.
5:00 lol love that edit where u superimpose over tom scott. Red shirt gang.
amazing
When would hextree be available?
I was studying DEFLATE this days lol
Push!
Cool Video. I love your content.
@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
Huh, could that probably what was being used by pegasus?
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
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....
Where’s the second video ? I feel like the only one not seeing it ;)
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!!!
Does it means that this can be exploited currently on ios under a certain version ?
Good thing that webp isn't in UEFI based firmware yet. Only broken GIF, JPEG, PNG and BMP parsers. :D
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!
What's the best way to protect ourselves until this is fixed?
it's fixed
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
Could you show us some pentesting against teamspeak server?
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?
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.😅
Nokiaaaaaaaaa!
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.
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
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
Kommentar für den Algorithmus ;)
5:56 I still don't understand how its only 5 bits. 5 bits is the size of the location of the data your trying to retrieve it would only reduce the data size if their is multiple of a character, what if there was only 1 of each character wouldnt that increase the size as it would be 5 bits for the location plus 8 bits for each character
Yes. You always need to communicate the lookup table as well. For actual compression, this means that your data should have repetition, so savings can outweigh the upfront cost of the lookup table.
@@RecursiveTriforce Speaking of images ... shouldn't that be the case? I mean like always
As you can see, the example tree is not symmetrical or balanced. To get to another character, it's only 4 bits. Or maybe 8 bits (you can see that it's a good idea to encode the characters that don't occur often with a long "location sequence" whole the most used character is just encoded by a 1.
If every character occurs the same amount of times, the tree will still encode one character as 1, one as 11, one as 101 etc. So the l
@@borstenpinsel even though that would increase reading speeds wouldnt that make it use more storage
@letsgetto1millwithoutvids in an edge case, I guess. But we're talking images here. Every pixel is 24 (or 32) bit. That's 16 million colours (or 3.x billion). So, in a 16MP image (reasonable resolution for slightly older cameras and I guess many smartphones in default setting), every pixel needs to be different. (And even then, 2 bytes are the same, so there's room for compression). But let's say everything is unique somehow: it's extremely unlikely that a picture looks like that, and if every colour exists 2 times, it's already significantly smaller size.
And if it's really that bad, maybe a different algorithm will be used. The exploit is in the huffman algorithm, so the video is about that, but the webp might use many different algorithms for different kinds of images.
An example is the repeating char compression. If you have many pixels of the same color, in huffman tree you would still need to write "1" (most common char/color) a bunch of times. But writing 1000xff00ff takes up way less space than 11111111111....
Every tree or every sorting algorithm will have cases where it performs really bad. Perhaps even worse than an algorithm that is generally considered inferior. But iif that case is super rare, you can still use it and achieve incredible results 99% of the time. Or you can analyse the data and then code your library in such ac way that a different algorithm is used.
yo this guy looks like mr robot
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.
Yeah so we can call it butter overflow not buffer 🤣
I don't want to live on this planet anymore
I bet Mark Adler is laughing at this one
Would this be a vulnerability still on Rust? I am a complete ignorant in memory safe stuff.
13th
15th
Edit: I initially had a critique of the video on explaining the jump from the tree to table for huffman encoding, but OP does provide the necessary information, but some of it is subtle and the part best explaining this is a bit later in the video at 13:10.
During the clip for explaining the huffman table, I think questions like "Why does it only require 1 bit to decode 'a' but 3 bits for 'c'? I thought three bits were required for each character but you just moved 1 digit over after reading 010?" are natural even if you were following along with the trees but a bit lost on the table. Timestamp 13:10 is a good spot to skip ahead and then go back. Each character is encoded by three bits, but what we are seeing is a "compressed" version of their three bit encodings *because* of the huffman encoding and its properties. So the string of binary digits is really the compressed data and we read it based on the necessary information to deduce what character they correspond to (recall that the average number of binary questions needed to ask to get the answer is entropy). This is why huffman trees have high frequency data points towards the root, but it requires less information. Hence, this is more efficient on average and allows us to efficeintly compress the data in this way where 'a' (frequent data) requires 1 bit (binary question) but 'd' requires 3 bits.
Did you watch the video? I mentioned all those things ;)
You mainly just talked about resources you used with little explanation, which is valid since the video can only be so long and isn't a tutorial on huffman encodings.
I think everything you said I mentioned with at least one sentence. Though it was very condensed and fast
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.”
Nothing is secure by design.
The proof is "pegasus" ;)
third
2th
Don't make videos about CVE's at Christmas man... someone of us didn't get over log4j yet...
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.
As if I needed more reasons to hate webp
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
Takeaway for me is to disallow webp formatted images in the app. No big loss.
but it's fixed now
@@LiveOverflowI never allowed webp in my apps, anyway. gif, jpeg, png, and svg seems like an inclusive enough range of inputs.
And png and jpeg never had similar issues?
yeah, disallowing a widely-used image format because of a since-fixed vulnerability in a decoder is a short-sighted choice. this is particularly odd in the context of allowing SVG, which has exponentially more complexity and larger potential attack surface than any raster image format I am aware of.
@@PaulFisher Nah, it's a choice to simplify and streamline.
Hehehe first😂
This will be pinned!
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
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
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? 😂😳👉👈👍
I never trusted WebP 😒
But vuln is fixed now
@@LiveOverflow Still don't trust it 🧐
Webp has always been bad
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
IOs != World
What about Chrome?
They literally said Android, Linux and windows as well
Omg i thgought it was the hentai over fl0w part 2🤣🤣🤣🤣😌
ok but rust