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.
Summary:
Apple disclosed and patched an actively exploited vulnerability in its proprietary image processing library.
At the same time, Google disclosed and patched an actively exploited vulnerability in its own webp processing in Chrome.
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. Because processing webp files is such a fundamental function of any different pieces of software, there’s a concern that this is one vulnerability common to a huge set of commonly used software.
I wonder if this vulnerability is especially serious, given that the programs processing images often have escalated privileges.
At a certain point I’m left wondering the degree to which this is not a conspiracy, maybe additionally involving the other big guy three-letter agency(ies)
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.
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.
This is the best summary I could come up with:
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.
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.
Rather than Apple, Google, and Citizen Lab coordinating and accurately reporting the common origin of the vulnerability, they chose to use a separate CVE designation, the researchers said.
It is best practice for software products to track upstream libraries they depend on in order to pick up security fixes and improvements.”
The representative didn’t explain why the official CVE and Google’s disclosure did not mention the widely used libwebp library or that other software was also likely to be vulnerable.
The original article contains 546 words, the summary contains 181 words. Saved 67%. I’m a bot and I’m open source!
