Google waarschuwt voor ernstige kwetsbaarheid in WebP-bestandsformaat

Google waarschuwt voor een ernstige kwetsbaarheid in bestandsformaat WebP. Daardoor zijn er verschillende andere bedrijven die als reactie patches voor die bug hebben uitgebracht, waaronder LibreOffice.

De bug is een heap buffer overflow in WebP, het bestandsformaat dat door Google is ontworpen maar inmiddels in veel andere software wordt ingezet. Aanvallers konden de kwetsbaarheid misbruiken door een lossless WebP-bestand te maken waarmee de libwebp-library code kan schrijven die uit de buffer kan ontsnappen. Die bug werd oorspronkelijk door beveiligingsonderzoekers ontdekt en is intussen door Google verholpen.

Google heeft de nieuwe bug een rating van 10/10 gegeven, wat aangeeft dat uitbuiting grote gevolgen kan hebben. Zo is het mogelijk om apparaten te laten crashen, maar ook om data te extraheren en uiteindelijk mogelijk om code uit te voeren. Vorige week speculeerden andere beveiligingsonderzoekers al dat de kwetsbaarheid mogelijk in de praktijk werd misbruikt door Pegasus-spywaremaker NSO Group. Daarover schreven die onderzoekers een beschrijving van de exploitketen, waarin de kwetsbaarheid werd misbruikt.

Google waarschuwde vorige week al voor de bug. Het bedrijf legde daar CVE-2023-4863 voor vast, een bugmelding die specifiek gold voor de implementatie van WebP in Chrome. Daar kreeg het bedrijf echter veel commentaar op; door de registratie van die specifieke bug leek het alsof de bug alleen in Chrome voorkwam maar dat andere diensten met WebP-integratie geen risico lopen. Dat bleek echter niet het geval; de buffer overflow was ook in andere software te triggeren, zoals in Microsoft Teams en LibreOffice. Die laatste heeft inmiddels een fix uitgebracht. Ook andere diensten hebben dat gedaan, maar Google kreeg alsnog kritiek op de beperkte informatie die het bedrijf gaf over de kwetsbaarheid. Daarom heeft Google de bugmelding opnieuw geregistreerd onder CVE-2023-5129. Daarin noemt Google dat de bug in WebP en niet alleen in Chrome zit en geeft het bedrijf meer details over hoe de bug kan worden uitgebuit.

Reacties (64)

[WeeJeePee]

Heeft de gemiddelde persoon hier iets van te vrezen of niet?

[Aaargh!]

Ja.

Dit wordt b.v. veel gebruik op Android toestellen, dus als je een niet-geupdate toestel en iemand stuurt je een webp bestand via b.v. een instant messenger...

Libwebp wordt ook gebruikt in allerlei forks van Chromium. Denk b.v. aan Electron apps die allemaal hun eigen kopie van Chromium meeleveren, die moeten dus allemaal individueel geüpdatet worden.

[Reactie gewijzigd door Aaargh! op 23 juli 2024 12:28]

[Dreamvoid]

Teams, Discord, Twitch, allemaal kanalen waar je eenvoudig mee een plaatje naar iemand kan versturen. Dit is behoorlijk ernstig.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 12:28]

[84hannes]

Ach, libwebp.so updaten en alle apps zijn weer veilig toch?

/Skeptic
Ik haat op dit soort momenten hoe elke applicatie zijn eigen kopietjes van dezelfde libraries heeft

[Dreamvoid]

Tsja, we wilden toch allemaal van de dependency hell af?

[R4gnax]

Inderdaad /skeptic.

Kijk bijv. eens naar Valve en Steam.
Hangen al jaren lang op een enorm out-of-date versie van Chromium.
Ze zitten nu nog steeds op versie 85, dacht ik.

En ze verwerken gewoon creditcard etc. betalingen in dat ding.
Totaal onverantwoordelijk.
Hiervoor zou Valve moeten hangen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 12:28]

[84hannes]

Hiervoor zou Valve moeten hangen.

Dat is misschien wat grof uitgedrukt, maar het zou fijn zijn als ze een boete krijgen, het liefst voordat het mis gaat.

[Sando]

Bepaalt Valve zelf niet de content op hun eigen platform? Is het gevaar dan dat Valve haar eigen klanten zou hacken?

[84hannes]

Ik denk dat uitgevers van spellen zelf bijvoorbeeld hun plaatjes aanleveren. Als daar een malafide webp tussen zit kunnen ze daarmee wellicht de machine van gebruikers overnemen.

Aan de andere kant moet Valve die uitgevers toch al vertrouwen, want na installatie van een spelletje kunnen ze nog veel meer.

@R4gnax noemt profielpagina's; als ik middels een plaatje bij mijn profiel andere gebruikers kan hacken is dat toch wel ernstig te noemen.

[Reactie gewijzigd door 84hannes op 23 juli 2024 12:28]

[R4gnax]

Dat is misschien wat grof uitgedrukt, maar het zou fijn zijn als ze een boete krijgen, het liefst voordat het mis gaat.

