Google repareert voor zesde keer in 2024 zeroday in Chrome

Google heeft een Stable-release van Chrome 125 uitgebracht. In die versie is een bug gerepareerd waarvan Google zegt dat er een publieke exploit van bekend is. Details over die mogelijke uitbuiting ontbreken. Het is inmiddels de zesde zeroday die dit jaar in de browser is gevonden.

Google schrijft dat het Chrome 125.0.6422.60 en 125.0.6422.60/.61 voor Linux, Windows en macOS heeft uitgebracht. In de release zitten meerdere bugfixes, maar er worden ook negen kwetsbaarheden opgelost. Vier daarvan zijn door externe onderzoekers aangedragen via Googles responsible-disclosureprogramma. Van die bugs is er eentje waarvan Google zegt dat er een publieke exploit bestaat. Dat is CVE-2024-4947, een type confusion in de V8-JavaScript-engine in de browser.

Volgens Google is het voor aanvallers mogelijk om op afstand code uit te voeren in een sandboxomgeving als een slachtoffer op een aparte phishingpagina klikt. De bug wordt als een hoog risico ingeschat, mede omdat Google dus zegt dat er een publieke exploit beschikbaar is. Daarover zijn echter geen details beschikbaar; Google noemt niet welke exploit het is en zegt ook niet of de bug actief wordt misbruikt.

Het is de derde keer in slechts een paar weken dat er een zeroday wordt gerepareerd in Chrome. Eerder bleek er ook al een bug, CVE-2024-4761, in de V8-engine te zitten. Dat was een out-of-bounds-writekwetsbaarheid. Het is inmiddels de zesde zeroday die Google dit jaar in de browser moest repareren.

Reacties (25)

[wildhagen]

Zover ik begrijp zit het lek niet alleen in Chrome, maar ook in Chromium, en zijn andere Chromium-based browsers, zoals Edge, Vivaldi, Brave etc ook kwetsbaar.

Voor in ieder geval Edge heeft Microsoft gisteren een nieuwe versie uitgebracht, waarin dit lek gedicht zou moeten zijn. Dit is versie 124.0.2478.109. Zie voor meer info het Security Bulletin van Microsoft: https://msrc.microsoft.co...lnerability/CVE-2024-4947

[GertMenkel]

Wat ik dan weer niet snap is dat Google dit soort patches niet coordineert met Microsoft en alle andere bedrijven die Chrome-forks uitbrengen (Opera, Vivaldi, etc.). Dit soort 0days zitten daar ook in, dan kunnen ze prima die bedrijven een heads-up geven en een aptch delen, lijkt me. Tenzij die bedrijven niet de tijd hebben om dit soort patches snel uit te brengen, natuurlijk.

Nu is Chrome en Chromium veilig, maar zijn Edge en alle andere Chrome-likes nog keihard kwetsbaar voor een actief misbruikt lek.

[DDX]

Dat doen ze volgens mij ook wel, iig Edge heeft gisteren/vandaag ook een update gekregen.
Zie ook reactie van @wildhagen

[Reactie gewijzigd door DDX op 23 juli 2024 01:35]

[Vexxon]

Die wijzigingen komen vanzelf in Edge lijkt me, maar ik waarom denk je dat dat niet zo is?

[Reactie gewijzigd door Vexxon op 23 juli 2024 01:35]

[kodak]

Zorgen dat security bugs bij andere ontwikkelaars bekend zijn en zorgen dat er updates uitgebracht worden zijn verschillende dingen.

Google geeft ontwikkelaars van Chromium en andere Chromium-based browsers informatie zodat ook die updates uit kunnen brengen. En andersom lijkt dat ook te gebeuren.

Er lijkt alleen geen gezamenlijke behoefte te zijn om de updates gelijktijdig uit te brengen. Wat niet alleen aan Google zal liggen. Ontwikkelaars kunnen niet zomaar aan elkaars verwachtingen voldoen. Zo zal Microsoft niet zomaar updates buiten hun patch tuesday uitgeven en andersom zal Google niet zomaar hun wil aan afgeleide software opleggen.

