12 ms·

Chrome: Heap buffer overflow in WebP

333 points by skilled 3y ago

jeroenhd 3y ago
Well, that's pretty bad. User-uploaded WebP images are used in tons of messengers and tons of messengers also use Chrome's render engine to produce "native" apps that get statically compiled (i.e. a single update isn't enough to patch your system, every app needs an update). I hope this is just Google Chrome, somehow. The secrecy is a little annoying. The page links to two places where you can supposedly find details, but both are internal resources. It's hard to judge how pervasive the bug is, and to find out if other software using Chrome as a render engine are also affected. Also pretty comical that Google's Project Zero policy is to release details (edit: 7 days after) a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable. Good for Apple that they didn't decide to pay Google back in kind.
- suddenclarity 3y ago
  Why release details publicly before people have a chance to update?
  - jeroenhd 3y ago
    To hasten security vendor response is usually the most important reasons. Software vendors, especially corporate ones, will happily keep a known vulnerability under embargo for years if you let them. Google's page (https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl...) has their reasoning explained in some more detail.
    - suddenclarity 3y ago
      I'm not asking why vulnerabilities should be published, but rather why they should be published before an update is in place. Even the page you linked now explained the importance of waiting 30 days after a fix is in place and even allow a 14 days extension in the case of update cycles. In the case of the Chrome update, the fix is rolling out during the coming "days/weeks" and you originally complained about the vulnerability not being public. Which raised my question.
      - jeroenhd 3y ago
        Google has a history of releasing vulnerability details and PoCs before updates could be rolled out; CVE-2020-17087 was perhaps the worst example. The two weeks grace period is in place for your run-of-the-mill 90-day disclosure time period, but for actively exploited bugs that extension period is up to three days. After digging in deeper, it appears they have the fix rolling out 6 days after the report came in, so they're within their own deadline I suppose. Their statement about publishing the details doesn't mention releasing the details in a month like their own projects would, though: (https://www.bleepingcomputer.com/news/google/google-fixes-another-chrome-zero-day-bug-exploited-in-attacks/ https://www.bleepingcomputer.com/news/google/google-fixes-an...): > "Access to bug details and links may be kept restricted until a majority of users are updated with a fix," Google said. "We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven't yet fixed." Google's inconsistencies when it comes to disclosure timelines irk me. "Wait until all third parties have also updated their software" isn't a luxury Google provides to others when they're the ones finding bugs. I'm all for swift disclosure timelines and pressure on manufacturers, but every Google team seems to have their own rules and guidelines written to serve themselves rather than general security.
- lima 3y ago
  > Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable. Project Zero treats Google like any other vendor (much to the annoyance of other internal teams).
- rs_rs_rs_rs_rs 3y ago
  >Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable That is not true please stop spreading misinformation.
  - jeroenhd 3y ago
    You're right, after looking it up I found that the time period for actively exploited bugs is seven days. I must've misremembered.
frankjr 3y ago
Fix OOB write in BuildHuffmanTable https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134...
- hannob 3y ago
  Also interesting: Shortly after there is another commit that is related to oss-fuzz: https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 https://github.com/webmproject/libwebp/commit/95ea5226c87044... This could mean Google optimized their fuzzers for libwebp after finding that bug and now they're finding more.
deleted 3y ago
[deleted]
londons_explore 3y ago
Within Google Chrome, WebP images are decoded by the renderer, and therefore any exploit can only get renderer code execution - which is inside a sandbox. Since the renderer is very complex, there are lots of exploits discovered each year for it. However, when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get. Specifically, they can't see or leave files on the filesystem of your machine, nor even read cookies for other domains.
- sigmoid10 3y ago
  Getting permissions on a single website user context is already enough considering the vast amount of user uploaded images on the modern internet. It's a bit like XSS on steroids, because it is not limited to one site or frontend.
  - londons_explore 3y ago
    Well websites are stupid if they don't reencode user-uploaded images for precisely this reason... Otherwise an evil client uploads a malicious webp image, which then gets hosted and 'shared' by the server to other users, who upon viewing said image get exploited and share more malicious images...
    - masklinn 3y ago
      Unless you mean the client should transcode before upload (which they can, mind) that mostly makes the server exploitable.
      - mortehu 3y ago
        You'd set up the server so that it's okay if it gets exploited. For example, maybe its only job is decoding images.
        michaelt 3y ago
icelusxl 3y ago
Seems to be reported by Apple and looks a lot like this security update: https://support.apple.com/en-us/HT213906 https://support.apple.com/en-us/HT213906
- masklinn 3y ago
  Reported by Apple “and the citizen lab at the UoT Munk School”, which is exactly who’s attributed on the page you link to. So yeah seems pretty likely, either Apple uses libwebp internally in ImageIO or they made a similar mistake.
  - saagarjha 3y ago
    Former
- brigade 3y ago
  It is interesting to see how different the reactions are now than last week
londons_explore 3y ago
I'm sure that in 2023, no mainstream software runs image decoders outside a sandbox right??
- rfoo 3y ago
  ... and then people chain it with a sandbox escape. This bug is the initial vector of last week's NSO Group zero-click exploit for iPhones: https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
  - londons_explore 3y ago
    The sandbox escape is the 'bigger' issue really. Applications parse crazy complex stuff to do everything they do, so obviously have a really big attack surface. Often the complexity is unavoidable - if you are a web browser, you cannot avoid parsing html for example. However the sandbox is designed to have an attack surface as small as possible (and be configurable via permissions to have the bare minimum needed). The sandbox interfaces with the rest of the system are fully controllable by Apple, so there is no need to be passing complex and dangerous legacy datastructures across the boundary either. Therefore, it should be the sandbox that is 'hardest' to break out of.
    - rfoo 3y ago
      Your point on sandboxes reduce attack surface is good. > so there is no need to be passing complex and dangerous legacy datastructures across the boundary either. lol, by same logic there is no need to be passing complex and dangerous legacy stuff to browser to parse, just rewrite the world to be simpler.
- intelVISA 3y ago
  Yep, not following best practices was banned late 2022 so thankfully your fave outsourced shop is only shipping High Quality and Secure Code (tm) Oh wait, that whole LLM thing...
- 3y ago
gavinsyancey 3y ago
Does this affect electron as well? If so, what versions?
- frankjr 3y ago
  It does, see [0]. Fun fact: Signal desktop, which uses Electron under the hood, is running without sandbox on Linux [1][2]. [0] https://github.com/electron/electron/pull/39824 https://github.com/electron/electron/pull/39824 [1] https://github.com/signalapp/Signal-Desktop/issues/5195 https://github.com/signalapp/Signal-Desktop/issues/5195 [2] https://github.com/signalapp/Signal-Desktop/pull/4381 https://github.com/signalapp/Signal-Desktop/pull/4381
  - Y-bar 3y ago
    I just love the unnecessary jousting with the stupid stale bot in 5195
  - est31 3y ago
    To be fair, if signal didn't use electron, they would probably have used libwebp still, and then they would either have to implement sandboxing themselves, or they would be subject to the same vulnerability. Still, that they didn't prioritize this is sad.
    - Waterluvian 3y ago
      If they didn’t use electron they’d probably not even have a Linux client, so there would be no problem! But the lack of sandboxing when it’s available, for something like Signal, is kind of weird. I wonder what the reasoning was.
_rdvw 3y ago
This will be in today's Firefox 117.0.1 and Fenix 117.1.0: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca2125a6eb1e2d08cc9e5824f15e1e67a566 https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...
montzark 3y ago
Imo other related code of the person who made that mistake should be audited, could be there is similiar mistake somewhere else. Additionally imo possible that some developers would intentionally make such mistakes to sell these to interested persons, there are millions to be made here.
- isodev 3y ago
  Establishing a blaming culture would be quite detrimental. Bugs happen, regardless of who commits the code. A more robust approach is to implement appropriate checks (like fuzzing, code analysis etc) that offer an opportunity to review and correct issues before they ship (and for people to learn from).
  - irundebian 3y ago
    The chromium developers do all this but this hasn't prevent this bug.
    - isodev 3y ago
      It's software, bugs happen.
      - irundebian 3y ago
        Many bugs can be prevented.
    - summerlight 3y ago
      That's not a good reason to just blame a specific developer instead of having the best practice in place.
- vitus 3y ago
  The breakage [0] was introduced by the creator [1] of the project. If you want to audit 1674 commits over the past 12 years, it'd be easier to just audit the full project. [0] https://github.com/webmproject/libwebp/commit/21735e06f7c1cb35562754e7f54365f24124ef15 https://github.com/webmproject/libwebp/commit/21735e06f7c1cb... [1] https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32f3e7eab5b7997a85ad8814b188 https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32...
irundebian 3y ago
It would be interesting to know how this vulnerability has been found.
- fh9302 3y ago
  https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer... > Last week, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices, Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware. And since the initial bug appears to be in Google's webp library other programs are also vulnerable.
  - irundebian 3y ago
    Okay, but I mean the initial finders of the vulnerability. If they are conducted manual code reviews, automatic static analyses or fuzzing.
    - tadfisher 3y ago
      Visit the link in the comment to which you're replying.
      - hannob 3y ago
        I think he is talking about NSO group, or whoever sold it to them. However, obviously that's unlikely to get revealed.
        insanitybit 3y ago
        I have to imagine that NSO group just watches the commit log for "I optimized webp" lol it's free CVEs
    - saagarjha 3y ago
kouteiheika 3y ago
It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages? Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3]. [1] -- https://code.videolan.org/videolan/dav1d https://code.videolan.org/videolan/dav1d [2] -- https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif [3] -- https://github.com/AOMediaCodec/libiamf https://github.com/AOMediaCodec/libiamf Yep. Keep writing these in C; surely nothing will go wrong.
- Patrickmi 3y ago
  [dead]
- masklinn 3y ago
  We all know that’s The Price Of Freedom. As they say, “give me exploitable trivial memory safety bugs or give me authoritarian dystopia” (https://news.ycombinator.com/item?id=27638940 https://news.ycombinator.com/item?id=27638940).
  - ignoramous 3y ago
    Dystopia? Given a choice, you'd rather trust a compiler than a human given the billions already lost to buffer overflows, read after free, and other memory related bugs, surely?
- EustassKid 3y ago
  Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?
  - 3y ago
Bu9818 3y ago
Will libwebp get a new release/tag soon?
- jeroenhd 3y ago
  If not, this seems to be the patch: https://chromium.googlesource.com/webm/libwebp.git/+/4619a48fc3292743d7ce9658bee4245406734109%5E%21/ https://chromium.googlesource.com/webm/libwebp.git/+/4619a48...
lifthrasiir 3y ago
The original commit in question: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1be52350b1a6fc5cfa6c2194499 https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1... The commit that fixes this bug: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... The original commit optimizes a Huffman decoder. The decoder uses a well-known optimization: it reads N bits in advance and determines how many bits have to be actually consumed and which symbol should be decoded, or, if it's an N-bit prefix of multiple symbols, which table should be consulted for remaining bits. The old version did use lookup tables for short symbols, but longer symbols needed a graph traversal. The new version improved this by using an array of lookup tables. Each entry contains (nbits, value) where `nbits` is # bits to be consumed and `value` is normally a symbol, but if `nbits` exceeds N `value` is interpreted as a table index and `nbits` is reinterpreted as the longest code length in that subtree. So each subsequent table should have `2^(nbits - N)` entries (the root table is always fixed to 2^N entries). The new version calculated the maximum number of entries based on the number of symbols (kTableSize). Of course, the Huffman tree comes from an untrusted source and you can easily imagine the case where `nbits` is very big. VP8 Lossless specifically allows up to 15 bits, so the largest possible table has 2^N + 2^15 entries when every single LUT is mapped to its own secondary table, and doing this doesn't need that many symbols (you only need 16-N symbols for each table). Amusingly enough the code itself had a mode where only the table size is calculated (VP8LBuildHuffmanTable called with `root_table == NULL`), but it wasn't somehow unused and the fixed maximum size was assumed. So if the Huffman tree was crafted in the way that maximizes the number of entries, it will overflow the allocation. To be fair, I can see why this happened; the Huffman decoding step is one of the most computationally intensive part of many compression format and any small improvement matters. The Huffman decoder optimization described above is well known, but the longer code case is commonly considered less important to optimize because longer code should rarely appear in general. The original commit message refuted this, and was able to be merged. I'm not even sure that a memory safe language could have prevented this; this is a rare case where you actively want to avoid the overflow check [1]. [1] I should note that the memory corruption occurs during the table construction, which is not a tight loop, so a partial overflow check would be very helpful. The actual fix never altered the `ReadSymbol` function at all! But the safety of the tight loop should be still justified, so the wrong justification can ruin everything.
acdha 3y ago
This is why I’m more sympathetic to browser developers being slow to adopt new formats. WebP is a marginal advantage over JPEG (mostly transparency) which hasn’t seen much success but now that’s translated into multiple high-priority security holes and we’re all going to be spending the next month deploying patches everywhere which links against libwebp. That doesn’t mean we shouldn’t do new things but I think as developers we’re prone to underestimate the cost pretty heavily.
- o1y32 3y ago
  Eh, I think websites adopt webp for their smaller size than anything else.
  - acdha 3y ago
    Yes but you have to pay a LOT in bandwidth for a <10% savings to be worth the cost of supporting an entire extra toolchain and dealing with the support issues (better now but it took a decade not to have “I right-clicked and now I can’t open it” reports from users). Google and Facebook serve that much but most people do not.
    - dvhh 3y ago
      For some datacenters, that 10% saving would be worth the effort and could push back costly maintenance to increase egress bandwidth. And I would argue that beside Facebook, the end user right clicking and saving the image for them to use in an inappropriate manner ( downloading the image is not the issue, using it without permission would cause copyright infringement ) would be an issue for some of the website that are hosting the image.
      - acdha 3y ago
        > For some datacenters, that 10% saving would be worth the effort and could push back costly maintenance to increase egress bandwidth. No argument - my point was simply that very few sites on the web fall into that category. > And I would argue that beside Facebook, the end user right clicking and saving the image for them to use in an inappropriate manner That’s only true for a subset of sites, only to the extent that this wasn’t covered by fair use, and it came up enough that it was a common objection.
_8j50 3y ago
Is there a realistic path to exploiting this? From what I hear, heap-spraying on 64bit is no longer practical. Is there a predictable object in memory that could be overwritten?
- insanitybit 3y ago
  It's being exploited in the wild, so yes. Heap Spraying is definitely still a thing for kernel exploitation on 64bit, idk about the primitives people use for v8 exploitation.
gardaani 3y ago
This is a vulnerability in the WebP library, so this isn't only about Chrome. Which software is affected by this? - Android apps? - Cross-platform Flutter apps? - Electron apps? - Microsoft Edge and Brave (and all other Chromium based web browsers)? - Signal and Telegram displaying WebP stickers? - Which image editors are affected? Affinity tools, Gimp and Inkscape seem to use libwebp. - LibreOffice displaying WebP images? - server software such as WordPress (does it decode images to re-encode them?)? Apple devices were also affected, but they already got a fix. Anything else?
- duringmath 3y ago
  Firefox? Android WebView got patched so there's that.
  - internetter 3y ago
    > Firefox? Yup. https://hg.mozilla.org/releases/mozilla-release/rev/e245ca2125a6eb1e2d08cc9e5824f15e1e67a566 https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...
  - nlitened 3y ago
    Have only the recent Android phones been patched, or also 3—4+ year old phones as well?
    - NoahKAndrews 3y ago
      Phones of that era and later get WebView patched through Google Play, so they'll get the update.
    - ehsankia 3y ago
      That was the whole purpose of Project Mainline [0], which turned many critical system components into modules that can be updated through the Play Store regardless of manufacturer and OS updates. Media codecs is one of the first things they turned into a module, specifically for this reason; it is one of the biggest source of security patches. I actually remember hearing a stat that 90%+ of security patches are limited to a very small handful of components (media codec, crypt lib, network stack). So by turning those into modules that can be updated independently of the OS, all Android devices get to benefit from it, even years after they're abandoned by their OEMs. [0] https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system
vohu43 3y ago
This does really not sound good
est31 3y ago
FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image https://github.com/image-rs/image It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?
- insanitybit 3y ago
  If Chrome had a flag for "use the safe versions of XYZ libraries, even if they might be slower" I would absolutely flip that switch and take the performance hit.
  - Lt_Riza_Hawkeye 3y ago
    Right, but for most users, Chrome's differentiator is that it's fast. I can't imagine them flipping the flag on by default - and if 99.99% of users aren't going to use it, it's probably not worth it to bloat the binary size either. Maybe someone will make a chromium patch with it that people can keep rebasing, though
    - insanitybit 3y ago
      > Chrome's differentiator is that it's fast. I don't think that's the whole story. Chrome aggressively marketed itself around its sandboxing and security at a time when browser drive bys were huge. Anyone I recommended Chrome to, I did so because of security, not performance. > if 99.99% of users aren't going to use it, Ideally the crate would get closer and closer to the performance required to enable it entirely. I just meant as a temporary state. Also, I think more than .01% of users would enable it if there were a checkbox on install like "We can make your browser a tiny bit slower but potentially increase its security". > it's probably not worth it to bloat the binary size either. eh, there's so much in `chrome://flags` I don't think that they mind too much? idk
- NelsonMinar 3y ago
  It's crazy to me in 2023 we're still writing new C/C++ code for something with as enormous an attack surface as a web browser.
PaulHoule 3y ago
There is a long history of vulnerabilities in image codecs. The actual image processing is nice linear code you could write in memory-safe FORTRAN IV but compression means you have a lot of variable length data structures, pointer chasing, etc... And the pressure to make it run fast.
hollerith 3y ago
It's nice that Google identified this security hole, but I suspect that Google is also the main reason for its existence in the first place: if Google didn't want to reduce by a few percent its costs for serving images, there probably would be no widespread usage of the WebP format. (Similarly, it is nice that Google finds so many bugs in Javascript engines, but on the other hand they were one of the the main proponents of the bad idea of turning every web page into an executable program in the first place.) ADDED. OK I was unfair in my guessing as to Google's motivation: the main motivation seems to have been to speed up page loading across the web.
- akmittal 3y ago
  How is every webpage executable?
  - hollerith 3y ago
    In order to reliably view the web pages I visit, I must be prepared to execute Javascript or more precisely employ a browser to do it for me. The web was not always that way.
    - akmittal 3y ago
      My 15 years of web usage there was no time when I could turn JS off and everything would work fine.
- kccqzy 3y ago
  Read some history, friend. People wanted to turn web pages into executable programs even before Google existed. Have you heard of Java applets (Sun)? Have you heard of the beginnings of JavaScript (Netscape)? Have you heard of VBScript (Microsoft)? This is inevitable. Even if none of the aforementioned companies did it, some other company will.
  - Bluecobra 3y ago
    The network is the computer! :barf:
nocsi 3y ago
And people wonder why the pentagon enforced user to run browsers in a VM or print out websites to read as flattened pdfs
- mdaniel 3y ago
  Heh, ah yes, pdf: the MOST sekure file format :-D But seriously, depending on the attack vector in mind, using those "browser over VNC" technologies may address a lot of that risk if the objective is to read content without risking the local workstation running arbitrary code
_ache_ 3y ago
The WeBP and WeBP2 lib are a lot more tested than others format. I tried the official jxl lib and the heic tools, and I was able to identify bugs among these tools. I'm pretty sure that you can find a buffer overflow in these decoders.
- pornel 3y ago
  WebP2 is highly experimental, so don't count on it being safe. libwebp is relatively simple and clean C code, and has been around for over a decade. There are definitely scarier codec implementations than this.

333 points by skilled 3y ago

Well, that's pretty bad. User-uploaded WebP images are used in tons of messengers and tons of messengers also use Chrome's render engine to produce "native" apps that get statically compiled (i.e. a single update isn't enough to patch your system, every app needs an update). I hope this is just Google Chrome, somehow. The secrecy is a little annoying. The page links to two places where you can supposedly find details, but both are internal resources. It's hard to judge how pervasive the bug is, and to find out if other software using Chrome as a render engine are also affected. Also pretty comical that Google's Project Zero policy is to release details (edit: 7 days after) a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable. Good for Apple that they didn't decide to pay Google back in kind.

suddenclarity 3y ago
Why release details publicly before people have a chance to update?
- jeroenhd 3y ago
  To hasten security vendor response is usually the most important reasons. Software vendors, especially corporate ones, will happily keep a known vulnerability under embargo for years if you let them. Google's page (https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html https://googleprojectzero.blogspot.com/p/vulnerability-discl...) has their reasoning explained in some more detail.
  - suddenclarity 3y ago
    I'm not asking why vulnerabilities should be published, but rather why they should be published before an update is in place. Even the page you linked now explained the importance of waiting 30 days after a fix is in place and even allow a 14 days extension in the case of update cycles. In the case of the Chrome update, the fix is rolling out during the coming "days/weeks" and you originally complained about the vulnerability not being public. Which raised my question.
    - jeroenhd 3y ago
      Google has a history of releasing vulnerability details and PoCs before updates could be rolled out; CVE-2020-17087 was perhaps the worst example. The two weeks grace period is in place for your run-of-the-mill 90-day disclosure time period, but for actively exploited bugs that extension period is up to three days. After digging in deeper, it appears they have the fix rolling out 6 days after the report came in, so they're within their own deadline I suppose. Their statement about publishing the details doesn't mention releasing the details in a month like their own projects would, though: (https://www.bleepingcomputer.com/news/google/google-fixes-another-chrome-zero-day-bug-exploited-in-attacks/ https://www.bleepingcomputer.com/news/google/google-fixes-an...): > "Access to bug details and links may be kept restricted until a majority of users are updated with a fix," Google said. "We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven't yet fixed." Google's inconsistencies when it comes to disclosure timelines irk me. "Wait until all third parties have also updated their software" isn't a luxury Google provides to others when they're the ones finding bugs. I'm all for swift disclosure timelines and pressure on manufacturers, but every Google team seems to have their own rules and guidelines written to serve themselves rather than general security.
lima 3y ago
> Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable. Project Zero treats Google like any other vendor (much to the annoyance of other internal teams).
rs_rs_rs_rs_rs 3y ago
>Also pretty comical that Google's Project Zero policy is to release details when a public exploit is known to exist, yet the details are kept under wraps when their own software is vulnerable That is not true please stop spreading misinformation.
- jeroenhd 3y ago
  You're right, after looking it up I found that the time period for actively exploited bugs is seven days. I must've misremembered.

frankjr 3y ago

Fix OOB write in BuildHuffmanTable https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134...

hannob 3y ago
Also interesting: Shortly after there is another commit that is related to oss-fuzz: https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 https://github.com/webmproject/libwebp/commit/95ea5226c87044... This could mean Google optimized their fuzzers for libwebp after finding that bug and now they're finding more.

deleted 3y ago

[deleted]

londons_explore 3y ago

Within Google Chrome, WebP images are decoded by the renderer, and therefore any exploit can only get renderer code execution - which is inside a sandbox. Since the renderer is very complex, there are lots of exploits discovered each year for it. However, when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get. Specifically, they can't see or leave files on the filesystem of your machine, nor even read cookies for other domains.

sigmoid10 3y ago
Getting permissions on a single website user context is already enough considering the vast amount of user uploaded images on the modern internet. It's a bit like XSS on steroids, because it is not limited to one site or frontend.
- londons_explore 3y ago
  Well websites are stupid if they don't reencode user-uploaded images for precisely this reason... Otherwise an evil client uploads a malicious webp image, which then gets hosted and 'shared' by the server to other users, who upon viewing said image get exploited and share more malicious images...
  - masklinn 3y ago
    Unless you mean the client should transcode before upload (which they can, mind) that mostly makes the server exploitable.
    - mortehu 3y ago
      You'd set up the server so that it's okay if it gets exploited. For example, maybe its only job is decoding images.
      - michaelt 3y ago

icelusxl 3y ago

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

masklinn 3y ago
Reported by Apple “and the citizen lab at the UoT Munk School”, which is exactly who’s attributed on the page you link to. So yeah seems pretty likely, either Apple uses libwebp internally in ImageIO or they made a similar mistake.
- saagarjha 3y ago
  Former
brigade 3y ago
It is interesting to see how different the reactions are now than last week

londons_explore 3y ago

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

rfoo 3y ago
... and then people chain it with a sandbox escape. This bug is the initial vector of last week's NSO Group zero-click exploit for iPhones: https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
- londons_explore 3y ago
  The sandbox escape is the 'bigger' issue really. Applications parse crazy complex stuff to do everything they do, so obviously have a really big attack surface. Often the complexity is unavoidable - if you are a web browser, you cannot avoid parsing html for example. However the sandbox is designed to have an attack surface as small as possible (and be configurable via permissions to have the bare minimum needed). The sandbox interfaces with the rest of the system are fully controllable by Apple, so there is no need to be passing complex and dangerous legacy datastructures across the boundary either. Therefore, it should be the sandbox that is 'hardest' to break out of.
  - rfoo 3y ago
    Your point on sandboxes reduce attack surface is good. > so there is no need to be passing complex and dangerous legacy datastructures across the boundary either. lol, by same logic there is no need to be passing complex and dangerous legacy stuff to browser to parse, just rewrite the world to be simpler.
intelVISA 3y ago
Yep, not following best practices was banned late 2022 so thankfully your fave outsourced shop is only shipping High Quality and Secure Code (tm) Oh wait, that whole LLM thing...
3y ago

gavinsyancey 3y ago

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

frankjr 3y ago
It does, see [0]. Fun fact: Signal desktop, which uses Electron under the hood, is running without sandbox on Linux [1][2]. [0] https://github.com/electron/electron/pull/39824 https://github.com/electron/electron/pull/39824 [1] https://github.com/signalapp/Signal-Desktop/issues/5195 https://github.com/signalapp/Signal-Desktop/issues/5195 [2] https://github.com/signalapp/Signal-Desktop/pull/4381 https://github.com/signalapp/Signal-Desktop/pull/4381
- Y-bar 3y ago
  I just love the unnecessary jousting with the stupid stale bot in 5195
- est31 3y ago
  To be fair, if signal didn't use electron, they would probably have used libwebp still, and then they would either have to implement sandboxing themselves, or they would be subject to the same vulnerability. Still, that they didn't prioritize this is sad.
  - Waterluvian 3y ago
    If they didn’t use electron they’d probably not even have a Linux client, so there would be no problem! But the lack of sandboxing when it’s available, for something like Signal, is kind of weird. I wonder what the reasoning was.

_rdvw 3y ago

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

montzark 3y ago

Imo other related code of the person who made that mistake should be audited, could be there is similiar mistake somewhere else. Additionally imo possible that some developers would intentionally make such mistakes to sell these to interested persons, there are millions to be made here.

isodev 3y ago
Establishing a blaming culture would be quite detrimental. Bugs happen, regardless of who commits the code. A more robust approach is to implement appropriate checks (like fuzzing, code analysis etc) that offer an opportunity to review and correct issues before they ship (and for people to learn from).
- irundebian 3y ago
  The chromium developers do all this but this hasn't prevent this bug.
  - isodev 3y ago
    It's software, bugs happen.
    - irundebian 3y ago
      Many bugs can be prevented.
  - summerlight 3y ago
    That's not a good reason to just blame a specific developer instead of having the best practice in place.
vitus 3y ago
The breakage [0] was introduced by the creator [1] of the project. If you want to audit 1674 commits over the past 12 years, it'd be easier to just audit the full project. [0] https://github.com/webmproject/libwebp/commit/21735e06f7c1cb35562754e7f54365f24124ef15 https://github.com/webmproject/libwebp/commit/21735e06f7c1cb... [1] https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32f3e7eab5b7997a85ad8814b188 https://github.com/webmproject/libwebp/commit/c3f41cb47e5f32...

irundebian 3y ago

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

fh9302 3y ago
https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer... > Last week, while checking the device of an individual employed by a Washington DC-based civil society organization with international offices, Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware. And since the initial bug appears to be in Google's webp library other programs are also vulnerable.
- irundebian 3y ago
  Okay, but I mean the initial finders of the vulnerability. If they are conducted manual code reviews, automatic static analyses or fuzzing.
  - tadfisher 3y ago
    Visit the link in the comment to which you're replying.
    - hannob 3y ago
      I think he is talking about NSO group, or whoever sold it to them. However, obviously that's unlikely to get revealed.
      - insanitybit 3y ago
        I have to imagine that NSO group just watches the commit log for "I optimized webp" lol it's free CVEs
  - saagarjha 3y ago

kouteiheika 3y ago

It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages? Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3]. [1] -- https://code.videolan.org/videolan/dav1d https://code.videolan.org/videolan/dav1d [2] -- https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif [3] -- https://github.com/AOMediaCodec/libiamf https://github.com/AOMediaCodec/libiamf Yep. Keep writing these in C; surely nothing will go wrong.

Patrickmi 3y ago
[dead]
masklinn 3y ago
We all know that’s The Price Of Freedom. As they say, “give me exploitable trivial memory safety bugs or give me authoritarian dystopia” (https://news.ycombinator.com/item?id=27638940 https://news.ycombinator.com/item?id=27638940).
- ignoramous 3y ago
  Dystopia? Given a choice, you'd rather trust a compiler than a human given the billions already lost to buffer overflows, read after free, and other memory related bugs, surely?
EustassKid 3y ago
Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?
- 3y ago

Bu9818 3y ago

Will libwebp get a new release/tag soon?

jeroenhd 3y ago
If not, this seems to be the patch: https://chromium.googlesource.com/webm/libwebp.git/+/4619a48fc3292743d7ce9658bee4245406734109%5E%21/ https://chromium.googlesource.com/webm/libwebp.git/+/4619a48...

lifthrasiir 3y ago

The original commit in question: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1be52350b1a6fc5cfa6c2194499 https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1... The commit that fixes this bug: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a https://github.com/webmproject/libwebp/commit/902bc919033134... The original commit optimizes a Huffman decoder. The decoder uses a well-known optimization: it reads N bits in advance and determines how many bits have to be actually consumed and which symbol should be decoded, or, if it's an N-bit prefix of multiple symbols, which table should be consulted for remaining bits. The old version did use lookup tables for short symbols, but longer symbols needed a graph traversal. The new version improved this by using an array of lookup tables. Each entry contains (nbits, value) where `nbits` is # bits to be consumed and `value` is normally a symbol, but if `nbits` exceeds N `value` is interpreted as a table index and `nbits` is reinterpreted as the longest code length in that subtree. So each subsequent table should have `2^(nbits - N)` entries (the root table is always fixed to 2^N entries). The new version calculated the maximum number of entries based on the number of symbols (kTableSize). Of course, the Huffman tree comes from an untrusted source and you can easily imagine the case where `nbits` is very big. VP8 Lossless specifically allows up to 15 bits, so the largest possible table has 2^N + 2^15 entries when every single LUT is mapped to its own secondary table, and doing this doesn't need that many symbols (you only need 16-N symbols for each table). Amusingly enough the code itself had a mode where only the table size is calculated (VP8LBuildHuffmanTable called with `root_table == NULL`), but it wasn't somehow unused and the fixed maximum size was assumed. So if the Huffman tree was crafted in the way that maximizes the number of entries, it will overflow the allocation. To be fair, I can see why this happened; the Huffman decoding step is one of the most computationally intensive part of many compression format and any small improvement matters. The Huffman decoder optimization described above is well known, but the longer code case is commonly considered less important to optimize because longer code should rarely appear in general. The original commit message refuted this, and was able to be merged. I'm not even sure that a memory safe language could have prevented this; this is a rare case where you actively want to avoid the overflow check [1]. [1] I should note that the memory corruption occurs during the table construction, which is not a tight loop, so a partial overflow check would be very helpful. The actual fix never altered the `ReadSymbol` function at all! But the safety of the tight loop should be still justified, so the wrong justification can ruin everything.

acdha 3y ago

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

o1y32 3y ago
Eh, I think websites adopt webp for their smaller size than anything else.
- acdha 3y ago
  Yes but you have to pay a LOT in bandwidth for a <10% savings to be worth the cost of supporting an entire extra toolchain and dealing with the support issues (better now but it took a decade not to have “I right-clicked and now I can’t open it” reports from users). Google and Facebook serve that much but most people do not.
  - dvhh 3y ago
    For some datacenters, that 10% saving would be worth the effort and could push back costly maintenance to increase egress bandwidth. And I would argue that beside Facebook, the end user right clicking and saving the image for them to use in an inappropriate manner ( downloading the image is not the issue, using it without permission would cause copyright infringement ) would be an issue for some of the website that are hosting the image.
    - acdha 3y ago
      > For some datacenters, that 10% saving would be worth the effort and could push back costly maintenance to increase egress bandwidth. No argument - my point was simply that very few sites on the web fall into that category. > And I would argue that beside Facebook, the end user right clicking and saving the image for them to use in an inappropriate manner That’s only true for a subset of sites, only to the extent that this wasn’t covered by fair use, and it came up enough that it was a common objection.

_8j50 3y ago

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

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

gardaani 3y ago

This is a vulnerability in the WebP library, so this isn't only about Chrome. Which software is affected by this? - Android apps? - Cross-platform Flutter apps? - Electron apps? - Microsoft Edge and Brave (and all other Chromium based web browsers)? - Signal and Telegram displaying WebP stickers? - Which image editors are affected? Affinity tools, Gimp and Inkscape seem to use libwebp. - LibreOffice displaying WebP images? - server software such as WordPress (does it decode images to re-encode them?)? Apple devices were also affected, but they already got a fix. Anything else?

duringmath 3y ago
Firefox? Android WebView got patched so there's that.
- internetter 3y ago
  > Firefox? Yup. https://hg.mozilla.org/releases/mozilla-release/rev/e245ca2125a6eb1e2d08cc9e5824f15e1e67a566 https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...
- nlitened 3y ago
  Have only the recent Android phones been patched, or also 3—4+ year old phones as well?
  - NoahKAndrews 3y ago
    Phones of that era and later get WebView patched through Google Play, so they'll get the update.
  - ehsankia 3y ago
    That was the whole purpose of Project Mainline [0], which turned many critical system components into modules that can be updated through the Play Store regardless of manufacturer and OS updates. Media codecs is one of the first things they turned into a module, specifically for this reason; it is one of the biggest source of security patches. I actually remember hearing a stat that 90%+ of security patches are limited to a very small handful of components (media codec, crypt lib, network stack). So by turning those into modules that can be updated independently of the OS, all Android devices get to benefit from it, even years after they're abandoned by their OEMs. [0] https://source.android.com/docs/core/ota/modular-system https://source.android.com/docs/core/ota/modular-system

vohu43 3y ago

This does really not sound good

est31 3y ago

FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image https://github.com/image-rs/image It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?

insanitybit 3y ago
If Chrome had a flag for "use the safe versions of XYZ libraries, even if they might be slower" I would absolutely flip that switch and take the performance hit.
- Lt_Riza_Hawkeye 3y ago
  Right, but for most users, Chrome's differentiator is that it's fast. I can't imagine them flipping the flag on by default - and if 99.99% of users aren't going to use it, it's probably not worth it to bloat the binary size either. Maybe someone will make a chromium patch with it that people can keep rebasing, though
  - insanitybit 3y ago
    > Chrome's differentiator is that it's fast. I don't think that's the whole story. Chrome aggressively marketed itself around its sandboxing and security at a time when browser drive bys were huge. Anyone I recommended Chrome to, I did so because of security, not performance. > if 99.99% of users aren't going to use it, Ideally the crate would get closer and closer to the performance required to enable it entirely. I just meant as a temporary state. Also, I think more than .01% of users would enable it if there were a checkbox on install like "We can make your browser a tiny bit slower but potentially increase its security". > it's probably not worth it to bloat the binary size either. eh, there's so much in `chrome://flags` I don't think that they mind too much? idk
NelsonMinar 3y ago
It's crazy to me in 2023 we're still writing new C/C++ code for something with as enormous an attack surface as a web browser.

PaulHoule 3y ago

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

hollerith 3y ago

It's nice that Google identified this security hole, but I suspect that Google is also the main reason for its existence in the first place: if Google didn't want to reduce by a few percent its costs for serving images, there probably would be no widespread usage of the WebP format. (Similarly, it is nice that Google finds so many bugs in Javascript engines, but on the other hand they were one of the the main proponents of the bad idea of turning every web page into an executable program in the first place.) ADDED. OK I was unfair in my guessing as to Google's motivation: the main motivation seems to have been to speed up page loading across the web.

akmittal 3y ago
How is every webpage executable?
- hollerith 3y ago
  In order to reliably view the web pages I visit, I must be prepared to execute Javascript or more precisely employ a browser to do it for me. The web was not always that way.
  - akmittal 3y ago
    My 15 years of web usage there was no time when I could turn JS off and everything would work fine.
kccqzy 3y ago
Read some history, friend. People wanted to turn web pages into executable programs even before Google existed. Have you heard of Java applets (Sun)? Have you heard of the beginnings of JavaScript (Netscape)? Have you heard of VBScript (Microsoft)? This is inevitable. Even if none of the aforementioned companies did it, some other company will.
- Bluecobra 3y ago
  The network is the computer! :barf:

nocsi 3y ago

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

mdaniel 3y ago
Heh, ah yes, pdf: the MOST sekure file format :-D But seriously, depending on the attack vector in mind, using those "browser over VNC" technologies may address a lot of that risk if the objective is to read content without risking the local workstation running arbitrary code

_ache_ 3y ago

The WeBP and WeBP2 lib are a lot more tested than others format. I tried the official jxl lib and the heic tools, and I was able to identify bugs among these tools. I'm pretty sure that you can find a buffer overflow in these decoders.

pornel 3y ago
WebP2 is highly experimental, so don't count on it being safe. libwebp is relatively simple and clean C code, and has been around for over a decade. There are definitely scarier codec implementations than this.