Niks grofs aan als je eens objectief gaat kijken naar wat Steam allemaal op hun konto heeft mbt hun beveiligingsbeleid.

De versie van Chromium die ze embedden is stokoud en bevat meerdere security-problemen die in het wild misbruikt worden, maar ze weigeren het ding bij te werken. (Zelfs niet naar v109 die gewoon nog Windows 7 en 8 support heeft.)

Ze moesten door een security-firma gewaarschuwd worden omdat er al minstens een half jaar lang een hacker actief bezig was een anderhalf jaar oude vulnerability in de V8 JS engine te gebruiken om een proof-of-concept remote code execution exploit in elkaar te draaien voor DotA 2.

De Source engine is nog steeds zo lek als een vergiet mbt de remote code execution exploit die getriggered kan worden via malafide verzoeken om deel te nemen a/e multiplayer sessie. Hier zit vanuit de desktop Steam client een klein lapmiddel voor, maar het is wachten tot er weer (is al eerder gebeurt) een bypass voor gevonden is.

Het is meerdere malen mogelijk geweest voor gebruikers om JavaScript in hun profielpagina te injecteren, waardoor de credentials van argeloze bezoekers die toevallig op dat profiel uitkomen gestolen kunnen worden. Recent was er nog iemand die te kennen gaf hiervan weer een nieuwe variant privaat aan Valve gerapporteerd te hebben; maar er was al weken niets mee gedaan.

Tijdens één van de grote kerstuitverkopen ca 2014-2015 was er een kleine configuratie oopsie-woopsie met de CDN caching waardoor als je je accountpagina eerder bezocht had, bijv. om je wallet funds aan te vullen, deze in de public cache terecht kwam en andere gebruikers al je privé betalingsgegevens en NAW gegevens konden zien. Dag één is Valve hiervoor gewaarschuwd, maar ze hebben de kerstuitverkoop gewoon 2 weken lang door laten rollen zonder er iets aan te doen.

De architecturele opzet van de Steam client negeert bewust het gepartitioneerde systeem van per-account appdata folders wat gewoon is met Windows user accounts en mietert alles in één centrale folder. Resultaat is dat als je Steam je login gegevens laten onthouden, iedereen - elke account die toegang heeft tot dezelfde PC - automatisch met jouw account op Steam kan inloggen. Nooit fundamenteel opgelost. Paar keer een slap pleistertje overheen geplakt. Al minstens 6 keer een regressie op geweest. Momenteel al weer minstens een half jaar stuk.

Steam maakt gebruik van een Windows service component die onder de SYSTEM user draait en die dingen doet om doelbewust het security model van Windows, waar normale gebruikers niet naar applicatiefolders moeten kunnen schrijven, te omzeilen. 'Want dat is gewoon makkelijker of zo?'

Dat systeem zit er nog steeds in; ondanks dat het van begin af aan zo lek als een vergiet is geweest.
Het was heel lang triviaal mogelijk om de zwakheden in de opzet van dat gedrocht te misbruiken om van een gelimiteerde user account af, direct code uit te voeren met volle SYSTEM rechten. Valve vond dit initieel geen security probleem en wilde het niet patchen. Toen is de security researcher die dit gevonden had er publiek mee gegaan. En het eerste wat in Valve opkwam was niet om de issue alsnog te patchen, maar om deze man gerechtelijk aan te klagen en monddood te maken. Pas toen de mainstream media aandacht aan de zaak begon te geven, bonden ze in en hebben ze e.e.a. gepatched.
(Google maar eens naar "Vasily Kravets")

Overigens was hun eerste 'patch' niet eens een echte oplossing, maar enkel een pleistertje om de specifieke proof-of-concept die Kravets had gevonden, niet langer te laten werken. In de maanden daarop volgende hebben andere researchers met een triviaal aantal extra stappen telkens weer nieuwe bypasses gevonden waarmee de originele vulnerability nog steeds op dezelfde manier uitgebuit kon worden.

[Anonymoussaurus]

Die kans is wel aanwezig, zie ook https://www.security.nl/p...+zoals+WhatsApp+en+Signal. En aangezien de CVSS=score een 10 is, is het dus een zeer ernstige kwetsbaarheid.

[Reactie gewijzigd door Anonymoussaurus op 23 juli 2024 12:28]

[GertMenkel]

De score (10.0) is door Google zelf vastgesteld, maar (nog) niet extern bevestigt. Google acht dit een zeer grote kwetsbaarheid maar het kan zijn dat er een paar puntjes vanaf gaan als de CVE autoriteiten de risico's overwegen. Dat hoeft niet per se, maar nu is die 10.0 slechts een indicatie.

Hoe dan ook moet dit als de wiedeweerga gepacht worden, of dit nu een score van 8.5 of 10.0 krijgt.

[the_stickie]

Afaik komt het vaker voor dat de cvss onderschat wordt, danwel overschat.

Bovendien is het hele scoringsysteem open en rechtlijnig. Er zijn meerdere partijen die cve’s scoren en publiceren. Er is dus geen “officiële” score op dewelke je moet wachten. Theoretisch kan je, als je weet hoe de bug in elkaar zit, ook zelf de score maken.
Ik heb zelf geen weet van relevante afwijkingen tussen wat bijv Cve.org, mitre of het nist publiceren.