[Triblade_8472]

Huh? Edge is gewoon op Chromium gebaseerd. Als Google Chromium patched krijgt Edge die ook mee.

Het is alleen aan Microsoft om de changes te bestuderen en wel- of niet mee te nemen.

Andersom is het overigens ook het geval met Chromium -> Chrome.

[mphilipp]

Google hoeft MS niet persé te bellen dat er een lek gedicht is. Dat krijgen zij vanzelf door. En zij zien ook die CVE's voorbij komen, dus ze zijn op de hoogte.

En wie weet is er een vorm van coördinatie aanwezig, maar volgens mij zijn er vele forks, dus is het voor die forkers een kwestie van de boel in de gaten houden. Ze krijgen vast een pingetje als er iets in de source wijzigt.

[mutsje]

omdat soms Google Chrome wel geraakt is en Microsoft Edge niet. Dat was met de laatste Zero day in google het geval.

[- peter -]

Jaja, er gaat een moment komen dat men dit soort dingen in Rust gaat bouwen (of een vergelijkbare veilige taal). Ik vermoed dat er wel naar gekeken word bij Google, maar je hebt natuurlijk wel het probleem van een bestaande grote codebase, die je niet zomaar kwijt wilt cq overzet.

[Faeron]

Dan ontstaan er gewoon fouten op andere vlakken. De oplossing voor veilig programmeren zit niet in tools, maar in aandacht en kennis bij ontwikkelaars.

[brama]

Het is niet of het een of het ander. Rust biedt zeker diverse voordelen die helpen bij het veiliger programmeren. Het wil niet zeggen dat je dan maar lekker achteruit kunt gaan leunen.

[Reactie gewijzigd door brama op 23 juli 2024 01:35]

[nullbyte]

Dan ontstaan er gewoon fouten op andere vlakken

Wat een onzin argument, op het moment dat er problemen kenbaar worden moet er een structurele oplossing komen. Niks doen met "dan gaat er wel weer wat anders fout" is geen realistische intelligente optie. Er was iets met een ezel en een steen.

De oplossing voor veilig programmeren zit niet in tools, maar in aandacht en kennis bij ontwikkelaars.

Gezien de leeftijd van C en C++ is die kennis er niet. Bijna 40 jaar is blijkbaar niet genoeg voor programmeurs om veilig te leren coderen. Onzin natuurlijk, deze talen zijn onveilig doordat zij stammen uit een tijd waar security weinig aandacht had.

Hoog tijd voor wat alternatieven, zoals rust:

nieuws: Witte Huis vraagt programmeurs om alleen memorysafetalen te gebruiken

[Reactie gewijzigd door nullbyte op 23 juli 2024 01:35]

[latka]

En C# dan? Zelfs MS schrijft Office niet om in C# terwijl dat ook memory-safe is....

[_Pussycat_]

Ik zou niet eens zeggen dat het om weinig aandacht voor security gaat, een stack overflow zorgt normaal gesproken voor crashes en fouten, die altijd al een probleem waren.

Overflows voor hacks gebruiken is vaak een kwestie van heuuul precies dingen exact fout laten gaan. Maar de basis van het fout gaan was er sowieso al.

Uiteindelijk is C gewoon een erg simpele taal, die je bijna 1:1 in assembly om kunt zetten. Daarmee is een compiler makkelijk te maken, maar optimaal is het zeker niet.

[emn13]

De oplossing van dit soort fouten zit zeker niet bij aandacht en kennis bij ontwikkelaars - die aandacht is er al voor zover haalbaar. Echter, fouten en gebrekkige kennis zijn van alle tijden, en zullen niet verdwijnen. Daarnaast is het niet makkelijk dit soort fouten te voorkomen als je je software niet al in de broncode georganiseerd is op een manier die het makkelijk maakt om correctheid aan te tonen en/of goed over correctheid na te denken.

