A Vulnerability to Hack The World - CVE-2023-4863
Рет қаралды 104,838
Күн бұрын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
@psaini1999 5 ай бұрын
More than the vulnerability, I really loved how the huffman tree is optimised.
@patfre 5 ай бұрын
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
@WitherBossEntity 5 ай бұрын
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.
@elmo2you 5 ай бұрын
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!
@sheesh236 5 ай бұрын
@@elmo2you "Culpable negligence" LOL, is it not negligence to use other people's code without understanding it fully :)
@thewhitefalcon8539 5 ай бұрын
@@sheesh236 Actually in the law it could be. THIS SOFTWARE IS PROVIDED WITHOUT WARRANTY, EVEN MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
@erikkonstas 5 ай бұрын
Yeah that's what I thought as well, it's actually surprising it took so long and was still a zero-day...
@actuallynxiss 5 ай бұрын
Never thought I'd ever actually use the huffman coding I learned during dsa. Good stuff
@emblemi6345 5 ай бұрын
Exactly this came to my mind seeing the chrome cve back then. I realised my information theory professor really taught something useful lol.
@cancername 5 ай бұрын
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 :)
@kreuner11 5 ай бұрын
@@emblemi6345 why did you go to info theory without interest in it
@TmOnlineMapper 5 ай бұрын
The day I heared about that vulnerability I was hoping for coverage on the technical details. Thank you so much for that!
@danielgysi5729 5 ай бұрын
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.
@mahfuzsobhan8184 5 ай бұрын
"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 😂
@k3dr1 5 ай бұрын
Amazing book, filters me hard!
@vishalmishra7018 5 ай бұрын
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.
@0heinz0 5 ай бұрын
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.
@fouzaialaa7962 5 ай бұрын
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 !!!!
@dragonminz602 5 ай бұрын
Amazingly explained. Thank you!
@will_i_craft5555 5 ай бұрын
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
@n1rus 5 ай бұрын
Wow 🤩 amazing work in explaining this.
@dfsrow 5 ай бұрын
I hit like on his videos first and then watch it! Always learn so much from him. Thanks liveoverflow
@oscarllerena2980 5 ай бұрын
I loved the way you researched. I joined. I will take a look more on your educational stuff. Cheers!
@k0ns0l 5 ай бұрын
Top-notch, as always!
@free_user 5 ай бұрын
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
@eliluong 5 ай бұрын
amazing content, as always.
@0xGRIDRUNR 5 ай бұрын
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!
@user-zu4ft8yw9e 2 ай бұрын
The stages involved in resolving issues related to CVE-2023-4863 include identification of the vulnerability, vendor acknowledgment, patch release, and updating affected products.
@hamzahajjaj4106 5 ай бұрын
the best IT tutor on the internet
@cinderwolf32 5 ай бұрын
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 😁
@MisterQuacker 5 ай бұрын
ty for your videos good soul! Party Hearty 💜
@kipchickensout 5 ай бұрын
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
@mrdzha9519 5 ай бұрын
thank you for the job you are doing!!!!!!
@teogorqui7061 5 ай бұрын
FINALLY SOMEONE TALKING ABOUT THIS IN KZfaq! 🙏👏👏
@boomknuffelaar 5 ай бұрын
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
@kwzu 5 ай бұрын
buffer overflow!
@KonstantinUb 5 ай бұрын
He misspoke. The correct number 256 was still written on the screen (“This table always holds 256 possible Symbols”).
@psaini1999 5 ай бұрын
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.
@nicholasvinen 5 ай бұрын
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).
@TheRobinrosenberg 5 ай бұрын
Really good video
@SoreBrain 5 ай бұрын
04:58 the red tshirt overlay is too perfect 😂 Edit: I'm hyped for the fuzzing video!
@wareya 5 ай бұрын
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.
@mrfincher 5 ай бұрын
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
@ru31k32 5 ай бұрын
I hope there will be more series like this one. :)
@Nunya58294 5 ай бұрын
Damn script kiddies.
@ru31k32 5 ай бұрын
@@Nunya58294 I mean for the knowledge part, not for the scripting thing. Also, at some part people needs to start.
@Umbreedon 4 ай бұрын
@@Nunya58294 bro be saying this and acting like he wasn't a skid at some point
@LongBean7 5 ай бұрын
What a cliffhanger!
@forestrf 5 ай бұрын
All the hands at 5:00 xdd
@pognar 5 ай бұрын
8:22 was the exact moment I said “oh shit”. Great video
@kevinwydler7305 5 ай бұрын
YESSS !!! This is right down my hacking ally
@wChris_ 5 ай бұрын
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!
@hung8969 5 ай бұрын
my thoughts as well, first thing id think of when it comes to the wallet feature.
@dealloc 5 ай бұрын
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.
@philipegoulet448 5 ай бұрын
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
@nicholasvinen 5 ай бұрын
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.
@JamEngulfer 5 ай бұрын
@@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.
@zyansheep 5 ай бұрын
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!
@thegooddalek04 5 ай бұрын
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!!
@lootclan5842 5 ай бұрын
FBI backdoor my beloved
@mystmuffin3600 5 ай бұрын
Looking forward to the next videos and maybe even an ios exploit chain demonstration in a simulator?!
@MoiJsuisTropBeauPourToi 5 ай бұрын
LETS GO CITIZEN LAB LOVE JSR
@netanelkomm5636 5 ай бұрын
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!
@BlackHermit 5 ай бұрын
Strong hacking world.
@bigmistqke 5 ай бұрын
5:00 lol love that edit where u superimpose over tom scott. Red shirt gang.
@somiltyagi7127 5 ай бұрын
amazing
@kingshukcs 5 ай бұрын
When would hextree be available?
@xspager 5 ай бұрын
I was studying DEFLATE this days lol
@tg7943 4 ай бұрын
Push!
@tobixnator9314 5 ай бұрын
Cool Video. I love your content.
@skylo706 3 ай бұрын
@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
@YandiBanyu 5 ай бұрын
Huh, could that probably what was being used by pegasus?
@KangJangkrik 5 ай бұрын
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
@williamdrum9899 5 ай бұрын
Game Boy: "F that, I'll just run out of battery without warning"
@KangJangkrik 5 ай бұрын
@@williamdrum9899 lol reminds me chinese phone that has fluctuating battery percentage
@TheRobbix1206 5 ай бұрын
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....
@davidchill79 5 ай бұрын
Where’s the second video ? I feel like the only one not seeing it ;)
@nejuspesnejsi 5 ай бұрын
Instead of fixing the bug we could abandon webp format all together. What a missed opportunity for a humanity.
@erikkonstas 5 ай бұрын
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!!!
@rambo6573 5 ай бұрын
Does it means that this can be exploited currently on ios under a certain version ?
@CyReVolt 5 ай бұрын
Good thing that webp isn't in UEFI based firmware yet. Only broken GIF, JPEG, PNG and BMP parsers. :D
@deathflavouredfart 4 ай бұрын
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.
@LiveOverflow 4 ай бұрын
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.
@deathflavouredfart 4 ай бұрын
Thanks for clarification!
@williamdrum9899 5 ай бұрын
What's the best way to protect ourselves until this is fixed?
@LiveOverflow 5 ай бұрын
it's fixed
@user-allah_God 5 ай бұрын
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
@Andi-pv3sj 5 ай бұрын
Could you show us some pentesting against teamspeak server?
@PwnySlaystation01 5 ай бұрын
Yay, webp. The format you can't right click and save without extra steps! I wish they'd just delete the format lol
@flipped_bit 5 ай бұрын
Where is part 2?
@wildstorm74 5 ай бұрын
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.😅
@ramiroaka9 5 ай бұрын
Nokiaaaaaaaaa!
@codieefranchise4637 5 ай бұрын
Can anyone explain the part 15:38, I couldn't get why is the tree invalid.
@hamburgerfatso 5 ай бұрын
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.
@jfb- 5 ай бұрын
but writing code in c is totally a good idea!!!!1!
@williamdrum9899 5 ай бұрын
My hot take: Programmers who don't know assembly have no business writing C
@user-xd2gm5xu8e 4 ай бұрын
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
@mrAjor 5 ай бұрын
Kommentar für den Algorithmus ;)
@letsgetto1millwithoutvids 5 ай бұрын
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
@RecursiveTriforce 5 ай бұрын
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.
@EdubSi 5 ай бұрын
@@RecursiveTriforce Speaking of images ... shouldn't that be the case? I mean like always
@borstenpinsel 5 ай бұрын
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
@letsgetto1millwithoutvids 5 ай бұрын
@@borstenpinsel even though that would increase reading speeds wouldnt that make it use more storage
@borstenpinsel 5 ай бұрын
@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.
@tony5226 5 ай бұрын
yo this guy looks like mr robot
@alexestefan7521 5 ай бұрын
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?
@LiveOverflow 5 ай бұрын
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.
@tomysshadow 5 ай бұрын
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.
@hamburgerfatso 5 ай бұрын
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.
@hamahawlery7194 5 ай бұрын
Yeah so we can call it butter overflow not buffer 🤣
@imax9000 5 ай бұрын
I don't want to live on this planet anymore
@0xKilty 5 ай бұрын
I bet Mark Adler is laughing at this one
@TomasRoggero 5 ай бұрын
Would this be a vulnerability still on Rust? I am a complete ignorant in memory safe stuff.
@adithya543 5 ай бұрын
13th
@Andrew-Galvin 5 ай бұрын
15th
@thefourthbrotherkaramazov245 5 ай бұрын
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.
@LiveOverflow 5 ай бұрын
Did you watch the video? I mentioned all those things ;)
@thefourthbrotherkaramazov245 5 ай бұрын
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.
@LiveOverflow 5 ай бұрын
I think everything you said I mentioned with at least one sentence. Though it was very condensed and fast
@GuyMassicotte 5 ай бұрын
Nothing is secure by design. The proof is "pegasus" ;)
@sjswitzer1 5 ай бұрын
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.”
@_Wansmet 5 ай бұрын
third
@daominh89 5 ай бұрын
2th
@WistrelChianti 5 ай бұрын
Don't make videos about CVE's at Christmas man... someone of us didn't get over log4j yet...
@MikeJones-mf2rt 5 ай бұрын
Israel’s Unit 8200 getting busy again 🙄
@alonzy989 5 ай бұрын
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
@MikeJones-mf2rt 5 ай бұрын
@@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.
@eno88 5 ай бұрын
As if I needed more reasons to hate webp
@alang.2054 5 ай бұрын
The classic Rust would have fixed that moment
@coarse_snad 5 ай бұрын
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.
@dealloc 5 ай бұрын
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.
@MrFram 5 ай бұрын
@@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...
@dealloc 5 ай бұрын
@@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.
@MrFram 5 ай бұрын
@@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
@RichardLucas 5 ай бұрын
Takeaway for me is to disallow webp formatted images in the app. No big loss.
@LiveOverflow 5 ай бұрын
but it's fixed now
@RichardLucas 5 ай бұрын
@@LiveOverflowI never allowed webp in my apps, anyway. gif, jpeg, png, and svg seems like an inclusive enough range of inputs.
@LiveOverflow 5 ай бұрын
And png and jpeg never had similar issues?
@PaulFisher 5 ай бұрын
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.
@RichardLucas 5 ай бұрын
@@PaulFisher Nah, it's a choice to simplify and streamline.
@marioniangi 5 ай бұрын
Hehehe first😂
@realzguardian 5 ай бұрын
This will be pinned!
@hung8969 5 ай бұрын
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
@Cornbread2100 5 ай бұрын
First 😎
@ItIsJan 5 ай бұрын
you are the actual first!
@Cornbread2100 5 ай бұрын
@@ItIsJan I’m a pro speedrunner now lol
@Wierie_ 5 ай бұрын
Your mom’s first
@Cornbread2100 5 ай бұрын
@@Wierie_ HAHAHAHA what a creative joke, you’re hilarious
@fb_zero 5 ай бұрын
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? 😂😳👉👈👍
@_CryptoCat 5 ай бұрын
I never trusted WebP 😒
@LiveOverflow 5 ай бұрын
But vuln is fixed now
@_CryptoCat 5 ай бұрын
@@LiveOverflow Still don't trust it 🧐
@mohamedmonem2645 5 ай бұрын
Webp has always been bad
@hyronharrison8127 5 ай бұрын
But IOS is more secure!
@geckwwo 5 ай бұрын
Did you even watch the video? Smh
@hyronharrison8127 5 ай бұрын
@@geckwwo i did
@geckwwo 5 ай бұрын
@@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)
@patfre 5 ай бұрын
@@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
@Nikebl 5 ай бұрын
IOs != World
@RecursiveTriforce 5 ай бұрын
What about Chrome?
@patfre 5 ай бұрын
They literally said Android, Linux and windows as well
@shortseror3033 5 ай бұрын
Omg i thgought it was the hentai over fl0w part 2🤣🤣🤣🤣😌
@girlswithgames 5 ай бұрын
ok but rust
Tomaž Zaman
Рет қаралды 1 МЛН