Zoals je zelf aangeeft is een 10 reden tot directe actie. Maar dat is een 9 of 8 ook, dus wat maakt het uit?
(Ken wel (ex) collega’s die altijd duimen voor minder dan 7 omdat je dan van pci-dss net iets meer tijd/comfort krijgt )

[GertMenkel]

Mwah, ik vind de moderne CVE-scores maar alarmerend, hoor. Erg vaak komen er erg hoge getallen uit voor dingen die ik helemaal niet zo gevaarlijk vind.

Als ik een scoresysteem zou maken, zou ik een score van 10 opvatten als "iemand kan met één netwerkpakketje kernelcode uitvoeren" zoals bij bepaalde embedded-systemen met micro-besturingssystemen nog wel eens is voorgekomen. Dat is zo'n beetje het slechtste geval denkbaar.

In dit geval is de code zelf niet zomaar bereikbaar, daar gaat eerst een hele hoop code aan vooraf. De exploit is ook niet per se makkelijk uit te voeren ("makkelijk" is subjectief, maar ik denk dat de benodigde shellcode een stuk lastiger is dan bijvoorbeeld die van Shellshock).

Ik snap dat dit voor de ontwikkelaars van libwebp zo'n beetje het slechtst-denkbare scenario is, maar vergeleken met andere hoog-scorende exploits vind ik deze nog enigszins meevallen. Met de nodige sandboxing zou de impact hiervan minimaal moeten zijn (een image-parser-proces zou geen toegang mogen hebben tot het bestandssysteem, tot gedeeld geheugen, tot zo'n beetje elke syscall, of tot het netwerk, het zou hooguit de call naar de image parser moeten kunnen laten hangen en zelfs die kan asynchroon gewoon doorgaan zodat er hooguit CPU-cycles worden verspild).

Als we alles wat eng is maar achten en negens geven, worden de vieren en vijven nooit gepatcht, ondanks dat die wel relevant blijven. Daarom vind ik dat de score van veel dingen overtrokken wordt.

Als willekeurig voorbeeld neem ik een van de nieuwste exploits in libcurl. Er kan data uit de heap gelekt worden en aan de gebruiker getoond worden doordat er een stuk geheugen te vroeg wordt vrijgegeven. Welke data wordt er mogelijk getoond? Nou, de data waar het proces al toegang tot had. Ja, in theorie kan dat betekenen dat je je private key per ongeluk in een foutmelding zet, maar heeft dit nou echt een risico van 7,5 op een schaal tot 10?

[the_stickie]

NIST heeft 'm 8.8 gescoord met deze vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Dixit de vector is de aanval "eenvoudig" en "via het netwerk" uit te voeren. Volgens google is er geen userinteractie vereist, volgens het NIST wel. Blijkt een gevalletje "verkeerde website bezoeken=Pwned".

CVSS is geen directe risico-inschatting voor een individu. Het geeft in één getalletje en een 'vector' weer wat mogelijke risico's zijn. Daaruit (en de verdere CVE info) kan ieder voor zich uitmaken of je er niets mee doet, documenteert, mitigeert of oplost.
Het helpt imo voornamelijk bij security beleid (zoals voor overheden en financiële instellingen noodzakelijk is) om eenvoudig te classificeren (bijv. "alles >=7 moet per direct opgelost of gemitigeerd zijn, danwel gedocumenteerd waarom we het niet doen"). Je moet daarbij rekening houden met targeted attacks. Als je private keys per ongeluk kunnen lekken is dat best ernstig!!! Dat vind ik zeker 7.5 waard.

Punt is dat het hele CVSS systeem de 'meting' objectiveert. Ik werk in een internetcafé, jij bij de CIA: het lijkt me duidelijk dat er ook subjectieve of indivuduele doelstellingen en afwegingen) zijn.

[GertMenkel]

NIST heeft 'm 8.8 gescoord met deze vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Dixit de vector is de aanval "eenvoudig" en "via het netwerk" uit te voeren.

Huh, dat wist ik niet, toen ik vandaag zocht was hij nog under review. Klinkt wel een stuk logischer.

bijv. "alles >=7 moet per direct opgelost of gemitigeerd zijn, danwel gedocumenteerd waarom we het niet doen"

Dat is het ding een beetje, er wordt niet echt een threshold gegeven uit de berekening. Je moet heel arbitrair gaan kiezen wil je ook maar iets doen met de score. Het beste wat je er nu mee kunt is "0 is goed en 10 is slecht" en dan misschien een kwetsbaarheid als baseline kiezen die net niet interessant genoeg is om te patchen.

De officiële tabel classificeert 7,0 - 8,9 als hoog, maar specificeert niet zoveel. De hoge kant van medium bevat ook best problematische kwetsbaarheden.