Het hele punt van goede tools+talen is dat je dat makkelijker maakt. Fouten maken blijft menselijk, maar goeie werkwijzes zorgen ervoor dat de impact lager is; ipv een RCE misschien "het compileert niet eens meer" of opvallende waarschuwingen, runtime asserts etc.

Het is absoluut essentieel dat we blijven investeren in verbeteringen op dit punt; het is een van de enige middelen die werkt.

Op maatschappelijk vlak kun je je afvragen of meer transparantie en aansprakelijkheid niet bedrijven zou kunnen stimuleren om dat soort keuzes wat vaker te maken - nu zijn risicos door zeer beperkte aansprakelijkheid en routinematige non-transparantie immers heel makkelijk verborgen, dus de financiele prikkel om mee te werken aan structurele verbeteringen is maar zwak.

[Reactie gewijzigd door emn13 op 23 juli 2024 01:35]

[latka]

Als je in rust "let output = Command::new("curl").arg(param).output()?;" doet dan ben je ook gewoon kwetsbaar voor malafide user-input. Dus het lost het probleem niet op en maakt sommige zaken nodeloos complexer.

[nullbyte]

Vrijwel elke taal heeft dergelijke valkuilen als in jouw voorbeeld. Als gebruikersinvoer niet op de juiste wijze ontsmet wordt (sanitized) krijg je SQL injectie en XSS kwetsbaarheden, ongeacht de taal die gebruikt is.

Rust is veel beter bestand tegen memory overflows. En laten de meeste kwetsbaarheden daar nu op gebaseerd zijn.

Dit bewijst dat rust niet nodeloos complex is maar complex met een veel veiliger code als resultaat.

Hop, hop, niet lui zijn, coderen in rust.

[Reactie gewijzigd door nullbyte op 23 juli 2024 01:35]

[latka]

Een garbage collector met een managed runtime heeft ook geen buffer overflows.... de techniek is het probleem helemaal niet en rust met de borrowchecker is te complex voor veel programmeurs met als gevolg unsafe rust code door de borrowchecker te omzeilen.

[Maurits van Baerle]

Er zijn tegenwoordig render engines gebouwd in Rust, Servo bijvoorbeeld, maar dit is een probleem in de JavaScript engine en ik weet eerlijk gezegd niet of daar ook Rust implementaties van zijn en of het gebruik van Rust dit überhaupt had voorkomen in dit specifieke geval.

[latka]

Onwaarschijnlijk. De bulk van de fouten zitten in jitted-code en daar kan rust niets aan veranderen. Maar rust heeft inmiddels zo'n schare fanboys dat de discussie nauwelijks meer zin heeft.

[Jan Onderwater]

"Google repareert voor zesde keer in 2024 zeroday in Chrome"
Ding blijft maar kapot gaan, gelukkig dat ze zo coulant zijn

[burgt]

Alleen heb ik met de laatste versie enorme issues met geeugen gebruik, paginas blijven contstant hangen, jira is bijna niet te gebruiken zonder 3 keer op de wait knop te drukken omdat Chrome denkt dat de pagina dood is.

[emn13]

Zou weleens dit kunnen zijn; hier heb ik iig last van: https://issues.chromium.org/issues/341095522 - <select>'s met veel <option> kinderen zijn in de HTML parser in deze versie ineens absurd traag.

Opmerkelijk dat de fix al weken geleden gemaakt is, en in v126 al zit, maar ergens lijkt daar iets knullig mis gegaan te zijn.

Als je er echt last van hebt kun je tijdelijk de v126 beta gebruiken, of Firefox.

[Wim Cossement]

Ze zouden beter maken dat die stomme UI-update ons niet door de strot geramd wordt sinds de flags niet meer werken en je een CLI optie moet gebruiken.
Stop met pixels te verspillen!