Chrome: Heap buffer overflow in WebP

https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html

by skilled • 3 years ago

333 252 3 years ago

chromereleases.googleblog.com

jeroenhd5• 3 years ago

Well, that's pretty bad. User-uploaded WebP images are used in tons of messengers and tons of messengers also use Chrome's render engine to produce "native" apps that get statically compiled (i.e. a single update isn't enough to patch your system, every app needs an update). I hope this is just Google Chrome, somehow.

The secrecy is a little annoying. The page links to two places where you can supposedly find details, but both are internal resources. It's hard to judge how pervasive the bug is, and to find out if other software using Chrome as a render engine are also affected.

Also pretty comical that Google's Project Zero policy is to release details (edit: 7 days after) a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable. Good for Apple that they didn't decide to pay Google back in kind.

suddenclarity2• 3 years ago

Why release details publicly before people have a chance to update?

jeroenhd5• 3 years ago

To hasten security vendor response is usually the most important reasons. Software vendors, especially corporate ones, will happily keep a known vulnerability under embargo for years if you let them.

Google's page (https://googleprojectzero.blogspot.com/p/vulnerability-discl...) has their reasoning explained in some more detail.

rs_rs_rs_rs_rs• 3 years ago

Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable

That is not true please stop spreading misinformation.

jeroenhd5• 3 years ago

You're right, after looking it up I found that the time period for actively exploited bugs is seven days. I must've misremembered.

lima• 3 years ago

Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable.

Project Zero treats Google like any other vendor (much to the annoyance of other internal teams).

icelusxl• 3 years ago

Seems to be reported by Apple and looks a lot like this security update: https://support.apple.com/en-us/HT213906

masklinn3• 3 years ago

Reported by Apple “and the citizen lab at the UoT Munk School”, which is exactly who’s attributed on the page you link to. So yeah seems pretty likely, either Apple uses libwebp internally in ImageIO or they made a similar mistake.

saagarjha9• 3 years ago

Former

brigade2• 3 years ago

It is interesting to see how different the reactions are now than last week

frankjr3• 3 years ago

Fix OOB write in BuildHuffmanTable

https://github.com/webmproject/libwebp/commit/902bc919033134...

hannob3• 3 years ago

Also interesting: Shortly after there is another commit that is related to oss-fuzz: https://github.com/webmproject/libwebp/commit/95ea5226c87044...

This could mean Google optimized their fuzzers for libwebp after finding that bug and now they're finding more.

londons_explore5• 3 years ago

Within Google Chrome, WebP images are decoded by the renderer, and therefore any exploit can only get renderer code execution - which is inside a sandbox.

Since the renderer is very complex, there are lots of exploits discovered each year for it. However, when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get. Specifically, they can't see or leave files on the filesystem of your machine, nor even read cookies for other domains.

sigmoid10• 3 years ago

Getting permissions on a single website user context is already enough considering the vast amount of user uploaded images on the modern internet. It's a bit like XSS on steroids, because it is not limited to one site or frontend.

londons_explore5• 3 years ago

Well websites are stupid if they don't reencode user-uploaded images for precisely this reason...

Otherwise an evil client uploads a malicious webp image, which then gets hosted and 'shared' by the server to other users, who upon viewing said image get exploited and share more malicious images...

insanitybit11• 3 years ago

The idea here would be that I'm visiting Reddit, someone uploads a malicious WebP, and now my Reddit account is owned, right?

dspillett3• 3 years ago

when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get

Unless of course there is a sandbox break-out exploit to combine this with. So not an immediate priority, unless there is such an exploit in the wild that I don't know about, but important to patch as soon as not terribly inconvenient.

vinay_ys2• 3 years ago

Well, this was exploited in the wild. Here's the actual commit for the bug fix in webp. https://chromium.googlesource.com/webm/libwebp/+/902bc91

amelius• 3 years ago

Are you saying that the renderer can't send information back to the website?

Also, perhaps you turned off JavaScript, and now all of a sudden the website can still execute code?

__s• 3 years ago

I'm using lossless webp, it's much more efficient than png

(oops, wrong thread, meant to reply to https://news.ycombinator.com/item?id=37479576 "jpeg is good enough")

lifthrasiir17• 3 years ago

This security bug specifically happens in the WebP Lossless decoder ("VP8L").

the_sleaze9• 3 years ago

I lol'd

PedroBatista• 3 years ago

Looks like you're in a position of not losing anything. ( other than a system and accounts due to a hack )

vntok• 3 years ago

Is it Web scale?

londons_explore5• 3 years ago

I'm sure that in 2023, no mainstream software runs image decoders outside a sandbox right??

rfoo2• 3 years ago

... and then people chain it with a sandbox escape.

This bug is the initial vector of last week's NSO Group zero-click exploit for iPhones: https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

londons_explore5• 3 years ago

The sandbox escape is the 'bigger' issue really.

Applications parse crazy complex stuff to do everything they do, so obviously have a really big attack surface. Often the complexity is unavoidable - if you are a web browser, you cannot avoid parsing html for example.

However the sandbox is designed to have an attack surface as small as possible (and be configurable via permissions to have the bare minimum needed). The sandbox interfaces with the rest of the system are fully controllable by Apple, so there is no need to be passing complex and dangerous legacy datastructures across the boundary either.

Therefore, it should be the sandbox that is 'hardest' to break out of.

intelVISA• 3 years ago

Yep, not following best practices was banned late 2022 so thankfully your fave outsourced shop is only shipping High Quality and Secure Code (tm)

Oh wait, that whole LLM thing...

olliej• 3 years ago

Right, so all attacks now go:

1. Send payload to a process (image in a browser say)

2. Use payload to get code execution

3. If your current process has all the access you need then go forth and conquer; else

4. Send a payload to another process, go to step 2

Sandboxes are mitigations and roadblocks that increase the complexity of an attack they don’t make them go away.

gavinsyancey• 3 years ago

Does this affect electron as well? If so, what versions?

frankjr3• 3 years ago

It does, see [0]. Fun fact: Signal desktop, which uses Electron under the hood, is running without sandbox on Linux [1][2].

[0] https://github.com/electron/electron/pull/39824

[1] https://github.com/signalapp/Signal-Desktop/issues/5195

[2] https://github.com/signalapp/Signal-Desktop/pull/4381

Y-bar• 3 years ago

I just love the unnecessary jousting with the stupid stale bot in 5195

est312• 3 years ago

To be fair, if signal didn't use electron, they would probably have used libwebp still, and then they would either have to implement sandboxing themselves, or they would be subject to the same vulnerability. Still, that they didn't prioritize this is sad.

SubzeroCarnage• 3 years ago

This will be in today's Firefox 117.0.1 and Fenix 117.1.0: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

montzark• 3 years ago

Imo other related code of the person who made that mistake should be audited, could be there is similiar mistake somewhere else.

Additionally imo possible that some developers would intentionally make such mistakes to sell these to interested persons, there are millions to be made here.

isodev2• 3 years ago

Establishing a blaming culture would be quite detrimental. Bugs happen, regardless of who commits the code.

A more robust approach is to implement appropriate checks (like fuzzing, code analysis etc) that offer an opportunity to review and correct issues before they ship (and for people to learn from).

irundebian5• 3 years ago

The chromium developers do all this but this hasn't prevent this bug.

vitus• 3 years ago

The breakage [0] was introduced by the creator [1] of the project. If you want to audit 1674 commits over the past 12 years, it'd be easier to just audit the full project.

[0] https://github.com/webmproject/libwebp/commit/21735e06f7c1cb...

[1] https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32...

flohofwoe• 3 years ago

Why even bother looking at other code this person wrote? Straight to jail for such a capital offense!!! (jeesus dude...)

yjftsjthsd-h• 3 years ago

Nobody said that. The suggestion was that probably that if this is caused by, say, one person having a slightly wrong mental model, it's worth checking if they made similar mistakes elsewhere. Not necessarily implying fault, just a heuristic. (And given the particular author, in this case probably not super useful, but still a decent question)

irundebian5• 3 years ago

It would be interesting to know how this vulnerability has been found.

fh9302• 3 years ago

https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

Last week, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices, Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware.

And since the initial bug appears to be in Google's webp library other programs are also vulnerable.

irundebian5• 3 years ago

Okay, but I mean the initial finders of the vulnerability. If they are conducted manual code reviews, automatic static analyses or fuzzing.

kouteiheika• 3 years ago

It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages?

Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc919033134...

I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3].

[1] -- https://code.videolan.org/videolan/dav1d

[2] -- https://github.com/AOMediaCodec/libavif

[3] -- https://github.com/AOMediaCodec/libiamf

Yep. Keep writing these in C; surely nothing will go wrong.

masklinn3• 3 years ago

We all know that’s The Price Of Freedom. As they say, “give me exploitable trivial memory safety bugs or give me authoritarian dystopia” (https://news.ycombinator.com/item?id=27638940).

ignoramous4• 3 years ago

Dystopia? Given a choice, you'd rather trust a compiler than a human given the billions already lost to buffer overflows, read after free, and other memory related bugs, surely?

EustassKid• 3 years ago

Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?

LoganDark3• 3 years ago

...What is a "safe C compiler"?

vesinisa• 3 years ago

This is a great question.

The answer is that it's literally impossible to write a "safe C compiler" since the language is inherently memory unsafe.

There are various static analysis tools that can try to simulate C programs and try to automatically discover memory management bugs, but due to fundamental limitations of computation they can never catch all possible faults.

pjc502• 3 years ago

You can't really retrofit safety to C. The best that can be achieved is sel4, which while it is written in C has a separate proof of its correctness: https://github.com/seL4/l4v

The proof is much, much more work than the microkernel itself. A proof for something as large as webP might take decades.

lightedman• 3 years ago

If you think Rust is entirely memory-safe, I've got a bridge in Brooklyn to sell you.

Man can make it, man can break it.

quickthrower2• 3 years ago

Does it have to be? Riding a bicycle with a helmet isn’t entirely safe, but I still prefer to wear one.

acdha18• 3 years ago

That’s like saying we shouldn’t wear seatbelts or have airbags and antilock brakes because you can still die in a crash.

If anything, that’s still underselling it: there are entire categories of bug which are widespread even in well-tested, heavily-fuzzed C codebases like Chrome but would not be likely or often possible in Rust.

lifthrasiir17• 3 years ago

We don't have a very good mainstream [1] solution for critical and performance-hungry applications. I do think that they are limited in number (many applications are not that performance-hungry) and Rust is already good enough, but those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added. This particular bug could have been reasoned once you know where to look at, after all.

[1] In my definition, this translates to "as popular and user-friendly as sanitizers".

bennettnate5• 3 years ago

those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added

There are actually already tools built for this very purpose in Rust (see Kani [1] for instance).

Formal verification has a serious scaling problem, so forming programs in such a way that there are a few performance-critical areas that use unsafe routines seems like the best route. I feel like Rust leans into this paradigm with `unsafe` blocks.

[1] https://github.com/model-checking/kani

irundebian5• 3 years ago

It should be possible with Ada/SPARK. It's focused on low level systems programming and compilable programs are free from run-time errors. In addition, the correctness of the program or key properties can be proven at compile-time.

ignoramous4• 3 years ago

"as popular and user-friendly as sanitizers" solution for critical and performance-hungry applications.

Google just did enable Memory Tagging Extension (ARM's hardware accelerated sanitizers) on the Pixels last year. May be sanitizing ISAs offer hope?

alexvitkov2• 3 years ago

We still don't have an alternative. No, you can't use Arc<HashMap<Whatever>> in the middle of a decoder routine. Some software to actually has to perform well.

lifthrasiir17• 3 years ago

In this particular case Rust could have helped, because the table construction can use a normal Rust while the tight decoder loop can remain `unsafe` which can be justified more easily. But I demand more than the human-readable justification.

cypress66• 3 years ago

Even if bounds checking made the decoder 10x slower, would that even matter, outside of low end mobile devices? How many milliseconds are spent decoding images in your average website anyway?

Ar-Curunir• 3 years ago

Thankfully you can write C-like Rust code if you wanted, just safe. Nobody says that you have to use a "Arc<HashMap<Whatever>>" for this task. Indeed, people have written competitive and safe decoders for various image and video formats in Rust already.

cookiengineer2• 3 years ago

Stagefright was the point when I started to tell people to use a safe programming language.

When they ask "Which one?" I am answering "I don't care, as long as it's a programming language that uses a VM".

Every time I hear the discussions about how fast and perfect C is, people seem to miss the point that new programming languages try to avoid complexity, because they were using C/C++ themselves in the past and they fell on their noses more than once.

It's not about what is faster. It is about how often you make mistakes, statistically. And chances are you make dozens of mistakes per day in C that you will never be aware of, whereas in other memory constrained languages they have hundreds of mechanisms implemented to catch those common mistakes.

Filligree2• 3 years ago

You should allow Rust as well, at least.

Bu9818• 3 years ago

Will libwebp get a new release/tag soon?

jeroenhd5• 3 years ago

If not, this seems to be the patch:

https://chromium.googlesource.com/webm/libwebp.git/+/4619a48...

lifthrasiir17• 3 years ago

The original commit in question: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...

The commit that fixes this bug: https://github.com/webmproject/libwebp/commit/902bc919033134...

The original commit optimizes a Huffman decoder. The decoder uses a well-known optimization: it reads N bits in advance and determines how many bits have to be actually consumed and which symbol should be decoded, or, if it's an N-bit prefix of multiple symbols, which table should be consulted for remaining bits.

The old version did use lookup tables for short symbols, but longer symbols needed a graph traversal. The new version improved this by using an array of lookup tables. Each entry contains (nbits, value) where `nbits` is # bits to be consumed and `value` is normally a symbol, but if `nbits` exceeds N `value` is interpreted as a table index and `nbits` is reinterpreted as the longest code length in that subtree. So each subsequent table should have `2^(nbits - N)` entries (the root table is always fixed to 2^N entries).

The new version calculated the maximum number of entries based on the number of symbols (kTableSize). Of course, the Huffman tree comes from an untrusted source and you can easily imagine the case where `nbits` is very big. VP8 Lossless specifically allows up to 15 bits, so the largest possible table has 2^N + 2^15 entries when every single LUT is mapped to its own secondary table, and doing this doesn't need that many symbols (you only need 16-N symbols for each table). Amusingly enough the code itself had a mode where only the table size is calculated (VP8LBuildHuffmanTable called with `root_table == NULL`), but it wasn't somehow unused and the fixed maximum size was assumed. So if the Huffman tree was crafted in the way that maximizes the number of entries, it will overflow the allocation.

To be fair, I can see why this happened; the Huffman decoding step is one of the most computationally intensive part of many compression format and any small improvement matters. The Huffman decoder optimization described above is well known, but the longer code case is commonly considered less important to optimize because longer code should rarely appear in general. The original commit message refuted this, and was able to be merged. I'm not even sure that a memory safe language could have prevented this; this is a rare case where you actively want to avoid the overflow check [1].

[1] I should note that the memory corruption occurs during the table construction, which is not a tight loop, so a partial overflow check would be very helpful. The actual fix never altered the `ReadSymbol` function at all! But the safety of the tight loop should be still justified, so the wrong justification can ruin everything.

avg_dev2• 3 years ago

Thanks for your explanation.

I’m not a C programmer over the past decade+ and was never very good at it anyway. But I was thinking, based on your description, I agree that a bounds check would have caught the issue, but I’m also curious if an automated test could have been constructed to catch this sort of thing. I personally work with code where you could factor out some calculations to their own function and test them in isolation. Perhaps that would be tough to do here because of performance; I am really not sure.

danielheath• 3 years ago

I’m quite surprised coverage-guided fuzzing didn’t find it almost immediately, to the point that I wonder if it had even been set up.

lifthrasiir17• 3 years ago

I believe it is possible to construct a dedicated automated test, but a normal fuzzing wouldn't be very effective in this case because you need some non-trivial logic to construct a Huffman tree with very large LUT. It's like a condition like phi(input) equals to the specific number [1]; you can construct an input by hand, but fuzzers generally have no idea to approach that. I do think this was found by fuzzing, but it is entirely reasonable that fuzzers took much time to trigger the actual memory corruption.

That said, this particular bug could have been avoided by a careful coding; VP8LBuildHuffmanTable could have received the maximum size of `root_table`, just like snprintf. It still would have needed much time to find but at least it could never be a security bug.

[1] https://math.stackexchange.com/questions/265397/inversion-of...

tialaramex5• 3 years ago

I'm not even sure that a memory safe language could have prevented this; this is a rare case where you actively want to avoid the overflow check.

This component should be written in WUFFS. If you were correct, that the bounds check isn't needed that's fine, WUFFS doesn't emit runtime bounds checks. If, as was the case here, the software is wrong because it has a bounds miss, that won't compile in WUFFS.

You might be thinking, "That's impossible" and if WUFFS was a general purpose programming language you'd be correct. Rice's Theorem, non-trivial semantic properties are Undecidable. Fortunately WUFFS isn't a general purpose language. The vast majority of software can't be written with WUFFS. But you can write image codecs.

lifthrasiir17• 3 years ago

I agree that Wuffs [1] would have been a very good alternative! ...if it can be made more general. AFAIK Wuffs is still very limited, in particular it never allows dynamic allocation. Many formats, including those supported by Wuffs the library, need dynamic allocation, so Wuffs code has to be glued with unverified non-Wuffs code [2]. This approach only works with simpler formats.

[1] https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang...

[2] https://github.com/google/wuffs/blob/main/doc/note/memory-sa...

dvhh4• 3 years ago

Looks pretty interesting, I wonder it the result produced by WUFFS transpiled code could be used as drop-in replacement

Of course the issue with transpiled code ( same for generated code ), is that is making debugging a lot more difficult.

acdha18• 3 years ago

This is why I’m more sympathetic to browser developers being slow to adopt new formats. WebP is a marginal advantage over JPEG (mostly transparency) which hasn’t seen much success but now that’s translated into multiple high-priority security holes and we’re all going to be spending the next month deploying patches everywhere which links against libwebp.

That doesn’t mean we shouldn’t do new things but I think as developers we’re prone to underestimate the cost pretty heavily.

o1y32• 3 years ago

Eh, I think websites adopt webp for their smaller size than anything else.

acdha18• 3 years ago

Yes but you have to pay a LOT in bandwidth for a <10% savings to be worth the cost of supporting an entire extra toolchain and dealing with the support issues (better now but it took a decade not to have “I right-clicked and now I can’t open it” reports from users). Google and Facebook serve that much but most people do not.

dvhh4• 3 years ago

To be fair issues in jpeg decoding libraries also have been used in the past as vector for malware payload. While the webp ecosystem is far less mature, I am pretty sure that "older" format handling would also have its fair share of security issues.

But your reasoning is valid, it seems like a few weeks ago, netizen were arguing that jpeg xl should be adopted as fast as possible, and for that to be possible the browser developer "only needed to include the reference decoder code into their codebase" at "very little cost".

lifthrasiir17• 3 years ago

netizen were arguing that jpeg xl should be adopted as fast as possible, and for that to be possible the browser developer "only needed to include the reference decoder code into their codebase" at "very little cost".

Because otherwise AVIF should not have made into the codebase. High-profile C/C++ projects can't prevent all security bugs, but they can make them easier to find and harder to get in. AVIF and JPEG XL roughly have the same impact in this regard (written in C++, uses Google's standard convention, tested and fuzzed regularly, and so on).

acdha18• 3 years ago

To be clear, I’m not saying we shouldn’t add new formats - more that it’s one of those “take the developer’s estimates for how long it’ll take and double them, and then put a zero on the end” situations. I’m not sure WebP was worth it but AVIF definitely is and both of them do have one advantage over other formats if they can share code with VP8 and AV1, respectively, since browsers were definitely going to ship those.

What I wonder is whether this is saying there should be two tiers, where stuff like JPEG XL might be implemented in WASM for better sandboxing so browsers could more easily add support with less security risk and then possibly “promote” it to a core format if it proves successful and there’s enough performance win.

frankjr3• 3 years ago

But would have been these bugs discovered if the browsers had not adopted the new format? There are many other image formats and their libraries which are most likely riddled with bugs, but nobody cares because they are not used by major software (certainly not the people capable of finding and exploiting these bugs because of poor time reward ratio). Being unused for longer wouldn't make them any less buggy.

_ache_2• 3 years ago

I can confirm that. I talked about it in my last blog post.

janc_2• 3 years ago

This vulnerability was found in Apple's ImageIO library as used in their iMessage application on iOS...

https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

circuit10• 3 years ago

Firefox has a nice solution which gives an extra layer of sandboxing which can be applied to individual libraries rather than a whole process: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

acdha18• 3 years ago

Yes - not saying it’s impossible to improve or that we shouldn’t add new things to the web platform, only that it always costs more than we anticipate.

One example: that’s great for Firefox but that helps a format become more common, which increases the likelihood of tools integrating a library but not using a browser-grade sandbox. How many apps end up passing user uploads through something like ImageMagick, for example? (And how many years will it be before the last container image is updated?)

keepamovin3• 3 years ago

Agree. This is one of the reasons it's better to go with older and more reliable JPEG for viewport streaming. An exploit chain would need to penetrate screen capture images to pass to the client. Browser zero days do occur and this is why it's important to have protection. For added protection people often use browser isolation, which specifically adds another layer of protection against such zero days.

If you're interested in an open source (AGPL-3.0) solution for zero trust browser isolation check out BrowserBox on GitHub. We are using JPEG (now WebP) for viewport pixels: https://github.com/dosyago/BrowserBoxPro

Technically, we did try using WebP due to its significant bandwidth gains. However, the compute overhead for encoding versus JPEG introduced unacceptable latency into our streaming pipeline, so for now, we're still against it. Security is an additional mark against the newer standard, as good as it is!

saagarjha9• 3 years ago

“JPEG is more secure than WebP” is the wrong takeaway here.

eviks2• 3 years ago

So that slowness has bought nothing? You have bad format with exploits in the wild while using that as an excuse to gate great format. (which the browsers could "slowly" RIIR instead to address the safety issue directly)

acdha18• 3 years ago

I don’t follow your argument - can you clarify?

blurbleblurble• 3 years ago

It's much better from my experience.

acdha18• 3 years ago

I mean, transparency is nice but I think it is reasonable to ask how much value a format will add relative to the cost & risk. WebP has already peaked but for compatibility it’ll need to be supported for decades to come.

userbinator• 3 years ago

It's also a far more complex format than JPEG, and complexity almost directly correlates with defect density.

That said, I also blame the culture of making code more complex than necessary, along with developers who barely understand the details.

miohtama4• 3 years ago

The security holes are caused by C/C++ being unsafe language to develop with, not new image formats. If image, and other, encoders and decoders do not use unsafe languages, it’s unlikely they introduce any such bugs.

acdha18• 3 years ago

That would definitely help, but it doesn’t eliminate the problem entirely (consider for example the attacks on hardware accelerators). I do think that’d be a good policy: new codecs have to be written in Rust or run in WASM.

SanderNL• 3 years ago

It would be cool if an app could use an user-provided “codecs” for all sort of common (media) things. That way I can determine an acceptable risk myself customized for my circumstances.

Maybe I’ll use an open, safe but feature incomplete webp implementation because I don’t care if three pixes are missing or the colors are not quite correct. Maybe I’ll provide a NULL renderer because I just don’t care.

I know this sounds stupid, but a man can wonder.

niutech2• 3 years ago

You can use WASM for image codecs, like my JPEG XL decoder: https://github.com/niutech/jxl.js

There is also WebCodecs API: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

saagarjha9• 3 years ago

Did you know the path for decoding JPEGs on Apple hardware goes through the kernel?

lost_tourist2• 3 years ago

Do you have a reference for this? that seems like a huge security issue with 0 benefit since decoding can be done easily in userland.

acdha18• 3 years ago

You mean AppleJPEGDriver? Yes, but I'm pretty sure I learned about that from one of your older comments.

lost_tourist2• 3 years ago

it also has lossless capability as well, that's a big one to me, it can replace png and jpeg for 99% of use cases.

acdha18• 3 years ago

Yeah, I'm not saying it has _no_ value but I don't think it's enough so to be compelling - it's widespread enough that we're probably going to be supporting it for the next few decades but the time where it had an advantage will be what, half a decade?

badrabbit• 3 years ago

Is there a realistic path to exploiting this? From what I hear, heap-spraying on 64bit is no longer practical. Is there a predictable object in memory that could be overwritten?

insanitybit11• 3 years ago

It's being exploited in the wild, so yes. Heap Spraying is definitely still a thing for kernel exploitation on 64bit, idk about the primitives people use for v8 exploitation.

gardaani• 3 years ago

This is a vulnerability in the WebP library, so this isn't only about Chrome. Which software is affected by this?

- Android apps?

- Cross-platform Flutter apps?

- Electron apps?

- Microsoft Edge and Brave (and all other Chromium based web browsers)?

- Signal and Telegram displaying WebP stickers?

- Which image editors are affected? Affinity tools, Gimp and Inkscape seem to use libwebp.

- LibreOffice displaying WebP images?

- server software such as WordPress (does it decode images to re-encode them?)?

Apple devices were also affected, but they already got a fix.

Anything else?

duringmath• 3 years ago

Firefox?

Android WebView got patched so there's that.

internetter3• 3 years ago

Firefox?

Yup. https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

nlitened• 3 years ago

Have only the recent Android phones been patched, or also 3—4+ year old phones as well?

internetter3• 3 years ago

log4j again?

miohtama4• 3 years ago

WebP is an image format so it is likely a buffer overflow.

So C/C++ again.

smith7018• 3 years ago

I mean, it would most likely affect any software that uses libwebp. Taking a quick look at Arch's libwebp page:

* allegro

* emacs (lmao)

* ffmpeg

* freeimage

* gd (required for gnuplot, fceux, graphviz, etc)

* godot

* openimageio

* qt5/6-imageformats

* sdl2_image

* thunderbird

* webkit2gtk

* etc

optionally:

* gdal

* imagemagick

* python-pillow

* python-piexif

* etc

Should note that a vuln doesn't mean an exploit, of course.

vohu43• 3 years ago

This does really not sound good

est312• 3 years ago

FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image

It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?

insanitybit11• 3 years ago

If Chrome had a flag for "use the safe versions of XYZ libraries, even if they might be slower" I would absolutely flip that switch and take the performance hit.

Lt_Riza_Hawkeye• 3 years ago

Right, but for most users, Chrome's differentiator is that it's fast. I can't imagine them flipping the flag on by default - and if 99.99% of users aren't going to use it, it's probably not worth it to bloat the binary size either. Maybe someone will make a chromium patch with it that people can keep rebasing, though

NelsonMinar• 3 years ago

It's crazy to me in 2023 we're still writing new C/C++ code for something with as enormous an attack surface as a web browser.

PaulHoule• 3 years ago

There is a long history of vulnerabilities in image codecs. The actual image processing is nice linear code you could write in memory-safe FORTRAN IV but compression means you have a lot of variable length data structures, pointer chasing, etc... And the pressure to make it run fast.

hollerith2• 3 years ago

It's nice that Google identified this security hole, but I suspect that Google is also the main reason for its existence in the first place: if Google didn't want to reduce by a few percent its costs for serving images, there probably would be no widespread usage of the WebP format.

(Similarly, it is nice that Google finds so many bugs in Javascript engines, but on the other hand they were one of the the main proponents of the bad idea of turning every web page into an executable program in the first place.)

ADDED. OK I was unfair in my guessing as to Google's motivation: the main motivation seems to have been to speed up page loading across the web.

akmittal2• 3 years ago

How is every webpage executable?

hollerith2• 3 years ago

In order to reliably view the web pages I visit, I must be prepared to execute Javascript or more precisely employ a browser to do it for me.

The web was not always that way.

kccqzy• 3 years ago

Read some history, friend. People wanted to turn web pages into executable programs even before Google existed. Have you heard of Java applets (Sun)? Have you heard of the beginnings of JavaScript (Netscape)? Have you heard of VBScript (Microsoft)?

This is inevitable. Even if none of the aforementioned companies did it, some other company will.

Bluecobra• 3 years ago

The network is the computer!

:barf:

nocsi2• 3 years ago

And people wonder why the pentagon enforced user to run browsers in a VM or print out websites to read as flattened pdfs

mdaniel• 3 years ago

Heh, ah yes, pdf: the MOST sekure file format :-D

But seriously, depending on the attack vector in mind, using those "browser over VNC" technologies may address a lot of that risk if the objective is to read content without risking the local workstation running arbitrary code

_ache_2• 3 years ago

The WeBP and WeBP2 lib are a lot more tested than others format. I tried the official jxl lib and the heic tools, and I was able to identify bugs among these tools.

I'm pretty sure that you can find a buffer overflow in these decoders.

pornel• 3 years ago

WebP2 is highly experimental, so don't count on it being safe.

libwebp is relatively simple and clean C code, and has been around for over a decade. There are definitely scarier codec implementations than this.

Chrome: Heap buffer overflow in WebP

Related Stories