De verschillende vectoren die CVSS aangeeft zijn wel heel bruikbaar (helemaal met CVSS 4), maar ze zijn zelfs voor security professionals niet altijd even leesbaar; het is makkelijk om al die lettercodes door de war te halen. Tools en nieuws hebben het daarom volgens mij ook nog steeds over de oude CVSS 3 score om aan te geven hoe "erg" de kwetsbaarheid wel niet is.

Je moet daarbij rekening houden met targeted attacks. Als je private keys per ongeluk kunnen lekken is dat best ernstig!!! Dat vind ik zeker 7.5 waard.

Het lekken gebeurt richting de gebruiker, niet richting het netwerk of iets. Verder gaat het over een maximum van 210 bytes die net toevallig naast de foutmelding in het geheugen moeten zitten. De rapporteur van de bug gaf aan de impact op medium in te schatten.

[the_stickie]

Vanaf een (on?)bepaalde maturiteit kan je er niet omheen dat je (team) kwetsbaarheden moet gaan beoordelen met kennis van je systemen en architectuur. CVE en CVSS zijn dan belangrijke tools, al was het om te weten waar je moet beginnen . De discussie over een al dan niet 'correcte' score is wmb heel interessant, maar weinig relevant omdat elke omgeving anders is en daarmee de risico's en hun weging ook.
De 'gekozen' threshold is idd arbitrair, maar daarom niet zinloos. Je kan (soms moet) je daarbij richten op standaarden zoals pci-dss, soc2, niet csf...

[nullbyte]

op de NCSC advisory pagina staat exact bij "kans" hoe de scores berekend worden. Zoveel H/H meldingen zijn er niet. Als ik naar de geschiedenis en de impact van de kwetsbaarheden kijk dan zijn deze in mijn optiek dan ook zeker niet overtrokken.

Wel vermakelijk dat jij er anders over denkt dan zo'n beetje de gehele wereldwijde Cybersecurity community.

Webp is verweven in een groot aantal applicaties. Een forse kwetsbaarheid daarin in acht nemend lijkt een score van een 10 zeker aannemelijk.

WebP wordt door allerlei software gebruikt. Zo kwam Mozilla met updates voor Firefox en Thunderbird. Een aantal programma's is nog kwetsbaar, aldus securitybedrijf Rezilion. Het gaat om Microsoft Teams, Slack, Skype, Discord, Affinity, Gimp, Inkscape, LibreOffice, ffmpeg. Volgens Hawkes heeft ook Android met het probleem te maken.

https://advisories.ncsc.nl/advisories

[Reactie gewijzigd door nullbyte op 23 juli 2024 12:28]

[GertMenkel]

Ik zie bij de NCSC geen vermelding van CVE-2023-5129, maar wel van CVE-2023-4863 (welke dezelfde kwetsbaarheid is, maar de link tussen de twee kon ik niet direct vinden op het moment van schrijven van mijn comment). NCSC geeft hem een score van medium/medium. CVSS geeft hem een score van 8,8.

Dezelfde bug in macOS heeft een CVE-score van 7,8 maar is wel weer medium/high bij de NCSC.

CVE's zijn een hele hoop, maar consistent zijn ze niet. Dezelfde WebP-bug heeft een score van 7,8 tot 10,0 afhankelijk van wie de library gebruikt. De wereldwijde cybersecuritycommunity is niet een enkel lichaam, maar ze zijn het in ieder geval bijna allemaal oneens met de score die Google aan de kwetsbaarheid gegeven heeft.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 12:28]

[nullbyte]

Dat klopt, de advisory van het NCSC is er nog niet. Ze zullen er nog druk mee bezig zijn. Of dit is een TLP Amber of Red waarbij eerst de belangrijke spelers in NLD geïnformeerd worden. https://www.ncsc.nl/docum...24/traffic-light-protocol

CVE's zijn een hele hoop, maar consistent zijn ze niet.

Zoals ik al aangeef, je kan exact zien bij details->kans op de NCSC advisory pagina zien hoe de scores berekend worden bij het NCSC. Nu vermoed ik dat ze deze berekening niet uit de duim gezogen is, maar is door gedruppeld uit de V.S. Er is vermoedelijk dus wel enige vorm van consistentie. Maar dat is een aanname van me (the mother of...)

Als er later blijkt dat er b.v. geen gebruikersinteractie nodig is dan gaat de score omhoog. En komt er een update, dat zal nu dus ook gaan gebeuren denk ik.

NCSC:
"Onderstaande tabel geeft in detail aan hoe wij tot de inschatting zijn gekomen hoe groot de kans is dat deze kwetsbaarheid in het doorsnee praktijkgeval kan worden misbruikt. De punten worden bij elkaar geteld."https://advisories.ncsc.nl/advisory?id=NCSC-2023-0290 (Voorbeeld MS Office)

Zoals ik al aangaf, zoveel H/H meldingen zijn er niet. Het "pop-up" syndroom dat jij beschrijft, en daarbij bedoel ik het feit dat te veel meldingen niet meer bekeken worden door mensen. Is dus niet echt van toepassing.

Het is de H/H die telt en niet perse het cijfer waarnaar gekeken wordt. Een 8 M/H is nog steeds geen H/H waarbij de alarmbellen echt gaan rinkelen.

