[HN Gopher] The WebP 0day
___________________________________________________________________
The WebP 0day
Author : benhawkes
Score : 150 points
Date : 2023-09-21 17:21 UTC (5 hours 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?
| 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.
| kristopolous wrote:
| Can you give me a real number on that? Are we talking over a
| million? Over 5?
| 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.
| 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.
| 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/
| 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.
| 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]
| 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.
| 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.
| [deleted]
| 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.
| 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]
| 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.
| 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...)
| 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.
| 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.
| 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.
| [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?
| [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.
| 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]
| 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.
| 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.
| 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...
| 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.
| 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.
| 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?
| 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-21 23:00 UTC)