- cross-posted to:
- security@lemmy.ml
- technology@lemmy.world
- cross-posted to:
- security@lemmy.ml
- technology@lemmy.world
Any Chromium and Firefox browser prior to version 116 will be vulnerable to this, update your browsers.
You must log in or register to comment.
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.
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
? I dont like it because I’m uneducated so it’s bad, average voter
Lazy motherfuckers on this site can’t even use proper grammar when being a snarky asshole. That shit you wrote is barely coherent.
Your low intelligence is none of my concern
whats wrong with it
Try linking one and sending it to someone else. I tried it and the recipient died two days later.
That’s weird, doesn’t it usually take seven?
jokes aside what is bad 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”
why does everyone like jpegxl and why does google care if it’s foss
JPEG XL, like AVIF and HEIC and WebP, is basically a next generation format that supports much higher quality at lower file sizes compared to JPEG and PNG.
Among those four formats, JPEG XL is promising because it allows for recompression of JPEG losslessly. That means if you take an image that was already encoded as JPEG (as the vast, vast majority of images are), you can recompress with no additional loss in quality from the conversion. That’s something that isn’t true of the others.
JPEG XL also has a much higher maximum quality and specific features great for high quality image workflows (like for professional photographers, publishers, and those who need to print images). WebP, AVIF, and HEIC are good for sharing on the web, but the printing and publishing workflow support requires a few more conversions along the way.
I thought this blog post by a cloud image delivery network that played a big role in developing JPEG XL was pretty persuasive, even if they had a direct interest in JPEG XL adoption.
But aren’t jpegxl and webp meant for completely different uses? Like jpeg and png are. Jpeg is better for photos and png for graphics.
Also using “XL” in a name for an encoding which does better compression was not the smartest idea, that will surely confuse many users.
But aren’t jpegxl and webp meant for completely different uses? Like jpeg and png are. Jpeg is better for photos and png for graphics.
No. JPEG XL is designed to be better at pretty much everything than webp (which was just adapted from a video format that was designed to be really efficient at video but without touching any patents). JPEG is best at photographs at screen resolutions, and PNG is best for screenshots of computer interfaces with lots of repeated colors, and DNG/TIFF are great for high resolution and bit depth (like for professional printing and publishing, or raw image capture from the camera). JPEG XL does a good job at all of those.
Exactly why WebP is shit, and Google literally owning everything shouldn’t be normalized.
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.
I had meant to say common format. I’ve never encountered a JPEG 2000.
I’m old enough to remember when the same argument was made for PNG files. It’s a stupid argument.
WEBP is 13 years old at this point and lacks the support that PNG had 3 years into its lifetime. The benefits are marginal, and without platform support it can’t catch on. Do your research before calling someone else’s argument stupid.
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)
Good to go. Always roll with the latest version. 118.0.1
Latest is 118.0.1.
Ok, but the latest is 118.0.1
Yeah now that the parent edited their comment, mine looks silly.
:)
118.1.0, actually?
Erm, no. 118.0.1 like I said. Released in 28/09. https://www.mozilla.org/en-US/firefox/118.0.1/releasenotes/
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
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.
oh >_>
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/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 effectGood, 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)
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.
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!
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.
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.
Imma let you get to that soon but we all know RCE vulnerabillities really won the night here
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.
Click bait much???
How is this clickbait? The all-caps is a bit much, but the title contains everything you need to know. There’s nothing remotely clickbaity about it.
Ah, yes sorry for the all-caps title. I just wanted to seem a bit urgent.
Not gonna lie the all caps made it seem less urgent because I’m so used to dealing with click bait
I just wanted to seem a bit urgent.
It was kinda urgent two and a half weeks ago when this was first published. Now, not so much,
Two and a half weeks ago? I learned about it yesterday. Sorry for bothering you then.
I found these alerts so hilarious… You have no idea how many vulnerabilities are discovered by grey/blackhat hackers. Even whitehat working for the governments or contractors not reporting it to have more variety of back doors.
But ok… Update and “be” protected. 🤣
Yes but this is a vulnerability now open to the public that script kiddies are going to utilize so unless you want your data grabbed by a 14yo larper for opening an image in your browser update your browser
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).
