This is way way wider than just browsers. Anything that can display webp images is vulnerable and that includes things like MS Teams and Twitch.
this post was submitted on 29 Sep 2023
374 points (95.2% liked)
Technology
58143 readers
5014 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
Further solidifying webp as the worst image format.
The current advisory is in webm (VP8 specifically). The webp one was 2 weeks ago. ...yeah, not a good time for web browsers lately...
(edit: noticed OP actually did link the webp one, I thought it'd be CVE-2023-5217 because that's being linked elsewhere)
WebP is currently the smallest and highest quality format accepted by browsers today. I have no idea why you think so negatively of it, but it's irreplaceable until something better is widely adopted, and thus viable.
It's the best format for websites as of this exact moment.
Highest compression, not highest quality (arguably).
Also heavy compression which takes more resources to display.
Also poor compatibility outside browsers.
afaik it's basically still just VP8 in image format with added metadata, and google refuses to support alternatives because they like to own the browser market.
I think there was gonna be a webp and webm 2, but it never happened.
The only reason that’s the case is because Google axed the JPEGXL implementation
AVIF is supported everywhere and it's fantastic
load more comments
(3 replies)
It's the full disclosure of the ImageIO webp vuln from last week, this is the root cause.
Well, i think firefox 117 fixed that webp issue so i am on that one.
Specifically 117.0.1 (117.1 on android)
Yep. Fennec F-Droid 117.1.0
On the topic of Fennec F-Droid why does it still connect to various Mozilla and Google services that can track users? Is there an F-Droid browser which doesn't?
Try mull. I have heard its set to be more strict by default.
Probably so it can still support FireFox sync.
idk. The post content was not in all caps, so I am not really sure about the urgency
There's a more recent CVE as well for FF that was patched in 118.0.1: CVE-2023-5217: Heap buffer overflow in libvpx
I read this as RICE vulnerability and was confused
Imma let you get to that soon but we all know RCE vulnerabillities really won the night here
What actual like platforms does this affect and to what extent tho? Like Mac (probably not iOS which is WebKit)?
I've read elsewhere it's actually a problem with libwebp not just chrome.
Basically, anything that relies on libwebp (ie can play libwebp) is vulnerable.
https://snyk.io/blog/critical-webp-0-day-cve-2023-4863/
I wonder if it applies to devices using LockDown mode, thats shuts down a lot of nonsense in its own right...
Citizen Lab said Blastpass was discovered on the device of an employee with "a Washington DC-based civil society organization" and that it could be mitigated by Apple's Lockdown Mode. An investigation into the exploit chain continues, but researchers said it involved "PassKit attachments containing malicious images sent from an attacker iMessage account to the victim."
Edit:
Fuck my reading skill (or fuck articles listing multiple high profile CVEs)...
Blastpass is not the same libwebp CVE (blastpass, the iMessage thing, is CVE-2023-41064. libwebp is CVE-2023-4863 - although that is the chrome one, despite this affecting libwebp not chrome).
I think the whole situation is very rapidly being researched and it's all developing.
So, no idea if lockdown mode would have any effect
Good, I'm so fucking tired of this bullshit.
Nah, this bullshit is progress.
The root of this problem has always existed. Exploits have always been there, mistakes have always been there. These things are fundamentally unavoidable.
Acknowledging then, documenting them is new. Sensible disclosure is new. Companies paying for these bug bounties before they are publicly disclosed (so they can be fixed) is new.
And it's awesome. It's security. It's people working together for the betterment of everyone.
It would be amazing if people didn't make mistakes. But that isn't possible.
Openess, honesty and quickly remedying of issues is possible, and it's laudable.
So yeh, next time you get an annoying update that interrupts you're workflow. Please understand the work and reason behind the update. You can still be pissed at the interruption, but please appreciate the human reason for it.
Edit: I read "good" as "god". Idk if that changes anything
I def agree with the openess tenor of your reply. People and companies (since companies technically "are" people) need to stop valuing pride over security and safety and all the good stuff of life. Like, just fix the damn cancer, stop trying to hide it and cut off the progrssively more necrotic limbs to save face.
We don't disagree on anything, I was perhaps inelegant and non-specific in my invective.
since companies technically "are" people
This wording is some legal loophole bullshit.
I have tried to word something that disagrees with this for 30m. I can't figure it out.
This is bullshit.
But this "company is person" tries to re-humanise corporations. I think. Or something.
Have some ranting....
A company is a group of people working in the interest of themselves.
A person is generally working in the interest of themselves.
A group of people always has more power than a single person, and thus should be held to a higher standard.
It seems like Google is taking this seriously... now (assigning a 10.0. The next highest is an 8.8 for $15k). But it seems like the cve is still assigned to chrome, as opposed to libwebp (where the actual vulnerability is)
And while I appreciate the publication - the fact its a 0-day publication (as opposed to "we patched this 6 months ago") means Google hasn't taken it seriously previously (or it's be found exploited in the wild)
Current Description
Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)
By crafter webpage, does it mean it refers to anything like phishing or something a more savvy user wouldn't likely "fall for" or does that actually not matter (zero-day or whatever)
Looks like it can do RCE without user interaction other than visiting the page-- not good!
Discord, slack, MS Teams, Steam, pretty much anything. But most of them have already fixed it so if you let stuff update itself frequently, there's little risk.
Apple also released urgent out-of-band security patches for iOS and MacOS around the same time, and disclosed that it had something to o do with imag processing. Unclear whether they use libwebp or some other implementation, but they disclosed that it was being actively exploited on iPhones.
What about webview-based browsers in android phones?
As far as I'm aware this does affect Android and is not currently fixed. It's expected to be fixed in the October security patch.
This is just my memory of reading weeks ago. Someone else may know better.
The Android webview is updated through the play store as of a few years ago
I believe the libwebp is implemented at the OS level. Again someone else may know better.
So if the phone gets a security update for this at the OS level, should we theoretically be safe to use apps with any sort of browser functionality? Like some apps that don't update, or are no longer being maintained, etc
This isn't just a browser vulnerability. It's a vulnerability at a much more fundamental level, which is why it's so critical. It's a vulnerability in how almost every piece of software processes a widely supported image format, so anything that touches images is potentially at risk: browsers, chat or messaging apps, file browsers, or really anything that uses thumbnails or image previews, including some core OS functionality. On the server side, you've got anything that makes thumbnails and previews, too.
We should wait and see whether there are any practical attacks outside the browser context (maybe the malicious code needs to be placed in a web page that displays the malicious image file, or maybe they need to figure out a way to actually put all the malicious code in the image file itself). But the vulnerability itself is in a fundamental library used by a lot more software.
Not sure why you only mention Chromium and Firefox in the post text, I can only assume this vulnerability affects ALL browsers. Safari (WebKit based) is, as far as I know, the second most used browser in the world.
It's anything implementing .webp support. Though the CVE has been out for nearly two weeks already so most apps have been patched.
Actually, it’s specific to libwebp, but many things that decode webp just use this library (for example, decoding webp with the "image" rust crates doesn’t use libwebp. It does use it for encoding thought).
view more: next ›