[Reactie gewijzigd door nullbyte op 23 juli 2024 12:28]

[nout77]

Is inmiddels bekend of de kwetsbaarheid in Signal en WhatsApp is gedicht? Of loop je nu gevaar een malafide webp afbeelding op je device te ontvangen? 🤔

Edit: In de Play Store zie ik dat WhatsApp de laatste update op 13 september heeft geplaatst en Signal op 21 september.

Edit2: volgens dit artikel zou in ieder geval Signal al op 13 september gepatcht zijn. Aangezien het op electron is gebaseerd, weer wat geleerd:
https://stackdiary.com/cr...webp-codec-cve-2023-4863/

[Reactie gewijzigd door nout77 op 23 juli 2024 12:28]

[Anonymoussaurus]

Ik denk dat het een patch is die in Android moet komen als ik het goed begrijp, zie https://blog.isosceles.com/the-webp-0day/.

As of today, Android hasn't released a security bulletin that includes a fix for CVE-2023-4863 -- although the fix has been merged into AOSP. To put this in context: if this bug does affect Android, then it could potentially be turned into a remote exploit for apps like Signal and WhatsApp. I'd expect it to be fixed in the October bulletin.

[GertMenkel]

Dit is hoe iOS tot korte tijd geleden zonder enige interactie gehackt kon worden via iMessage. Messengers die libwebp gebruiken en niet bijgewerkt zijn, kunnen nog op dezelfde manier worden gehackt.

Naruurlijk is er een tweede exploit nodig om uit de sandbox te breken en daadwerkelijk een risico te vormen, maar dit toont wel het risico aan. Omdat WebP een format is dat zoveel beter is dan de alternatieven (comprimeert beter dan JPEG, heeft hardwareversnelling op diverse chips, doet animaties en ondersteunt transparante achtergronden) is dit formaat heel populair voor bijvoorbeeld stickers.

[Dazzyreil]

Zelf pas voor het eerst het Webp format gebruikt omdat iemand perse plaatjes wilde hebben onder de 50kb en ik was zeer onder de indruk van de kwaliteit.

[GertMenkel]

Ik heb al een tijdje plaatjes in WebP-formaat op mijn site staan, en als je een <picture>-element gebruikt, gaat eigenlijk bijna iedereen erop vooruit.

Photoshop en een paar andere programma's en websites ondersteunen het formaat niet (helemaal), dat is waarom een hele hoop mensen een hekel hebben aan het formaat. Als je zelf kiest wat er met je plaatjes gebeurt, is het een superhandig formaat.

Alternatieven als AVIF en die nieuwe JPEG-standaard zijn nog niet klaar voor gebruik. Ik vind ze persoonlijk ook niet zo heel geweldig; redelijk hoge encoding-tijd voor magere compressiewinst of puur theoretische software-support. Over tijd zal dat vanzelf goed komen, maar voor nu zit ik heel goed met WebP.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 12:28]

[DataGhost]

Vindt de gemiddelde persoon het problematisch als opeens alle bestanden op de computer/telefoon/tablet versleuteld zijn?

[wildhagen]

Ligt eraan of de gemiddelde persoon er problemen mee heeft als zijn persoonlijke gegevens potentieel in handen van kwaadwillenden kunnen komen.

Mensen die dat geen probleem vinden hebben nergens iets voor te vrezen. Mensen die dat liever niet zien gebeuren hebben dat absoluut zeker wel.

Dit lek is exploitable en heeft een zéér hoge CVSS-score gekregen, dat geeft de ernst van het probleem ook al aan.

[vickypollard]

Is dit iets wat op Android door Google geüpdatet kan worden via de Play Store? Of vereist het echt een OS update? Ik heb een S10e waarvan, blijkbaar, de recentste update uit maart komt, dus ik verwacht niet dat daar nog iets mee gebeurt.

[Kees]

Ik gok een OS update, want ook al update je al je apps, je OS zal hoogstwaarschijnlijk ook libwebp aan boord hebben, bijvoorbeeld om een achtergrond weer te kunnen geven.

[vickypollard]

Ja, alleen Google update een deel van Android via de Play Store, vandaar

[N8w8]

Hier kan je iig zien dat de fix laatst "al" in AOSP is beland.
Wat dat dan in de praktijk betekent weet ik ook niet.
Ja AOSP is de basis van elke ROM, maar mss kunnen ze tegenwoordig ook onderdelen daarvan via de Play Store verspreiden?
En ik had begrepen dat er nog geen Android security bulletin van was, wellicht zit het in de volgende. De laatste is van 5 september en dat doen ze 1x/maand? Dus mss over 1-2 weken zeggen ze er meer over.
Zie hier.

[bewerkers]

Jammer dat Google JPEG XL weigert te ondersteunen ten behoeve van WebP. JPEG XL heeft veel potentie. Weer een geval van machtsmisbruik van Google. En nu blijkt hun opgedrongen format ook nog zo lek als een mandje.

Edit: als ik het toch over machtsmisbruik heb zijn er kennelijk weer veel Google fans aan het minnen geweest in de reacties hier.

