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
400 points (95.0% liked)
Technology
69804 readers
5302 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- 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, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years 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
whats wrong with it
There's some politics involved. Basically, everyone is rallying behind JPEGXL instead of WebP, but Google refuses to support JPEGXL in Chrome. The reasoning they gave is weak, so it's assumed that they're just trying to force the format they invented on everyone because they can.
IIRC, performance of the two formats is similar.
"everyone"
load more comments
(6 replies)
It’s a format that most major image editors don’t support. Basically, if you wanted to do anything with it, you need to first convert it to a different format. It’s the only format that has this problem.
That's fair except it's not the only format that has this problem. There's JPEG 2000 and AVIF which have even less image editor support.
load more comments
(1 replies)
load more comments
(2 replies)
load more comments
(1 replies)
load more comments
(3 replies)
load more comments
(1 replies)
Well, i think firefox 117 fixed that webp issue so i am on that one.
Specifically 117.0.1 (117.1 on android)
Good to go. Always roll with the latest version. 118.0.1
idk. The post content was not in all caps, so I am not really sure about the urgency
AGAIN?
It's last week's big libwebp vulnerability again.
Edit: this underlying vuln is why last week's CVE was such a big deal, anything using webp is at risk including a whole big pile of electron apps that everyone uses.
load more comments
(1 replies)
Sorta. OP just linked the full disclosure of the libwebp vulnerability that made the news 2 weeks ago.
But there's an even more recent vulnerability in libvpx that was announced this week, that is similar in a lot of ways (including severity).
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
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/
load more comments
(7 replies)
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.
load more comments
(1 replies)
I read this as RICE vulnerability and was confused
Yeah, Linux boys would be mad
No, how could I be mad about the truth? We'd download and run any dotfiles if the screenshot looks nice enough.
load more comments
(1 replies)
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.
load more comments
(1 replies)
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.
load more comments
(1 replies)
view more: next ›