No one mentioned that libwebp, a library found in millions of apps, was a 0-day origin.

Incomplete information included in recent disclosures by Apple and Google reporting critical zero-day vulnerabilities under active exploitation in their products has created a “huge blindspot” that’s causing a large number of offerings from other developers to go unpatched, researchers said Thursday.

Two weeks ago, Apple reported that threat actors were actively exploiting a critical vulnerability in iOS so they could install espionage spyware known as Pegasus. The attacks used a zero-click method, meaning they required no interaction on the part of targets. Simply receiving a call or text on an iPhone was enough to become infected by the Pegasus, which is among the world’s most advanced pieces of known malware. “Huge blindspot”

Apple said the vulnerability, tracked as CVE-2023-41064, stemmed from a buffer overflow bug in ImageIO, a proprietary framework that allows applications to read and write most image file formats, which include one known as WebP. Apple credited the discovery of the zero-day to Citizen Lab, a research group at the University of Toronto’s Munk School that follows attacks by nation-states targeting dissidents and other at-risk groups.

Four days later, Google reported a critical vulnerability in its Chrome browser. The company said the vulnerability was what’s known as a heap buffer overflow that was present in WebP. Google went on to warn that an exploit for the vulnerability existed in the wild. Google said that the vulnerability, designated as CVE-2023-4863, was reported by the Apple Security Engineering and Architecture team and Citizen Lab.

  • @KerfuffleEnglish
    6•9 months ago

    The timing and similarity highly suggests this is a problem with how almost all software has implemented the webp standard in its image processing software.

    Did you read the article or the post? The point was that both places where the vulnerability was found probably used libwepb. So it’s not that there’s something inherently vulnerable in handling webp, just that they both used the same library which had a vulnerability. (Presumably the article was a little vague about the Apple side because the source wasn’t open/available.)

    given that the programs processing images often have escalated privileges.

    What? That sounds like a really strange thing to say. I guess one could argue it’s technically true because browsers can be considered “a program that processes images” and a browser component can end up in stuff with escalated privileges. That’s kind of a special case though and in general there’s no reason for the vast majority of programs that process images to have special privileges.

    • @[email protected]English
      2•9 months ago

      So it’s not that there’s something inherently vulnerable in handling webp, just that they both used the same library which had a vulnerability. (Presumably the article was a little vague about the Apple side because the source wasn’t open/available.)

      I don’t think it’s inherent to how webp is processed, just a common denominator somewhere between Chrome’s implementation (which uses libwebp) and Apple’s proprietary implementation (which might or might not use libwebp). Whether Apple uses libwebp or not, it still has important implications that the most common methods to implement webp support were vulnerable: if the problem is with libwebp, well a shitload of software uses libwebp. If the problem is with some proprietary Apple code and libwebp at the same time, well that’s also concerning.

      That sounds like a really strange thing to say.

      I was thinking specifically of core OS functionality that uses image processing: file browsers that use thumbnails/previews, lock screens/screen savers/login screens that display images over stuff that shouldn’t be visible, notification panels that might show thumbnails, etc. Browsers are at least sandboxed, but I’m not sure the same is always true of everything else that needs to process image data.