[Reactie gewijzigd door bewerkers op 23 juli 2024 12:28]

[Dwarrelegel]

https://www.cvedetails.com/cve/CVE-2021-28026/ JPEG-XL heeft een soort gelijk probleem gehad in 2021.

Denk dat er tegenwoordig voor de meeste software, file formats etc wel grote lekken zijn geweest. Staat natuurlijk los van het tegenwerken van een opener format door google.

[bewerkers]

Juist daarom wil ik de keuze kunnen hebben tussen concurrenende imperfecte standaarden. Google belemmert de concurrentie.

[Reactie gewijzigd door bewerkers op 23 juli 2024 12:28]

[Cryothic]

"Zo lek als een mandje" is natuurlijk wel lichtelijk overdreven, nu er een bug gevonden is en opgelost is.
Het is ook weer niet zo dat er wekelijks nieuwe problemen aan het licht komen met webp.

Wel helemaal met je eens dat google in dit geval z'n macht gebruikt om eigen systemen/oplossingen te forceren ten gevolg van concurenten.

[bewerkers]

Dat is een semantische discussie. Het Tweakersartikel noemt het "zeer ernstig" en Google zelf geeft het de maximale score van 10/10. Was het alleen lek geweest als het een score van 11/10 had ofzo?

[Cryothic]

Goed punt, zal aan je beeld van de uitdrukking liggen.
Persoonlijk vat ik dat altijd op als zijnde dat er gewoon heel veel "lekken" zijn. Daarom het gebruik van het woord "mandje", want daar zitten natuurlijk gewoon heel veel openingen in. En niet 1 groot gat. Vandaar dat ik er vanuit ging dat je bedoelde dat webp "aan alle kanten lek is", zeg maar

[bewerkers]

Goed punt. We weten nog maar van 1 lek inderdaad. En die is gedicht.

[Werelds]

Hè?

Even los van hoe relevant dat is tot deze nieuwspost (niet echt), is het ook nog eens volstrekt onjuist.

#1: Google is juist één van de ontwikkelaars van JPEG XL
#2: Chrome != Google en vice versa, want:
#3: Chrome ondersteunde het al in 2021 en heeft het eind vorig jaar uit hun product gehaald omdat er geen enkel teken was dat iemand anders het ging ondersteunen (zonder feature flags) en daardoor gebruikte dus ook niemand het (daarnaast was libjxl behoorlijk buggy).

Een bestandsformaat kan alleen slagen als het breed ondersteund wordt en niemand maakte aanstalten het te gaan ondersteunen; Firefox heeft het achter een feature flag zitten en Mozilla heeft aangegeven dat ze JXL "meh" vinden. Apple ondersteunt het vanaf Safari 17...gisteren, dus. En dat is slechts gedeeltelijke ondersteuning; geen kleurprofielen, geen animaties. De meesten hadden zich al achter AVIF geschaard.

En het Chrome team heeft al aangegeven dat ze JPEG XL zullen heroverwegen als er meer ondersteuning komt.

Wat hun "opgedrongen" WebP en deze bug betreft: de bug zit specifiek in libwebp, de standaard bibliotheek, niet het bestandsformaat. Zulke bugs hebben ook in libjpeg, libpng en dergelijke gezeten - en ook libjxl.

[Reactie gewijzigd door Werelds op 23 juli 2024 12:28]

[bewerkers]

Chrome != Google

Chrome wordt ontwikkeld door Google, maar dat weet u ook wel neem ik aan. Ik snap niet dat zo'n kinderachtige post 2 punten krijgt.

Chrome ondersteunde het al in 2021 en heeft het eind vorig jaar uit hun product gehaald

Dat weet ik. Dat is exact het probleem! Veel bedrijven hadden ondersteuning voor JPEG XL net af of waren het aan het ontwikkelen, maar doordat Google onaangekondigd de stekker er uit trok ging het mis.

Een bestandsformaat kan alleen slagen als het breed ondersteund wordt

Exact. Het is een kip ei probleem. Het dient gebootstrapped te worden. En dat kan onmogelijk zolang de monopolist het weigert te ondersteunen. Dat is mijn hele punt.

[Werelds]

Chrome wordt ontwikkeld door Google, maar dat weet u ook wel neem ik aan. Ik snap niet dat zo'n kinderachtige post 2 punten krijgt.

Echter ondersteunt "Google" JPEG XL weldegelijk, ze werken nog steeds aan de library (vandaar ook dat ze de CVE vrij geven), zijn denk ik nog steeds de top contributors en het is voor een groot deel op hun werk gebaseerd (2 van de 3 hoofd auteurs van de spec zijn Googlers; de derde werkt voor Cloudinary). Het is specifiek het Chrome team dat besloten heeft JPEG XL er uit te halen; en dat is niet definitief, ze hebben al aangegeven het er weer in te willen stoppen als het nut heeft.

Dat is wat ik bedoel: Chrome maakt hun eigen beslissingen, dit is geen beslissing geweest die van hogeraf is gekomen, want dan had Google al hun mensen ook uit JPEG XL getrokken. Maar die zijn nog steeds hartstikke actief.

