[HN Gopher] The WebP 0day
___________________________________________________________________
The WebP 0day
Author : benhawkes
Score : 368 points
Date : 2023-09-21 17:21 UTC (1 days ago)
(HTM) web link (blog.isosceles.com)
(TXT) w3m dump (blog.isosceles.com)
| pja wrote:
| So if your Android device is out of support, there's now a
| 0-click exploit floating about in the wild?
|
| Or will updating the SMS App, Chrome, WhatsApp, Signal etc be
| sufficient to cover all the likely input routes?
| modeless wrote:
| The platform image decoding libraries really ought to be one of
| the system modules that are updated through the Play Store, can
| anyone confirm whether they are or not?
| johnfernow wrote:
| I certainly hope it is, but even still Project Mainline only
| came out with Android 10, and as of May 30, 2023, 27.8% of
| Android users are on Android 9 or lower, according to
| Google's stats listed in Android Studio. [1]
|
| Considering there are over 3 billion active Android users
| according to Google [2], that's at least 834 million people
| who are potentially vulnerable to this exploit that will
| likely never receive a patch. That's awful enough by itself,
| but particularly terrible since the exploit could be as
| simple as having someone view an image. Chrome may be fixed,
| but there are over 2 billion WhatsApp users. [3]
|
| 1. https://www.androidauthority.com/wp-
| content/uploads/2023/06/...
|
| 2. https://www.theverge.com/2021/5/18/22440813/android-
| devices-...
|
| 3. https://about.fb.com/news/2020/02/two-billion-users/
| pja wrote:
| https://android-
| developers.googleblog.com/2020/02/Android-11... says:
|
| "Native image decoder - New NDK APIs let apps decode and
| encode images (such as JPEG, PNG, WebP) from native code
| for graphics or post processing, while retaining a smaller
| APK size since you don't need to bundle an external
| library. The native decoder also takes advantage of
| Android's process for ongoing platform security updates.
| See the NDK sample code for examples."
|
| However, poking about in the Android mainline module docs I
| can find no evidence that the image decoder libraries are
| included in the system updates that get pushed through
| Google Play. I've unpacked the obvious modules & found the
| video codecs, but no sign whatsoever of the image decoder
| libraries,
|
| It would be helpful to be able to tell whether a given
| phone has received such an update, especially in the case
| of 0-click exploits like this one! Are all Android 11+
| phones guaranteed to receive it? (it would seem so, if this
| is a core security component) Is there anyway to tell
| whether you've received it? This aspect of Android updates
| seems to be entirely opaque to the end user - updates get
| pushed through Google Play services & that's it.
|
| After some investigation, I found
| https://support.google.com/product-
| documentation/answer/1141...
|
| which gives some details of Android system updates pushed
| through Google Play. This changelog does not list CVEs or
| specific bugfixes, so it's impossible to tell which bugs
| have been closed via this route, but it is at least
| slightly better than nothing at all.
|
| It is possible to map those updates to actual CVEs
| mentioned in the AOSP sources via a circuitous route
| involving adb & running a bunch of commands on your phone,
| according to this blog post:
| https://www.esper.io/blog/building-a-google-play-system-
| upda...
|
| Looking at the current AOSP wepb sources, no module tags
| have been attached to the current release, so it doesn't
| look like it's been pushed out yet, if it's possible for
| Google to do so at all outside the monthly security updates
| for in-support phones.
| Aachen wrote:
| I'd really rather it was possible for _me_ to update
| vulnerable image decoding libraries than having to install a
| Play service and give it root access to do that for me
| tamimio wrote:
| If your android is out of security updates, this won't be the
| only thing to worry about, I would probably worry about the
| easier to exploit ones first.
| pja wrote:
| Yes, and Google should be supporting these old devices as far
| as possible.
|
| Not doing so is a disservice to their customers frankly.
| tamimio wrote:
| Agreed, I found infuriating that after 2ish years your
| android is no longer secure and you are on your own, and
| you have two options here, throw it away and get a new one
| that will be thrown away soon, or go in the efforts to find
| a hacky way to install a custom ROM that hopefully the
| maintainers will keep it secure. It's that reason why I
| switched to iOS years ago.
| pja wrote:
| It seems that GrapheneOS is making releases for Pixel
| phones, including the 4a which include patches for the
| webp exploit: https://grapheneos.org/releases#2023091800
| x0x0 wrote:
| Just buy Apple hardware.
|
| They're currently bugging me about updating a 9 year old
| ipad I just use as a kindle. They flatly blow Google away
| on device updates, and will continue to do so even if
| Google isn't lying about their new / supposed 5 year update
| plan (and NB: that's 5 years from the release date, not 5
| years from the last sale date, which could be reasonable.)
| sprokolopolis wrote:
| Some messaging apps have options to not automatically
| download/preview images that are sent, so that might be a good
| step to take. I know that Google Messages has this feature.
| lern_too_spel wrote:
| It's an especially big problem on iOS because iMessage has
| elevated permissions. On Android, all of those apps are
| sandboxed.
| saagarjha wrote:
| iMessage is a sandboxed app.
| olliej wrote:
| iMessage is sandboxed, and does attachment processing in yet
| another sandbox (the exploit is named BLASTpass as it
| circumvents this). These days iMessage itself is probably
| more tightly sandboxed than other apps.
|
| It sounds like the exploit was triggered in another process
| by iMessage forwarding the post-parse attachment content to
| that process - the blog post says this is passkit related so
| I assume any app that has passkit interaction could do this.
| iMessage is simply universally available so why use a
| different medium.
| benhawkes wrote:
| Well, we don't know for sure that an exploit exists for this
| bug on Android yet (the original exploit was for iOS via
| iMessage), but there's a reasonably high chance that one has
| been developed already. These types of exploits are in very
| high demand for Android right now, I've heard some eye-watering
| prices being mentioned recently.
|
| Updating Chrome on an unsupported device would fix the issue,
| but you would still need an Android OS upgrade to fix the issue
| for apps like Signal and WhatsApp. Chrome bundles its own
| version of libwebp, but messaging apps and other highly exposed
| stuff like Gmail all use the OS provided interfaces for
| displaying images. Hopefully we'll start getting updates for
| security-supported Android devices in early October.
| ocdtrekkie wrote:
| I have iOS devices from 2015 that still get security updates
| and already patched for this issue. It's really just straight
| up irresponsible at this point that Android can't actually do
| this.
| kristopolous wrote:
| Can you give me a real number on that? Are we talking over a
| million? Over 5?
| 0x53 wrote:
| The only publicly posted price list that I know of is
| zerodium's (evil people). http://zerodium.com/program.html
| They currently offer 2.5 million for an android zero click
| with persistence. This doesn't give you the persistence
| piece without another bug so maybe 2m. Of course, they are
| only willing to offer that price if they could sell it for
| much more.
| tamimio wrote:
| > Well, we don't know for sure that an exploit exists for
| this bug on Android yet
|
| If the target is an Android, definitely an advanced exploit
| like this isn't needed, so even if it will work, an easier
| ones most likely to be used.
| TheGuyWhoCodes wrote:
| This is honestly pretty bad. You either wait a month (or
| more) for the OS security update, if you are lucky enough
| that your device is supported.
|
| Or the app could bundle the library, they can push updates
| faster but then again they could just use an old version and
| never update like most 3rd party dependencies these days.
| TheHappyOddish wrote:
| This is the primary reason why I push the the non
| technically inclined (grandparents, older friends, etc) in
| my life to use iPhones. The latest Pixel I believe is now
| offering 6 years security patched (which makes it an
| Android leader), but 7+ years is already the standard on
| the cheapest iPhone option.
|
| The argument of a $1000 Androd phone vs a $1500 iPhone
| falls over if you have to replace that Android phone 2 more
| times in the same period.
| pja wrote:
| So there's a webp system library as well as the one in
| Chrome?
|
| Nice of Google to drop security support for the Pixel 4a just
| before this bug drops.
| vuln wrote:
| You're saying that Google knew about the bug and purposely
| dropped security support for the pixel 4a right before?
| Support didn't age out, like it typically does (age of
| device)? Google just pulled security support for this one
| device?
| pja wrote:
| No, I'm saying it's extremely frustrating that Google
| just drops security support entirely for devices like
| this, when they could continue to at least patch
| egregious platform bugs like this one, even if they can't
| fix everything.
|
| It's just icing on the proverbial cake that a month after
| they drop security support for the 4a a 0-click remote
| exploit is found.
| callalex wrote:
| The gigantic "Subscribe" button on this page is infuriating and
| highly distracting. It effectively covers 1/3 to 1/2 of the page
| if you scroll once a paragraph like me and many others.
| [deleted]
| pvg wrote:
| Couple of interesting things in the post that aren't about 'what
| to patch now'
|
| It can be quite a bit of work to recreate a POC of the exploit
| even knowing the location _and the fix_.
|
| A lossless decompressor in an image decoder can be quite fuzzing
| resistant.
|
| Maybe obvious to security people but fun to read about as a
| muggle.
| matthewdgreen wrote:
| The answer to this stuff isn't to fuzz, it's to cut this code
| out like it's a tumor. Then if it breaks stuff throughout the
| OS/browser, write _one_ heavily sandboxed and memory-safe
| format converter that can handle the problem. I 'd rather have
| an iPhone or browser that is annoying in a few edge cases than
| have code like this where vulnerabilities are almost guaranteed
| (irrespective of fuzzing.) I know I'm being optimistic here,
| but I'm positive this won't the last chapter in this story.
| lifthrasiir wrote:
| To me, this bug is most similar to the Timsort bug back in 2015
| [1].
|
| Timsort is an ingenious hybrid sorting algorithm originated from
| CPython and many implementations including OpenJDK adopted it
| mostly via a source-by-source translation. Timsort particularly
| maintains a stack of sorted runs, and due to the construction
| there is a small enough finite limit in the maximum possible
| stack size. However the original CPython implementation didn't
| exactly match what was proven, so there were rare cases where
| stack overflow could happen. So this was a serious security bug
| in CPython, but wasn't in OpenJDK because Java instead threw an
| exception in that case.
|
| Similarly, this WebP bug occurred because the largest table size
| was formally proven but it didn't match what was fed to the
| source code. This kind of bugs is not only hard to verify but
| also hard to review, because of course there is a proof and the
| source code seems to match the proof, so it should be okay! This
| bug suggests strong needs for approachable formal verification,
| including the use of memory-safe languages (type systems can be
| regarded as a weak form of formal verification), not human
| reviews.
|
| [1] http://envisage-project.eu/wp-
| content/uploads/2015/02/sortin...
| tialaramex wrote:
| Specifically, since performance is crucial for this type of
| work, it should be written in WUFFS. WUFFS doesn't emit bounds
| checks (as Java does and as Rust would where it's unclear why
| something should be in bounds at runtime) it just rejects
| programs where it can't see why the indexes are in-bounds.
|
| https://github.com/google/wuffs
|
| You _can_ explicitly write the same checks and meet this
| requirement, but chances are since you believe you 're
| producing a high performance piece of software which doesn't
| need checks you'll instead be pulled up by the fact the WUFFS
| tooling won't accept your code and discover you got it wrong.
|
| This is weaker than full blown formal verification, but not for
| the purpose we care about in program safety, thus a big
| improvement on humans writing LGTM.
| nigeltao wrote:
| Wuffs author here.
|
| It's not full-blown formal verification but it doesn't have
| to be. Unlike most formal verification projects that I've
| seen, the proof part of Wuffs isn't about _correctness_
| (proving that "this implementation satisfies the PNG
| specification"), it's about _safety_ (proving that "this
| implementation won't read/write out of bounds"), which is
| much more tractable. Especially as the PNG spec (or WebP
| spec) doesn't mandate how to treat malicious input (like
| unbalanced Huffman tables).
|
| Wuffs doesn't have a WebP decoder yet but it's literally in
| the Roadmap and I've previously written the
| golang.org/x/image/webp package in the Go programming
| language.
|
| Wuffs does have a PNG decoder, PNG uses Deflate compression
| and Deflate and WebP's "decode a Huffman tree" data tables
| are very similar. Wuffs also has an equivalent of zlib's
| enough.c program mentioned in the original blog post to
| calculate worst-case memory requirements. Wuffs' version is
| called script/print-deflate-huff-table-size.go and it says
| that, for a 9-bit primary table, we need 852 table entries.
| Round that up to 1024, for nearest power-of-two.
|
| If you look for HUFFS_TABLE_SIZE = 1024 and HUFFS_TABLE_MASK
| = 1023 in Wuffs' std/deflate source code, you'll notice that
| Wuffs' Deflate decoder isn't susceptible to the same problem
| as the C/C++ WebP decoder the original blog post discussed.
| This is because, unless the Wuffs compiler can prove
| otherwise, the code doesn't just look up the table like
| `this.huffs[0][i]`, it's like `this.huffs[0][i&mask]` and
| `i&mask` is _always_ in bounds. The mask is either
| HUFFS_TABLE_MASK or it 's of a _refinement type_ guaranteed
| <= 511. The array is always (statically) allocated with 1024
| entries even though enough.c says that, with dynamic
| allocation, we could possibly get away with a smaller table.
|
| As you already know, for Wuffs (and unlike C/C++), taking out
| the `&mask` will lead to a compile-time error. Wuffs code
| won't compile unless the compiler can prove that array
| indexes are always within bounds.
|
| From the grandparent:
|
| > this WebP bug occurred because the largest table size was
| formally proven but it didn't match what was fed to the
| source code
|
| With WebP+enough.c this 'largest table size' was calculated
| by exhaustive, brute-force search (not really a formal proof)
| but it was based on assumptions (balanced codes) that didn't
| match actual (malicious) input. Or, in zlib-the-library,
| there's other C code (https://github.com/madler/zlib/blob/ac8
| f12c97d1afd9bafa9c710...) that rejects unbalanced Huffman
| codes, but IIUC similar enforcement was (until very recently)
| missing in libwebp.
|
| With Wuffs, even if the worst-case calculation was based on
| an incorrect model (or forgetting to separately reject
| unbalanced codes), the end result (on malicious input) might
| be "the wrong pixels" but it shouldn't be "buffer overflow".
| Ono-Sendai wrote:
| That's a neat trick with the index masking. I will have to
| try using Wuffs again.
| tialaramex wrote:
| Hi Nigel, Thanks for interjecting (and of course Thanks for
| WUFFS). I'm glad to hear that WebP is "on the Roadmap" but
| I think this sort of work ought to have been considered by
| vendors as a must-have, high priority project, rather than
| being sort of vaguely welcomed sideshow that's not on their
| critical path.
|
| Yes, I actually think that the choice to unequivocally
| prove safety rather than to attempt to prove that you
| implemented something specific (but with the risk that our
| specification is wrong), is almost invariably the right
| choice _for this problem space_. It would not have been
| appropriate for the TLS 1.3 protocol (which has a machine
| proof that it satisfies our intended criteria stated in the
| RFC, modulo the Selfie attack and assuming our
| cryptographic primitives all do what they said they do),
| but it 's exactly the right thing for say a DOCX parser, or
| ZIP parser, or a JPEG compressor or similar for which WUFFS
| is the right choice.
| lifthrasiir wrote:
| > With WebP+enough.c this 'largest table size' was
| calculated by exhaustive, brute-force search (not really a
| formal proof) but it was based on assumptions (balanced
| codes) that didn't match actual (malicious) input.
|
| Maybe I'm stretching the definition, but the exhaustive
| search is also a proof, especially when it can be done
| quickly or an efficient proof certificate can be generated
| (enough.c is the former). I even think that enough.c can be
| modified to generate a reasonably sized trace to aid
| verification.
| nigeltao wrote:
| As an intellectual 'puzzle', I'd be curious to see what
| that sort of trace-guided verification could look like,
| if that's even feasible. My recollection of enough.c is
| that, algorithmically, it's sufficiently complicated that
| I need to really think hard when I'm reading the code.
| But also, it uses clever data structures specifically to
| reduce the memory requirements at runtime.
|
| In comparison, "array size is always 1024, array index is
| always bitwise-anded with 1023, therefore always in-
| bounds" is undeniably simple and, per "The Fastest,
| Safest PNG Decoder in the World", practical and fast.
| lifthrasiir wrote:
| While I agree that you don't need the tight bound
| (especially because I think the tight bound for
| _incomplete_ trees is not much higher than one for
| complete trees), you do need to be confident that 1024 is
| either a loose but correct bound or highly unlikely to be
| reached in practice. So you need to calculate some kind
| of bounds anyway... And this is another reason I thought
| something more than Wuffs is desirable [1]; a dynamic
| memory allocation, when allowed, makes many things easier
| to implement _and_ prove.
|
| [1] https://news.ycombinator.com/item?id=37480019
| nigeltao wrote:
| 1024 _is_ a loose but correct bound. That 's what
| enough.c (or script/print-deflate-huff-table-size.go)
| says.
|
| Stepping back, I'm not sure if I understand what you're
| saying. Perhaps we're just disagreeing on how "formal"
| (as in, part of a "formal verification" process) the
| enough.c program (or equivalent) needs to be?
|
| ---
|
| As for dynamic memory allocation, Wuffs has a mechanism
| for the callee (Wuffs code) to tell the caller (C/C++
| glue code) that it needs N bytes of "scratch space" or
| "work buffer", where N is dynamically dependent (e.g.
| dependent on the image dimensions in pixels).
|
| It's not "dynamic memory allocation" in that Wuffs still
| doesn't malloc/new and free/delete per se. But it is
| dynamically (run time, not compile time) sized.
|
| Grepping for "work buffer" or "workbuf" in Wuffs'
| example/ or std/ code (or SkWuffsCodec.cpp) should give
| some leads, if you want to study some code. The
| workbuf_len is often zero but, for Wuffs' std/jpeg and
| std/png, it is positive. Manage the work buffer in the
| same way as the pixel buffer: it's always caller-owned
| and callee-borrowed.
| tkot wrote:
| Slightly off-topic but I can't resist the urge to ask.
|
| Why is the logo (https://raw.githubusercontent.com/google/w
| uffs/main/doc/logo...) no longer shown in the readme?
|
| I was pretty sure I had heard of the project before but I
| had to find the logo to be absolutely certain, it's truly
| one of a kind.
| nigeltao wrote:
| The logo is no longer shown because I think the tweet-
| screenshot is a more compelling introduction for people
| new to Wuffs.
| lifthrasiir wrote:
| Yeah, Wuffs can be classified as memory-safe languages in
| this case and should be endorsed as much as possible. I mean,
| I said a lot about the limitation of Wuffs in the last
| conversation, but that's because I believe _something like_
| Wuffs should be used more widely, and the current limitation
| of Wuffs can hinder the progress. We need several angles of
| attack to make it real, and Wuffs is only one of them.
| 3abiton wrote:
| TIL Stack Overflow is not just the name of a website.
| defrost wrote:
| If that's a serious TIL then you _might_ enjoy the Ye Olde
| Timey classic
|
| _Smashing The Stack For Fun And Profit_ (1996)
|
| (OG Phrack link) http://phrack.org/issues/49/14.html (Text-
| zine)
|
| (TISM Berkeley CS coursework) https://inst.eecs.berkeley.edu/
| ~cs161/fa08/papers/stack_smas... (PDF)
| tedunangst wrote:
| But unrelated to the stack overflow in Tim sort.
| defrost wrote:
| Not entirely - I wrote _a lot_ of numerical backend code
| intended for 24 /7/365 continuous use in the face of
| potentially _any_ input .. aquisition | instrumentation
| equipment failures can produce glitch inputs just as
| damaging as delibrately crafted malicious inputs from a
| hacker reverse engineering existing code.
|
| The common ground being code that has to be robust in the
| face of _any_ input has to be (correctly!) verified,
| constrained within hard resource limits, have graceful
| fail over behaviour, some measure of sanity checking,
| etc.
|
| Otherwise, if an e\/il hax0r doesn't get you .. mother
| nature and sheer bloody chance will.
| seabass-labrax wrote:
| I would really recommend trying to write a little C program
| that deliberately causes a stack overflow. It is completely
| harmless and is good fun if you've never encountered this
| kind of low-level systems code before.
|
| It's also pretty fun to try asking for weird amounts of
| memory with 'malloc' or seeing how many times you can ask the
| OS for no memory before something fails. You might need to
| force-reboot your computer after that though!
| SubzeroCarnage wrote:
| re Android:
|
| My DivestOS 14.1 (A7) through 19.1 (A12) has this patched, and
| 20.0 (A13) is currently compiling:
| https://divestos.org/pages/news#2023-09.2
|
| GrapheneOS shipped it: https://grapheneos.org/releases#2023091800
|
| CalyxOS has it staged for next update:
| https://review.calyxos.org/c/CalyxOS/platform_external_webp/...
|
| LineageOS 18.1+ also pulled it in:
| https://review.lineageos.org/q/topic:%22CVE-2023-4863%22
|
| Additionally all of the above have shipped Chromium 117.0.5938.60
| which contained the same fix as well:
| https://divestos.org/misc/ch-dates.txt
| [deleted]
| est wrote:
| Why can't modern software pack with more "modules"? e.g. Just
| upgrade a webp.dll and we're set.
| NavinF wrote:
| That's how most linux distros work, but it also leads to nasty
| diamond dependency problems
| hughw wrote:
| To what extent did the source code enable NSO to find this bug?
| Had the code been blob-only, would modern decompilers have worked
| well enough to help them understand the code and find this
| obscure bug?
| pornel wrote:
| A blob would not stop the attackers. To write a successful
| exploit they need to understand the compiled binary anyway.
| johnklos wrote:
| Funny, because for ages I was running macOS on a 2011 MacBook Pro
| which had a version of Safari that was so old it didn't support
| webp. At the same time, my Amiga 3000 running AmigaDOS 3.2.2
| could support webp by virtue of an operating system-wide datatype
| plugin for webp.
|
| Updating the OS-wide datatype means all apps are updated, not
| just the browser. Why is this STILL not the case on supposedly
| modern OSes these days?
| arp242 wrote:
| I don't really _want_ this to be the case. Remember when
| Firefox accidentally exposed all gstreamer plugins to the web?
|
| Having some insecure unaudited badly written codec is fine for
| a lot of use cases because it operates on trusted data. But
| this is of course quite a different situation than being
| exposed to all webpages you visit.
|
| The Amiga 3000 lived in a different world with a different
| internet.
| [deleted]
| chatmasta wrote:
| FYI, you can install Safari Technology Preview (and Safari
| Beta) as a standalone app, without upgrading the entire OS:
| https://developer.apple.com/safari/technology-preview/
| kalleboo wrote:
| IIRC, in the early days Safari _would_ pass off any image type
| to the OS, but after some TIFF vulnerability they whitelisted
| it to supported "web" formats.
|
| They also used to let you just embed a Quartz Composer file
| which let you do some "fun" stuff with the webcam that would
| terrify users.
| pornel wrote:
| The reason is most likely security and stability. OS vendors
| don't want every application to be potentially vulnerable or
| unstable, because user installed some dubious codec pack.
|
| One place where macOS allows arbitrary codecs is Quicklook
| plugins, but these are designed to run in a separate process.
| It'd be wise to implement image codecs the same way, but so far
| they're typically a library linked in the same process.
| callalex wrote:
| Especially infuriating because MacOS has the brilliant generic
| file viewing framework that they brand as Quick Look Plugins
| (QLPlugin). The name comes from where the feature started
| (pressing spacebar in the file viewer to ostensibly view
| literally any file) but it is used all over the place in Mac
| and iOS software.
| Macha wrote:
| It feels like this bug has only really flown down under the radar
| because the discoverers are not in the habit of giving bugs names
| and landing pages. Both because of level of access (remote code
| execution), the vector (image rendering, often done with
| untrusted data) and the widespread nature of the affected
| library.
| jandrese wrote:
| BLASTPASS is an ok exploit name, but it is kinda specific.
| People might think it was only about bypassing BlastDoor on
| iPhones. A better name might have been something like "WebPwn",
| which would have made it much more clear that it was a
| vulnerability in the image format.
| AdmiralAsshat wrote:
| "BLASTPASS" made me initially think it was the exploit used
| to breach LastPass.
| olliej wrote:
| WebPwn is a great name and I almost want a direct RCE in WebP
| just so it can get that name
| halJordan wrote:
| Blastpass is the exploit that broke open Blastdoor. The webp
| exploit is just a neat privilege escalation after you
| blastdoor'd the target.
| jsnell wrote:
| Did it really fly under the radar? It was widely reported in
| the mainstream media. There were at least two "top of HN
| frontpage" submissions on it.
|
| https://news.ycombinator.com/item?id=37425007
|
| https://news.ycombinator.com/item?id=37478403
| Macha wrote:
| Compared to the likes of log4shell, shellshock or heartbleed,
| yes. It feels like the immediately exploit possibility of it
| is arguably more than heartbleed, but I don't see every
| security person chasing after it in the same way.
|
| I've been following the progress of some of the fixes in apps
| I use and it's meandering through intermediates at an urgency
| that is more akin to the ssh 9.1p1 vulnerability which
| required peopel to ssh into an affected server.
| pvg wrote:
| It's nothing close to heartbleed which was 'extract key
| material from every TLS-serving endpoint in the universe'.
| There are almost certainly exploitable buffer overflows in
| whatever device you're using right now.
| mmsc wrote:
| I would argue that it has flown under the radar because it
| has only been contextualized with respect to Chrome and iOS.
| The issue has and continues to affect many other critical
| places, including server-side image processing services.
| [deleted]
| not2b wrote:
| Ubuntu and Fedora have put out security updates for libwebp, so
| any program that uses the shared library to access WEBP images is
| safe, once security updates are applied. Not sure about other
| Linux distros, but I expect that almost everyone has dealt with
| this. Unfortunately, snap and flatpak applications are a problem;
| it's hard to tell which ones might have a bundled, vulnerable
| WEBP decoder linked in.
| [deleted]
| [deleted]
| ComputerGuru wrote:
| Not really "any" program but those that don't ship their own
| version and didn't statically link against libwebp (if that's
| an option?). Notably, browsers often don't use the system
| version of the library. That's not the end of the world since
| browser vendors are on top of the security game for the most
| part - but the million Electron apps you might be running also
| each need to be updated individually!
|
| Basically, don't rest easy and get complacent. Updating the OS
| distros is not enough.
| freitzkriesler2 wrote:
| Ah webp, let me count the ways I hate thee...
| Jigsy wrote:
| I don't get the praise for webp either. Out of images I see,
| jpg has better details preserved than webp.
| freitzkriesler2 wrote:
| It's an annoying format that Google made that's proprietary
| and reinvents the wheel.
|
| Had Microsoft done this the tech world would be up in arms.
| When Google does it, it's OK.
|
| I have to add extensions to convert this crap when I want to
| download images. I hope that Google loses their dominance to
| Microsoft with AI.
| halJordan wrote:
| But you don't have to add extensions to convert this crap.
| You do that to yourself. If you quit making your life hard
| it would be so much easier, but probably less complaining-
| so i guess that's the trade off.
| tedunangst wrote:
| You do have to handle it though, and rarely when you want
| to. You click on a jpg link in your browser and save it,
| but the CDN invisibly converted it to webp. Which the
| program you want to edit the image in doesn't support. I
| didn't ask for webp. I didn't try to make this difficult.
| NavinF wrote:
| All modern image editors support webp
| taway1237 wrote:
| Certainly not all, as the ones I'm using don't. Unless
| you have a very cherry-picked definition of "modern".
| madars wrote:
| webp is not proprietary. There is a patent grant
| https://groups.google.com/a/webmproject.org/g/webp-
| discuss/c... and reference implementation is BSD-licensed.
| nayuki wrote:
| You might be interested that Microsoft developed JPEG XR:
| https://en.wikipedia.org/wiki/JPEG_XR ,
| https://www.microsoft.com/en-us/research/project/jpeg-xr/ .
|
| And in the past, they tried to shove Windows Media Video
| and Audio down our throats, which are inferior relatives of
| MPEG-4, AAC, FLAC, etc.
| dchest wrote:
| The lossless format (where this bug's in) achieves amazing
| compression rates, compared to PNG.
| not2b wrote:
| Yes, the main benefit of WEBP is for lossless compression,
| it's reported to be about 25% better, though this would
| depend on the image. For lossy, there's no reason I can see
| to prefer it over JPEG.
| edflsafoiewq wrote:
| The lossy format has alpha support, unlike JPEG.
| [deleted]
| keyle wrote:
| Millions of people in the world are affected by this library, 10
| times over for every devices and apps they use.
|
| I'm sorry but I call for libraries used by millions around the
| world to NOT use C. And I love C... But this risk ratio is off
| the charts and they ought to not use C for such critical
| libraries.
|
| Even as a C guru, you are going to make a mistake, at some point.
|
| I think this is the fix
| https://github.com/webmproject/libwebp/commit/dce8397fec159c...
|
| "malloc fail"? :facepalm: (oh yes, Slack, Discord, Teams,
| everything is affected, including all modern OS).
| saagarjha wrote:
| This is the fix:
| https://github.com/webmproject/libwebp/commit/902bc919033134...
| keyle wrote:
| Thanks!
| chrisbolt wrote:
| There's a follow-up fix, according to Debian[0]: https://gi
| thub.com/webmproject/libwebp/commit/95ea5226c87044...
|
| [0]: https://security-
| tracker.debian.org/tracker/CVE-2023-4863
| [deleted]
| ctz wrote:
| Not a single test, either here or in adjacent commits.
|
| !?!
| userbinator wrote:
| It's surprising that this isn't in a "newer" part of the image
| format; Huffman compression has been around for over 70 years,
| Canonical Huffman for a few decades less, but even JPEG uses
| Huffman. This is a decades-old technology that should've had the
| bugs worked out of its many implementations by now and there are
| also countless articles about how to implement it.
|
| I've read the JPEG spec (and written a decoder) before, so I
| decided to look at the WebP spec:
| https://developers.google.com/speed/webp/docs/webp_lossless_...
|
| The important information is in section 6. The first thing I
| notice is that it's not very clear how the codes are constructed,
| unlike the JPEG one (which actually has a ton of very readable
| flowcharts on the process), but it appears to be similar to
| LZH/deflate(zlib). The "specification" looks more like a selected
| set of source code fragments with accompanying descriptions.
|
| Perhaps I should try writing a WebP decoder too, having already
| done GIF, JPEG, and PNG, but based on the above "specification",
| it's almost as if they don't want you to.
| [deleted]
| nigeltao wrote:
| If you want some code to study,
| https://github.com/golang/image/tree/master/vp8l is a WebP-
| Lossless decoder in under 1200 lines of code.
| lifthrasiir wrote:
| > it's not very clear how the codes are constructed
|
| I agree the specification really lacks examples, but it
| explicitly states that it uses canonical Huffman trees so that
| only code lengths have to be transmitted. I think this is clear
| enough to pinpoint the actual tree. (I don't think there is any
| canonical Huffman tree implementation that uses the inverse
| lexicographical order.)
|
| > This is a decades-old technology that should've had the bugs
| worked out of its many implementations by now and there are
| also countless articles about how to implement it.
|
| Because there are many implementations of Huffman trees with
| different trade-offs? Charles Bloom once said that the
| definitive 1997 paper on Huffman optimizations [1] is still not
| well known at that point (2010) and many optimizations were
| rediscovered and then forgotten, so there should be many
| inefficient implementations out there.
|
| [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-
| huffm...
| Yeroc wrote:
| I'm surprised the summary of the article only talked about over-
| reliance on fuzzing and then suggested 1) more thorough code
| reviews and 2) sandboxing as solutions?! To me, the solution lies
| in using memory-safe languages.
| spookie wrote:
| Using memory safe languages may help, but the core issue lies
| on the lack of understanding of the program as a whole. Hence,
| the over reliance on fuzzing.
| anyfoo wrote:
| Luckily type safe languages, which includes memory safe
| languages, help you in understanding the program as a whole
| better, and strictly prevent you from doing things against
| that understanding, because the types literally encode
| automatically proven properties of your code.
| lmm wrote:
| Not all memory safe languages are type safe. I'd argue that
| expressive ML-style typing is if anything more important
| than memory safety, although it's hard to tell since a
| type-safe language will almost always have to be memory-
| safe.
| anyfoo wrote:
| I never claimed all memory safe languages are type safe.
| But memory safety is a subset of type safety. Whether
| dynamic or static (though I'm much in the latter camp),
| memory safety is achieved through information associated
| with the types. Whether that's exposed to the surface or
| not: Rust exposes it and is static, Haskell normally does
| not expose it and is also static, most modern dynamic
| languages are memory safe but don't expose the associated
| information.
| lmm wrote:
| > But memory safety is a subset of type safety. Whether
| dynamic or static (though I'm much in the latter camp),
| memory safety is achieved through information associated
| with the types.
|
| Nah. Dynamic languages don't actually have types (even if
| they have something that they call types), and even
| typed-but-GCed languages often don't really use the types
| for memory safety.
| anyfoo wrote:
| They have value types. The expressions don't have types
| (or rather very general types), but the values do, and
| it's still possible to have a dynamic language with very
| rigorous value types that have a well-defined set of
| inhabitants.
|
| Any dynamic language that has a string type has something
| similar to (for example) a buffer and a length associated
| with it internally. You can formalize that from the
| compiler's perspective, even if you don't expose it to
| the outside.
|
| You could argue that the _language_ doesn't necessarily
| have memory safety associated with its types, because a
| compliant compiler or interpreter could represent strings
| in any way it chooses, and on some academic level there's
| merit to that, but in practice you'd be rather stupid to
| implement the string value type in an interpreter or
| compiler for a language with a common string type in a
| memory unsafe way.
| Yeroc wrote:
| May help? Studies have shown that ~70% [1] of all security
| issues (including this one) are memory safety issues.
|
| [1] https://security.googleblog.com/2021/02/mitigating-
| memory-sa...
| [deleted]
| pcwalton wrote:
| Debating what the "core issue" is may be an interesting
| philosophical debate, but at the end of the day, using a
| memory-safe language would have prevented this issue from
| being exploitable.
| nolist_policy wrote:
| I think sandboxing is the more powerful solution. You think in
| terms of "What privileges can the attacker gain if this code
| blows up?" and limit the code's privileges to the minimum.
|
| Problem is, sandboxing is harder to implement so it's often
| done suboptimally or not at all.
| anyfoo wrote:
| This again.
|
| Strong type systems can give _provably_ correct code. For
| trusted code (e.g. not third party code), sandboxing is a
| post-exploit mitigation. And such a post-exploit mitigation
| cannot necessarily guard against any class of bugs that (at
| least in some aspect) provably correct code can.
|
| Yes, of course privilege separation as much as possible is
| still extremely valuable, but to say that sandboxing is a
| "better" solution, implying that one should not pursue
| provable correct code in favor of post-exploit mitigation, is
| a harsh liability. It's the same as the "oh, we don't need to
| use a type safe language, we have unit tests"-crowd, only
| worse.
| 0x53 wrote:
| What does provably correct mean here? I think you mean that
| the code doesn't have any memory corruption
| vulnerabilities. However, that is only one class of
| vulnerability, so more techniques then just relying on a
| memory safe language are required for secure software.
| anyfoo wrote:
| It means that the type system can prove certain
| properties for you. For example, in languages with
| dependent type systems like Agda, you can construct a
| sorted list type that the compiler will prove it sorted
| at all times, otherwise it won't compile. Or a complex
| tree type that is always balanced. Or a set of only even
| numbers, and again it won't compile otherwise...
|
| (Sadly, if you go that far, it isn't generally Turing
| complete anymore. Though in some cases that's a good
| thing.)
| kentonv wrote:
| > Strong type systems can give provably correct code.
|
| In theory, perhaps. In practice, the compiler / runtime
| will have bugs. So you still need a sandboxing layer. Best
| to do both.
|
| (The sandbox will have bugs too. But if you have two
| layers, hopefully it's hard for attackers to get ahold of
| zero days for both at the same time...)
| anyfoo wrote:
| Yeah, anything can be implemented incorrectly. My point
| was specifically that ignoring memory safe languages in
| favor of post-exploit mitigation is foolish, not that the
| latter is useless.
|
| But in practice, type systems can be proven to be sound,
| implementations of type checkers can be proven correct,
| and while it's still possible to make mistakes there,
| that isn't so much an issue in mathematics, simply
| because of how rigorous it is. This does not just include
| type systems, there's even an effort to rebase the
| foundation of mathematics on a type system instead of set
| theory!
|
| In other words, we likely agree that steel vaults can
| have holes. But we probably also agree that an average
| steel vault is better in keeping things in or out of it
| than a velvet curtain.
| lmm wrote:
| > In theory, perhaps. In practice, the compiler / runtime
| will have bugs.
|
| They probably won't. The trusted kernel for these systems
| is tiny; a sandbox is orders of magnitude more complex
| with orders of magnitude more chances for bugs to creep
| in.
| lifthrasiir wrote:
| > Strong type systems can give _provably_ correct code.
|
| "Sound" [1] type systems only guarantee the absence of some
| class of bugs as well. There are a lot of bug classes that
| remain exploitable. Memory safety happens to be a low-
| hanging fruit because many existing softwares are not even
| written in such languages.
|
| [1] "Strong" type systems generally refer to the
| intolerance towards implicit type conversions or memory
| unsafety, and that alone doesn't make type systems provably
| safe in some sense.
| anyfoo wrote:
| I did not claim that everything about the code was proven
| correct, but a subset of properties expressable by the
| type system.
|
| I agree that using the word "strong" was wrong. I
| basically meant it in the sense of "good"/"elaborate",
| mistakenly ignoring that "strong" already has a very
| specific meaning in type systems. Thanks for correcting.
| robertlagrant wrote:
| > Strong type systems can give provably correct code
|
| ^ I think this is where you seemed to claim that
| everything about the code was proven correct.
| littlestymaar wrote:
| Second problem: sandbox aren't perfect either. It's indeed
| useful, as part of a defense-in-depth approach, but it's far
| from sufficient.
|
| Memory safety could solve the problem altogether, but then
| again no program is 100% memory safe, there's always some
| kind of primitive that uses memory-unsafe code under the
| hood, so it's not perfect either.
|
| The "perfect" solution would probably be:
|
| - use memory safe languages
|
| - all primitives using memory unsafe stuff should get
| _formally_ verified
|
| Rust is kind of aiming at this (with things like [1] and
| [2]), but it's not there yet.
|
| [1]: https://dl.acm.org/doi/pdf/10.1145/3158154 [2]:
| https://github.com/rust-secure-code/safety-dance
| Yeroc wrote:
| Yes and Google Chrome has invested heavily in sandboxing and
| still had to ship this as a high-priority fix. I'd say
| sandboxing in conjunction with memory-safe languages is the
| future.
| kentonv wrote:
| The problem is that rewriting existing code into a memory-
| safe language is a huge investment -- and realistically the
| world depends on a _lot_ of code built over many decades
| that cannot be rewritten overnight. Consider that Mozilla
| created Rust _specifically_ so they could rewrite their
| browser in it, yet still only a small fraction of Firefox
| code is Rust today -- much more is still C /C++.
| Realistically we're going to have a lot of heavily used
| C/C++ code forever. The singularity will come before we can
| replace it all.
|
| The nice thing about sandboxing and fuzzing can be applied
| to existing code.
| Yeroc wrote:
| Yes, but sandboxing and fuzzing are insufficient. As
| pointed out in the article Google had been fuzzing this
| library and it didn't find the issue. They even tweaked
| the fuzzing after this issue was found to specifically
| target the area of the vulnerability and it apparently
| still didn't trigger the issue.
|
| Google Chrome also implements sandboxing and many areas.
| It's not feasible everywhere. So for new code / libraries
| we should default to a memory-safe language.
| kentonv wrote:
| I think almost everyone agrees new greenfield projects
| should not choose C/C++, now that Rust has matured enough
| and covers essentially the same use cases.
|
| But realistically that only solves a tiny fraction of the
| problem, since realistically new greenfield projects
| started today will likely take 10+ years to become widely
| used, if they do at all.
|
| WebP was written at a time when C/C++ was still the only
| viable language in which to write an image compression
| library. Saying "things like this should be written in
| Rust!" just doesn't actually do anything to make software
| like WebP secure. Improving fuzzers and sandboxing might.
| est31 wrote:
| > realistically new greenfield projects started today
| will likely take 10+ years to become widely used, if they
| do at all.
|
| I'm pretty sure that even now a lot speaks _against_
| using rust for greenfield projects precisely for that
| reason: few people want to integrate Rust into their
| build chain. You basically always have to have a compiler
| that 's 1 release old or otherwise you cannot compile new
| Rust software like the very widely used time crate.
|
| If you are a new and unproven format, do you really want
| to bear that hit? You could make two implementations, one
| in C and one in Rust, but that will mean you spread your
| probably quite scarce engineers over two projects.
| lmm wrote:
| You can write your implementation in Rust and expose a C
| ABI, and anyone using your library doesn't have to know
| or care that the internals use Rust. That's pretty much
| the whole point of Rust, otherwise you'd just use OCaml.
| kentonv wrote:
| Heh. Well, speaking as the lead engineer of a large C++
| systems project that sadly started a liiiiitle bit to
| early to use Rust (the Cloudflare Workers runtime), I'd
| say our attitude is the other way around: We basically
| refuse to bring in any kind of C/C++ dependency unless
| it's something used in Chrome (implying they've vetted
| it). We are much more willing to bring in Rust
| dependencies, even though they're harder for us to invoke
| due to the language barrier.
| Yeroc wrote:
| That's great, but the fact that the author of this
| article didn't mention memory safe languages is
| disturbing and an indication that not everyone is aware!
| albntomat0 wrote:
| The author is the former lead of Google Project Zero, and
| the article is an in depth look at a low level bug.
|
| He's certainly aware of memory safe programming.
| est31 wrote:
| That's a really good policy, and what I said above does
| not reflect my private opinion but the opinions of a lot
| of people that decoder projects target. You are in a way
| more controlled environment.
|
| For dav1d I heard that one of the reasons why C was
| chosen was precisely this portability concern. format
| decoders are usually quite low level components and can
| get integrated into all sorts of environments. I'm sure
| there is someone out there who made a visual studio
| project with a 3 year old VS version with dav1d inside
| for some embedded project. For such devs, Rust is a way
| harder sell.
| inferiorhuman wrote:
| You basically always have to have a compiler that's 1
| release old or otherwise you cannot compile new
| Rust software like the very widely used time crate.
|
| That's an interesting example as the time crate stagnated
| for quite a while and even the current version only
| requires Rust 1.67 or newer. The current Rust version is
| 1.72.
| est31 wrote:
| A rewrite of a webp decoder into Rust already exists
| (image-rs has a decoder for webp). I'm sure there is some
| polishing needed but it's nothing a company the size of
| Google can't afford.
| Yeroc wrote:
| Unfortunately, the readme for image-rs indicates that
| webp support is provided via the libwebp C library!
| est31 wrote:
| That's for the encoding part. The 0day we are talking
| about was in the webp decoder, and decoders generally are
| the riskier component compared to encoders. I'm not sure
| if Chrome ships with the webp encoder at all.
| tedunangst wrote:
| Only for encoding.
| skitter wrote:
| Mozilla has an interesting sandboxing strategy: They
| compile some of the C/C++ parts of Firefox (e.g. the ogg
| parser) to Wasm and then back to C. Because Wasm is
| memory safe, the resulting C is too.
| [deleted]
| Syonyk wrote:
| Good writeup, thanks for sharing it!
|
| And yet another argument for "You ought to be using Qubes."
| Random web access needs to be treated as "Genuinely high risk"
| anymore. A disposable VM with nothing of value in it for "casual
| web use" seems the right option for exploring the security
| hostile environment of "the internet."
| chatmasta wrote:
| Sure, that might help you on your desktop. But this exploit was
| only discovered because of a zero-click iOS exploit, where the
| payload was encoded in an iMessage attachment that opened in
| Passkit, which rendered the WebP file. (In fact the user didn't
| even need to "open" the attachment - just receiving the message
| was sufficient to trigger the exploit.)
|
| So Qubes won't help you everywhere, and the WebP decoder is
| everywhere.
| circuit10 wrote:
| Browsers already have sandboxes, they're not perfect but
| neither are VMs, and if you're going for a layer of security
| through obscurity by having an unusual setup (which is bad on
| its own but when layered with real security can be fine) then
| just running Linux is probably enough already
| cogman10 wrote:
| Unless you are making a vm per page refresh, I can't really see
| how a browser in the VM is any safer than a browser outside the
| VM.
|
| My most valuable stuff (passwords, bank accounts, logins) is
| accessible from the browser. You'd need to somehow sandbox and
| frequently destroy/restore the rendering and javascript engine
| to avoid leaking this information cross site while having a
| fairly strict firewall between those and the external browser.
| (IE: cookie/session/password storage).
| Syonyk wrote:
| It's not "a browser in a VM."
|
| It's "A range of VMs, with different browsers in them, for
| different purposes."
|
| My "random web use" browser VMs don't have _anything_ in them
| - they 're ephemeral. If I need a password, I copy it from
| another VM over. If you escape into that VM, you might be
| able to grab a password being pasted, but I don't access
| anything I consider sensitive in them - just random forum
| accounts, etc. And it's easy enough to spin up other
| disposable VMs for stuff in Qubes (I actually mostly browse
| through the Tor network, to add traffic to it).
|
| So, for your use case, you'd have one VM with your "core"
| stuff - passwords, logged in to webmail, banking. And then
| you do everything else web related in a different VM.
| cogman10 wrote:
| Ah, makes sense.
|
| Probably a good solution for the highly technical, not
| something I could ever propose to my mother.
| halJordan wrote:
| I mean your mother is successfully using Apple's highly
| sophisticated sandboxes and things like authenticated
| pointers. (sHe's On AnDrOiD)
|
| For Qubes specifically she can understand theres a bank
| Qube and a Facebook Qube and a nothing-special Qubes and
| its all color coordinated. She doesn't even need to know
| they are VMs, they're just color coded windows
| hiatus wrote:
| As a qubes user myself, I don't think my mother would be
| able to perform the initial setup and segregation, not to
| mention endure the hurdles of copy/paste rules and
| filesharing across VMs. Oh sure, she could learn another
| set of copy paste keyboard shortcuts that will end up as
| another handwritten note on her list of keyboard
| shortcuts. Not to mention how frequently I'd get called
| due to slowness as she neglects to close the VMs. And say
| goodbye to remote support options unless she gives me SSH
| to dom0 but then why do any of this anyway at that point?
| jwells89 wrote:
| My bet is that over time most people would slip on the
| separation and end up with tons of tabs in the wrong
| containers. The only way it'd work in the long term is if
| there were some way of automatically taking link clicks
| in the "wrong" container, thoroughly sanitizing them, and
| then tossing them over the "right" container but then
| you're back to risking cross-contamination.
| callalex wrote:
| Tools should work for people, not the other way around. The
| cognitive load of manually managing sandboxes is huge. Instead
| we could build tools that aren't fundamentally broken. Memory
| safety should be formally guaranteed before shipping.
| [deleted]
| bennyg wrote:
| This is a fun idea, are there any browsers that hide the VM
| from end users so it looks and feels like a browser instance
| but is actually a tunnel into a sandboxed VM that's being
| painted to?
| tech234a wrote:
| This exists as an option for Microsoft Edge on Windows:
| https://learn.microsoft.com/en-us/deployedge/microsoft-
| edge-...
| mminer237 wrote:
| The problem is that browsers are the biggest attack vectors
| but also the most valuable targets. Getting a user's email
| password or cookie is probably the most damaging thing they
| could get unless you're the type to buy cryptocurrencies.
| hiatus wrote:
| Not your bank? Email and bank login should be sufficient to
| change mfa and other settings and lock you out long enough
| to have forged checks drawn and cashed against your
| account.
| Chabsff wrote:
| That's kinda-sorta what they all do already. Not full OS-
| level VM abstraction, but surprisingly close to it. Exploits
| like this need to be paired with sandbox-escaping in order to
| do damage beyond the current browsing session (which VMs
| wouldn't help with in the first place). And the distinction
| between sandbox-escaping and VM-escaping is rather thin.
| Syonyk wrote:
| > _And the distinction between sandbox-escaping and VM-
| escaping is rather thin._
|
| Eh, I think it's a good bit harder to escape a HVM isolated
| virtual machine than a sandbox. At least, I'm not aware of
| many cross-Xen VM escapes.
| Chabsff wrote:
| Yes, I should have added that I'm referring specifically
| to the scenario OP is suggesting, which would require a
| host <-> client IPC channel, opening up the VM to similar
| attack vectors to a sandbox.
| lmm wrote:
| There used to be dozens of them at any given time; maybe
| they're a bit rarer now that cloud providers have been
| banging on them for a while.
| taway1237 wrote:
| There's a huge difference. Browser sandboxes are not
| "real" VMs and share a kernel. And in case of Chromium
| it's enough to read a few bytes from another process
| (token) to escape.
| nolist_policy wrote:
| Can you elaborate on that? What do tokens have to do with
| breaking out of a sandbox?
| skilled wrote:
| > The good news is that Apple and Chrome did an amazing job at
| responding to this issue with the urgency that it deserves
|
| Excuse me? It is Google that assigned this as Chrome only. Over
| the last 7 days alone every single major Linux distribution has
| had to push an update (including Red Hat which assigned this a
| 9.6 score), and Docker images like Python which has over 1
| billion pulls, not to mention Puppeteer(hello?), WordPress,
| Node.js, etc. and CRBug is still private to this day.
|
| I am not being condescending but sites like BleepingComputer
| reported this as they saw it rather than doing any investigation.
| And the same goes for a lot of security companies that reported
| on this issue in third person. It's really difficult to foster
| trust when you know that the person on the other side hasn't
| bothered to do any due diligence.
|
| Adam Caudill (1Password was one of the first to patch it) did a
| nice blog post, "Whose CVE is it anyway?"[0] highlighting the
| issue I am talking about in my comment.
|
| Citizen Lab has refused to comment on whether both are related,
| but it doesn't take a genius does it...
|
| [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/
| [deleted]
| albntomat0 wrote:
| Apple and Chrome specifically matter here because those where
| the targets being exploited in the wild, and have the most
| direct attack surface with the largest number of users.
|
| The author mentions that many other systems need to patch as
| well. However, wow many of those billion Python docker pulls
| are rendering untrusted WebP images? Same for Node, etc. These
| should also be promptly patched, but they're not in the same
| ballpark here as iOS/Android/Chrome.
| omginternets wrote:
| I have a few questions I'm not able to find clear answers to:
|
| 1. Are other Chrome-based browsers (e.g. Brave) affected by this?
|
| 2. Is desktop Chrome affected, or is this purely a mobile thing?
|
| 3. Why haven't I heard of WebP before? Am I living under a rock,
| or is this a mobile-first technology?
| dboreham wrote:
| It's a Google-first technology.
| fiddlerwoaroof wrote:
| It's pretty broadly supported now:
|
| https://caniuse.com/webp
| oittaa wrote:
| Many CDNs use it automatically. They detect you're on a
| modern browser and transparently compress sub-optimal
| images like PNGs without loss of quality.
| nyanpasu64 wrote:
| Considering that "lossless" WebP comes with mandatory
| chroma subsampling, I'd say that WebP and not PNG is the
| sub-optimal image format.
| NavinF wrote:
| > "lossless" WebP comes with mandatory chroma subsampling
|
| Source? I've roundtripped bitmap->WebP->bitmap and got
| the same bits out
| nyanpasu64 wrote:
| I did find that `ffmpeg -i file.png -lossless 1
| test.webp` could produce a full-res chroma image,
| recognized as WebP by file and opening successfully in
| Chrome and Firefox. I was under the impression this was
| not possible, but I suppose it is (today, not sure in the
| past).
|
| Why do I see WebP as an image format used to sneakily
| degrade PNG files? I've seen gaming wikis and CDNs serve
| PNG URLs as lossy WebP, ruining pixel art and degrading
| color detail in 2D art. And Discord CDN's
| "file.webp?size=1024&quality=lossless" serves
| icons/emotes with chroma subsampling (and ffprobe doesn't
| say the file is lossless, unlike test.webp above).
| NavinF wrote:
| Umm why not use `cwebp -lossless`? That's the official
| solution and it even guarantees preservation of
| transparent pixels with `-exact`:
| https://developers.google.com/speed/webp/docs/cwebp
|
| > today, not sure in the past
|
| Dunno about ffmpeg, but the official library supported
| lossless encoding a decade ago
|
| > Why do I see WebP as an image format used to sneakily
| degrade PNG files?
|
| Why does Twitter reencode PNG to JPEG even when this
| results in larger file sizes and terrible quality for 2D
| art and technical drawings? All the services you've
| listed are free and they all cater to the lowest common
| denominator. They'll never use lossless WebP by default
| for the same reason they won't use PNG. Lossless media is
| virtually unheard-of outside our bubbles. If you're lucky
| there will be a "download original" button
| aidenn0 wrote:
| > 3. Why haven't I heard of WebP before? Am I living under a
| rock, or is this a mobile-first technology?
|
| It's been supported in desktop chrome for a long while. There's
| dozens of JPEG replacements that have come and gone, and WebP
| is primarily notable for having Google's clout behind it. When
| Google bought Duck/On2 they got a lot of video compression
| technology, some of which went into WebP.
| mschuster91 wrote:
| At the scale of Youtube and Google Image Search, saving even
| 1% of data transfer is worth _a lot_ of money and yak-shaving
| efforts.
| aidenn0 wrote:
| Oh, it's definitely something that makes/made sense for
| them to do; just pointing out that not knowing one of many
| JPEG replacements doesn't mean you live under a rock.
| not2b wrote:
| WEBP is more of a PNG replacement; better lossless image
| compression. And it's claimed to be about 25% smaller.
| aidenn0 wrote:
| s/JPEG/PNG/ and my comment still works. In any event it's
| clearly designed for both, since the lossy and lossless
| modes are relatively independent of each other.
| eviks wrote:
| So why are they fighting the better JXL?
| wooque wrote:
| Every browser is affected, Firefox issued security update as
| well.
|
| WebP is gaining popularity as replacement for JPEG, I'm
| surprised you haven't stumbled it on yet, cause more and more
| images I download from the web turn out to be WebP.
| magicalhippo wrote:
| > Firefox issued security update as well
|
| Fixed[1] in Firefox 117.0.1 as well as some ESR and
| Thunderbird versions.
|
| [1]: https://www.mozilla.org/en-
| US/security/advisories/mfsa2023-4...
| NavinF wrote:
| You've almost certainly downloaded WebP images, but you didn't
| realize it because many websites serve multiple formats at the
| same URL. This is often done with a HTTP reverse proxy that
| automatically converts between formats so if you have a modern
| (last decade) browser, you'll get a WebP even if the download's
| file extension seems to be ".png". All modern image editors
| support WebP so you'll never notice the difference
| whywhywhywhy wrote:
| >All modern image editors support WebP so you'll never notice
| the difference
|
| This support has always been overstated. Photoshop still
| doesn't support it, you encounter other weirdness like Apple
| Preview.app can view them but not edit them.
| NavinF wrote:
| Photoshop definitely supports it:
| https://helpx.adobe.com/photoshop/kb/support-webp-image-
| form...
|
| Preview.app is the exception to the rule, but it still has
| acceptable UX. After you finish drawing the first brush
| stroke on a WebP file, it will ask you to reopen the edited
| file as a tiff before you continue editing. No loss of data
| or functionality
| noir_lord wrote:
| Cloudflare Polish and similar will transparently do it as
| well, as long as the Accept header contains webp.
| joveian wrote:
| On The Guardian for example it looks like I'm getting WebP
| for the photo collections and AVIF for the story images, both
| from .jpg URLs (in Firefox hit Ctl-I to see image info).
| Their photo galleries have been WebP for years. Firefox is
| clever enough to correct the suffix if you try to save it.
| pornel wrote:
| 1. _Everything_ that supports WebP is affected. Not just Chrome
| and Electron, but all browsers, desktop and mobile, and non-
| browser software too. All kinds of image viewers, graphics
| programs, email clients, even your file manager that shows
| thumbnails.
|
| The bug is in the codec library, and WebP has implementation
| monoculture, so everyone uses the same library, and everyone
| needs to patch.
|
| 3. Google tried to make WebP a thing 10 years ago, but it
| didn't get much traction, since it was Chrome-only for a long
| time. It never got properly standardized (it is open source
| tho). It compresses low-quality images better than JPEG, but
| tends to blur and smear colors in higher-quality images.
|
| Ironically WebP became widely supported at the same time when
| it became technically obsoleted by AVIF and JPEG XL.
| moffkalast wrote:
| > even your file manager that shows thumbnails
|
| Aha! Finally the day has come when KDE's Dolphin emerges as
| the most secure file manager, in a "this sign can't stop me
| because I can't read" fashion.
| Macha wrote:
| Desktop Linux is on the relatively safer side, just because
| so much of the open source ecosystem still uses dynamic
| linking so it just needs your distro to package a new
| version of libwebp.
|
| All the proprietary software with their own bundled
| versions of electron or vendored libraries, etc. on the
| other hand...
| josefx wrote:
| > so it just needs your distro to package a new version
| of libwebp.
|
| That and every snap/flatpack/etc. package, every
| container image you are using and possibly pip packages
| that can come with and compile all kinds of dependencies
| and haven't been maintained for ten years...
|
| The security benefit a well maintained Linux distro
| provides has been eroding for years now.
| sundarurfriend wrote:
| What do you mean? Dolphin displays thumbnails perfectly
| fine, and I love how easy it is to change the thumbnail
| size (ctrl-mousewheel or the slider at the bottom).
| moffkalast wrote:
| Might be just the type of files I'm working with, but it
| feels like half the time it renders the thumbnail as
| broken static or even not at all.
| sundarurfriend wrote:
| I don't think I've ever seen that in the past several
| years of using Dolphin. The context here being webp, I
| checked the many webp files I have, and Dolphin
| thumbnails all of them without any issue.
| est31 wrote:
| > Ironically WebP became widely supported at the same time
| when it became technically obsoleted by AVIF and JPEG XL.
|
| Firefox _very_ quickly implemented WebP when YouTube (a
| Google property) added support for animated WebP based hover
| thumbnails.
| pornel wrote:
| Mozilla created MozJPEG to show that WebP is unnecessary if
| you compress JPEGs well.
|
| Firefox and Safari only caved years later once Chrome-only
| WebP-only websites were too common to ignore.
| archerx wrote:
| I ignore them without problem, I do most of my web
| reading on my iPad that does not support webp and most
| sites display images without issues. Usually the ones
| that only offer images in webp are low quality sites and
| it's usually a good sign I should just bounce.
| doublepg23 wrote:
| WebP has been supported by Safari for a while now. Even
| WebM is supported which uses VP8/9
| https://caniuse.com/webp https://caniuse.com/webm
| teruakohatu wrote:
| > but all browsers, and non-browser software too
|
| It is a libwebp vuln right? So anyone that does not link to
| libwebp is or may be ok.
| tedunangst wrote:
| Pretty long tail of apps that shell out to imagemagick to
| convert stuff, too.
| not2b wrote:
| A security update for libwebp has been shipped by the major
| Linux distros.
| jandrese wrote:
| Yeah, but once you fix the library the system should be
| safe. Well, except for all of the snaps and docker
| containers and whatnot. Those will need to be updated as
| well.
| tedunangst wrote:
| There is an implementation for go, although it doesn't
| support every feature of the format.
| Hello71 wrote:
| ffmpeg also has an independent implementation based on its
| own vp8 decoder
| [deleted]
| benhawkes wrote:
| Good questions -- yes other Chromium-based browsers would
| likely be affected by this bug. Many of these do a commendable
| job of following security updates in Chromium (like Brave), but
| others tend to fall quite far behind (like Samsung's SBrowser).
|
| Chrome desktop was affected as well, both on Linux and Windows.
| Chrome bundles its own version of libwebp, so even if your
| Linux distribution hasn't patched yet, as long as Chrome is up-
| to-date you should be OK (in terms of browser attacks at
| least).
|
| There's lots of wonderfully obscure image file formats that are
| supported by the major browsers and operating systems. For
| example you can load a KTX2 file (Khronos Texture Container) on
| MacOS, or a DNG file (Adobe Digital Negative) on Android. Lots
| of interesting and highly exposed attack surface for attackers
| to explore.
| omginternets wrote:
| >Chrome desktop was affected as well, both on Linux and
| Windows.
|
| Not MacOS though?
| Bluecobra wrote:
| MacOS is affected. Sadly there hasn't been much coverage on
| this...
|
| Also for corporate users this is a pain as you have to
| update Safari via Software Update unlike browsers like
| Chrome which automatically update.
|
| Safari:
|
| https://support.apple.com/en-us/HT213930
|
| MacOS:
|
| https://support.apple.com/en-us/HT213906
|
| https://support.apple.com/en-us/HT213915
|
| https://support.apple.com/en-us/HT213914
| benhawkes wrote:
| Chrome on MacOS was affected as well, yeah. Note that we
| don't know if attackers exploited the bug on platforms
| other than iOS, but its certainly possible that they did
| (I'd argue even probable).
___________________________________________________________________
(page generated 2023-09-22 23:01 UTC)