Dat weet ik. Dat is exact het probleem! Veel bedrijven hadden ondersteuning voor JPEG XL net af of waren het aan het ontwikkelen, maar doordat Google onaangekondigd de stekker er uit trok ging het mis.

Uh, nee. Er zijn bedrijven die hebben aangegeven het bestandsformaat te willen ondersteunen, maar wachten op de browser ondersteuning. Maar de meeste van die bedrijven hebben dat dus niet gedaan, vanwege dat laatste; en ontwikkelen hoeven ze nauwelijks, ze hoeven enkel libjxl te integreren, wat niet echt een probleem is. Ze hoeven de spec niet te implementeren.

Exact. Het is een kip ei probleem. Het dient gebootstrapped te worden. En dat kan onmogelijk zolang de monopolist het weigert te ondersteunen. Dat is mijn hele punt.

Als je daadwerkelijk objectief wil zijn, dien je vooral richting Mozilla en Apple te wijzen, niet Google. Mozilla vanwege de feature flag die al 2,5 jaar bestaat maar nog steeds niet mainstream gemaakt is, en Apple omdat ze gewoon zo godvergeten traag zijn. En wellicht ook Microsoft, omdat zij en Apple het ook niet ondersteunen in hun OS. Maar vooral Apple is hier het grote probleem, vanwege het grote marktaandeel van Safari iOS. Safari macOS is niet zo spannend, maar helaas hangt dat samen met de iOS versie. We mogen al lang blij zijn dat ze het in de browser en niet het besturingssysteem hebben gestopt, zoals ze met APNG deden, dan zou de ondersteuning op macOS nog jaren duren aangezien er nog veel Intel Macs in omloop zijn. En daar heb je meteen nog een voorbeeld waar Apple juist degene was die dat bestandsformaat in eerste instantie afschoot, totdat ze er zelf een usecase voor hadden.

Ik ben inmiddels meer dan 20 jaar webontwikkelaar en heb genoeg van dit soort dingen langs zien komen. Het is maar heel zelden dat het Chrome team degenen zijn die zoiets tegen werken; sterker nog, vaak zijn zij de eerste of zelfs de grote voorstanders. Je mag mijn reactie kinderachtig noemen, maar controleer dan eerst je statements.

[Reactie gewijzigd door Werelds op 23 juli 2024 12:28]

[Bor]

En nu blijkt hun opgedrongen format ook nog zo lek als een mandje.

In alle software kunnen kwetsbaarheden voorkomen. Dat is nu eenmaal een gegeven. Het gaat er in mijn ogen veel meer om hoe een bedrijf hier mee omgaat. In dit geval wordt er actief gewaarschuwd waardoor andere initiatieven en bedrijven hun producten ook veiliger kunnen maken. Ik vind "hun opgedrongen formaat ook nog zo lek als een mandje" een behoorlijk overtrokken reactie.

[watercoolertje]

Edit: als ik het toch over machtsmisbruik heb zijn er kennelijk weer veel Google fans aan het minnen geweest in de reacties hier.

Ja sure, de misinformatie die je post speelt zeker geen rol in je 'minnetjes'? Bijna niks van je post is waar, dus je edit zal ook wel niet waar zijn (je hebt ook geen minnetje gehad, kan je zien als je er op klikt, dus dat is ook al gelogen).

Je durft niet eens op mensen te reageren die je leugens (want dat zijn het) weerleggen, dat spreekt toch boekdelen!

En als ik nu een minnetje krijg moet ik dan huilen dat dat komt door de mensen die anti-google zijn? We zijn toch geen kleuters, kom op, stop met liegen en doe je best wat bij te dragen ipv je haat uitdragen

[Reactie gewijzigd door watercoolertje op 23 juli 2024 12:28]

[bewerkers]

Ik heb niks onjuist gezegd en al helemaal niet bewust. En al helemaal niet misinformatie (zou ik dan door JPEG betaald worden?).
Ik ben zeer bekend met de geschiedenis achter de ondersteuning van Google van JPEG XL. En ik blijf bij mijn standpunt dat Google niet een concurende standaard zo had moeten weggooien ten behoeve van de standaard die in het artikel voorkomt.

je hebt ook geen minnetje gehad

Met minnen bedoel ik de score omlaag brengen/houden van 1 naar 0. Niet perse een negatieve score geven. De gemiddelde Tweaker snapt niet hoe de moderatie hier werkt. Het gaat om of een reactie on topic is, niet of je het eens bent met de inhoud. Verder heb ik wel minnen gehad.

[Reactie gewijzigd door bewerkers op 23 juli 2024 12:28]

[Onno]

ernstige kwetsbaarheid in bestandsformaat WebP

Dit lijkt me geen kwetsbaarheid in het bestandsformaat op zich, maar in libwebp, de library die veel gebruikt wordt voor het werken met dat formaat.

[MneoreJ]

Technisch gezien klopt dat, maar praktisch gezien is libwebp de library die gebruikt wordt om WebP te verwerken, als in, er is vrijwel geen reden waarom software die WebP ondersteunt iets anders zou gebruiken (als hooguit een wrapper om libwebp heen). Het is daarom handiger om WebP als kwetsbaar te bestempelen dan de library, in de zin dat het meer mensen triggert. Kunnen mensen die dieper graven en er toch achter komen dat hun implementatie niet kwetsbaar is zich alsnog op de borst kloppen, maar dan hebben ze dat maar gedaan.

[Verwijderd]

Het is wel beter als clickbait inderdaad

[PatrickV]

apple had het ook al gevonden, en niet gerapporteerd dat het in libwebp zat.

https://arstechnica.com/s...ndspot-for-0-day-hunters/

[Rmaxx]

verontrustend lijstje wel.. slack/telegram/skype/teams... Hoe werkt dit bij zoiets als telegram? Iemand stuurt een sticker en iedereen is de sjaak? Dan kan het hard gaan met infecties.

[Cyb]

Al hoewel "Chrome" genoemd wordt, geldt dit ook voor veel andere browsers. Alle software die libwebp gebruikt, kan kwetsbaar zijn. Zo ook Firefox, waar een fix al voor uit is. https://www.mozilla.org/e...y/advisories/mfsa2023-40/ Het is vooral opletten als je op Chrome of Firefox afgeleide browsers gebruikt, die meestal iets achter lopen op Chrome en Firefox zelf.
Ook bijv. passwordmanagers en chat applicaties kunnen kwetsbaar zijn. https://support.1password.com/kb/202309/

[TweakerTom]

Klopt, en echt nog heel veel meer.
Hier een leuk lijstje om mee te beginnen.
Gaat gezellig worden met updaten...

[Reactie gewijzigd door TweakerTom op 23 juli 2024 12:28]

[ErikT738]

Kunnen we niet gewoon stoppen met dat webp-formaat en iets gebruiken waar andere programma's gewoon mee om kunnen gaan?

[sfranken]

Zoals? Elk programma heeft een lib nodig om met *elk* format om te kunnen gaan, niks is "gewoon" zo te gebruiken.

Bovendien heeft zo'n beetje elk format problemen/issues/voordelen/nadelen, bijvoorbeeld JPEG-XL, zie Dwarrelegel in 'Google waarschuwt voor ernstige kwetsbaarheid in WebP-bestandsformaat'

[ErikT738]

Ik heb geen lijst bijgehouden van wat de problemen precies zijn, maar ben een aantal keer tegen issues aangelopen. Ik begrijp zelf ook wel dat dit komt omdat de programma's die ik wil gebruiken niet met webp om kunnen gaan, en dat het probleem niet in het formaat zelf zit.

[Kaastosti]

Yes please. Het enige formaat dat gewoon in een browser werkt, maar compleet nutteloos is op het moment dat je het downloadt. En maar weer mspaint opstarten, webp openen, opslaan als png... mooi, dan kunnen we het nu effectief gebruiken.

[HollowGamer]

JPEG heeft anders ook genoeg bugs gehad.
Geen idee of dit een betrouwbare site is ervoor, maar vond het op Google:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jpeg

Hetzelfde voor PNG, etc. Het zit ook meestal niet in het formaat, maar de lib die het formaat opbouwt/bewerkt.

[beerse]

Als dat je instelling is, dan zou je nu alleen bitmaps en gifjes gebruiken zoals we dat in de begin dagen van internet gebruikten. De meeste beeld-beschrijvende-bestandsformaten zijn ontwikkelingen die ooit op deze manier zijn begonnen.

[wica]

Waarom worden er 2 verschillende cve sites gebruikt?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4863
en
https://www.cve.org/CVERecord?id=CVE-2023-5129

https://www.cve.org is de nieuwe website voor CVE's

[Anonymoussaurus]

Staat er toch bij?

Op CVE-Mitre staat duidelijk:

NOTICE: Transition to the all-new CVE website at WWW.CVE.ORG and CVE Record Format JSON are underway.

Waarschijnlijk omdat CVE's nu algemener zijn en niet alleen het Mitre dat toe kan kennen.

[wica]

Ja, dus waarom wordt in dit artikel 2 verschillende sites gebruikt?

[Anonymoussaurus]

Dat kan Tijs ook niet weten; het is niet aan hem om de CVE's te publiceren of op die van Mitre of de niet-Mitre variant.

[ReTechNL]

What apps are affected by CVE-2023-4863?
https://gist.github.com/m...03c8283f4c343c3032dd2e7ec

[shades]

Dit gaat toch alleen om het maken van een webp in libreoffice of iedere actie die die library gebruikt
En dus niet bij het bekijken al dan niet via een webbrowser?

[Reactie gewijzigd door shades op 23 juli 2024 12:28]

[Dreamvoid]

Ja het gaat om het bekijken van een plaatje in een applicatie die de libwebp library gebruikt (een browser als Chrome, Edge, Firefox, of een app die ook deze library gebruikt zoals Teams, Signal, LibreOffice etc). De browsers zijn nu gepatched, de applicaties volgen 1 voor 1.