Google dicht elf beveiligingslekken in Chrome voor desktops

Google brengt een update uit voor zijn webbrowser op desktops om elf beveiligingslekken te dichten. Acht van de elf kwetsbaarheden worden door Google beoordeeld als een 'hoog risico'. De update komt beschikbaar voor Linux, Windows en Mac in de komende dagen.

Update 100.0.4896.88 voor Google Chrome wordt in de komende paar weken automatisch door de browser geïnstalleerd. Gebruikers kunnen de update ook handmatig uitvoeren, zodat ze meteen up-to-date zijn.

Google maakt verder nog weinig details bekend over de kwetsbaarheden. Google houdt deze details nog even voor zich tot het merendeel van de gebruikers de update geïnstalleerd heeft. Wel heeft de techgigant bekendgemaakt door wie de kwetsbaarheden zijn ontdekt. Het waren voornamelijk externe onderzoekers die achter de beveiligingslekken in de browser kwamen.

Google heeft voor een aantal ontdekkingen ook een beloning uitgereikt is te lezen in de release notes. De beloningen variëren tussen de 1000 en 6000 dollar voor de lekken met een hoog risico. De tien lekken die door externen werden ontdekt hebben de volgende CVE-nummers: 2022-1305 t/m 2022-1314.

Reacties (35)

[zalazar]

Er is simpelweg geen GUI browser welke voldoende veilig is.
De enige redelijk veilige oplossing is wat mij betreft om via een aparte VM, Windows Sandbox, Defender Application Guard of Sandbox applicatie te browsen.
Maar er zijn waarschijnlijk niet zo veel mensen die dit ook echt altijd zo doen.
Sandboxie werkt wat mij betreft prima en het performance verlies is minimaal.
https://github.com/sandboxie-plus/Sandboxie
Het vereist wel wat settings, o.a. Downloads directory Direct of Full Access geven.
En je data directories afschermen (Blocked Access) want ook al is de data vanuit de Sandbox niet te wijzigen, malware kan het dan ook niet lezen en doorsturen.
Op deze manier heeft geen enkel Chrome lek een kans.

[Reactie gewijzigd door zalazar op 31 juli 2024 15:04]

[slowdive]

Een sandbox of virtuele machine kan ook een lek bevatten (virtual machine escape), waardoor er een doorgang is tussen het os van de machine en de applicatie in de VM.

Het probleem van alle kwetsbaarheden is dat je nooit zeker weet of er een kwetsbaarheid is die nog niet publiek bekend is. Je kunt dus wel bedenken dat je de kwetsbaarheden van Chrome binnen een VM afschermd, maar je weet nooit zeker is die afscherming zelf weer lek is.

[batjes]

Grappig genoeg was IE ( vooral 11) voor zijn tijd heel erg veilig. Hier was wel EMET voor nodig om het maximale er uit te halen. Het heeft ruim een jaar geduurd voordat de eerste exploit de sandbox van IE11 (icm EMET) uit wist te breken. De eerste paar jaar zijn de serieuze exploits die serieus schade konden aanbrengen op 1 hand te tellen. De browser kwam ook meerdere hacking competities ongeschaaft door, terwijl Chrome, Firefox en Safari al heel snel gekraakt werden.

Maar helaas wilde niemand IE gebruiken en wilde men liever Google's Chrome.

Ik blijf het jammer vinden dat Microsoft de handdoek een beetje de ring in gegooid heeft en we geen IE12 hebben gekregen, ik deed graag bankzaken via IE. Edge heeft veel van dezelfde zwaktes die Chrome ook heeft. Buiten het privacy aspect is Chrome een veiligheidsgatenkaas.

[uiltje]

Onzin, de helt van wat ik doe gaat via de browser. Ken je de XKCD grap over Authorization niet?

[Iced Maggot]

Ik vind het maar weinig geld. Ik dacht dat er hogere bedragen werden uitgekeerd voor dat soort zero days.

[sourcecode]

Het is laatse tijd wel gatenkaas bij chrome.
Wees geen local admin tenzij je het echt nodig heb.............

[Globber]

Beetje onzinnige opmerking, het is een typisch gevalletje van 'je hoort er van, dus het lijkt alsof het alleen daar is'.

[batjes]

Chrome voert al vele jaren de ranglijst van meest exploitbare browser aan. Het was meestal ook de eerste browser die onderuit ging op de hacking competities.
Firefox doet het gemiddeld heel wat beter.

Het komt vooral door de focus die developers leggen. Chrome moest en zou de ranglijsten van de snelheids statistieken aanvoeren en dan worden er keuzes gemaakt.

Hetzelfde zag je b.v. bij Intel en AMD. Achteraf was Bulldozer helemaal zo slecht nog niet.

[TheMaurice]

Internet Explorer 9 doet het wat dat betreft een stuk beter. Die browser is van dusdanig hoge kwaliteit dat er überhaupt geen updates meer voor nodig zijn. Heb 'm op mijn PC al 4 jaar draaien met 0 updates

[Godson-2]

Ik vind het diep teleurstellend dat er een vrijwel oneindige reeks met beveilingsupdates nodig zijn om een browser veilig te houden. En dan alleen nog maar totdat de volgende beveiligingsfouten gevonden worden.

Het wordt tijd om Chrome te herschrijven in een memory-safe language zoals Rust. Aanzienlijke delen van Firefox zijn al in Rust geschreven en die delen vind men vrijwel geen fouten meer.

[Reactie gewijzigd door Godson-2 op 31 juli 2024 15:04]

[inversions]

Ik heb me nooit in Rust verdiept, maar Is Rust en al zijn libraries dan geheel in Rust geschreven? Zo niet dan gaat je gedachte al mank.

[dec0de]

niet alle libs zijn in rust geschreven, maar alle data die in en uit rust gaat naar een andere taal wordt altijd gesanity-checked. Daarbij is er een hele sterke drang in de rust community om voor alles een alternatief in rust te schrijven.

[VDB Computers]

Dat klinkt als een mooie utopie, echter kun je het opnieuw schrijven in welke taal dan ook er zullen altijd manieren gevonden om misbruik te maken, is het niet links om danwel rechtsom.

Ik juich het enkel toe dat dit soort partijen zo actief met security bezig zijn!

[uiltje]

Da's ook te makkelijk gesteld. Het is wel degelijk zo dat sommige programmeer omgevingen objectief veiliger zijn dan anderen. Een strongly typed language zal over het algemeen veiliger zijn dan een weakly typed language. Een language die trucks heeft om null pointers te vermijden net zozeer. En een language die pointer arithmetic toe staat... tja.

[SkyStreaker]

Leuk idee, software is ook maar zo dicht als de hardware waar het op draait en de situatie waarin zij zich bevinden. Laten we zeggen: ketting, zwakste schakel.

[Reactie gewijzigd door SkyStreaker op 31 juli 2024 15:04]

[mocean]

Blijkbaar is de test- en codereview--keten gewoon niet op orde. Het tempo waarin nieuwe features moeten worden toegevoegd is m.i. veel te hoog (met te weinig tijd per change).

Daar zou volgens mij wat aan moeten gebeuren.

[Luchtbakker]

Ik vind het diep teleurstellend dat er een vrijwel oneindige reeks met beveilingsupdates nodig zijn om een browser veilig te laten zijn. En dan alleen nog maar totdat de volgende beveiligingsfouten gevonden worden.

Laat me je uit je droom halen. Geen enkel product is bug-vrij. En dat zal het ook nooit worden. Waar gebruikers zijn, zijn ook misbruikers. Zolang iets geld oplevert zullen er altijd lekken gevonden worden die soms actief misbruikt worden.

[sig69]

Garbage collection heeft echt helemaal niets met beveiliging te maken.

[scalfirura]

Ik heb je bericht nu 3 keer gelezen, maar beweer jij serieus dat het Java framework (of C#) vrijwel nooit bugs hebben die tot security flaws kunnen lijden?

Links of rechts om is je theorie gewoon kortzichtig om het zacht uit te drukken. Alle talen / frameworks hebben met enige regelmaat security patches nodig, om veilig te blijven, ieder framework wat beweert dat hij (vrijwel) onkwetsbaar lult gewoon uit zijn nek en zou je per definitie met argwaan moeten benaderen.

Vergeet ook niet dat moderne browsers zeer complexe applicaties zijn geworden, het is alleen geen simpele app van pak 'm beet 2000 lines of code, het is bijna een compleet OS.

[Prince]

Ik ben het helemaal eens dat Rust een mooie taal is en vooral -en daar doel je op- goede compilers heeft die van de grond af geschreven zijn met security in gedachten. Dit lost veel op, maar het is net te hoog gegrepen om te beweren dat dit dan nooit meer fouten zou geven.

In Rust zelf worden zelfs security errors gevonden en dan nog wel van standaard library's.
bvb https://www.cve.org/CVERecord?id=CVE-2022-21658

Je moet dus ook bij rust je compilers updaten, software hercompileren en zoals je zelf helemaal terecht aangaf, ook oppassen voor logische fouten en fouten uit andere library's.

[Godson-2]

Ik beweer ook niet dat er nooit meer fouten zullen zijn, maar geen geheugen-gerelateerde fouten in ieder geval en dat is 75% van alle fouten die een overname mogelijk maken.

[Janbraam]

Zo zie je maar dat ook jij @Verwijderd fout(jes) maakt.... @Godson-2 heeft het over Rust, jij over Ruby.... Slechts twee letters verschil...

[oef!]

Als je op dit soort dingen inzoomt dan zijn het altijd de processen die in een tab draaien. Een Word bestand in je browser openen tikt met gemak 150mb aan (in Edge).

Browsers zijn tegenwoordig praktisch een losstaand OS. Websites kunnen volledige applicaties bevatten die veel/alle resources vreten.

[Globber]

Overdrijven is ook een vak, als Chrome bij jou 32gb gebruikt heb je óf te veel tabs open staan (zo'n iemand die 100-200 tabs open heeft, dan is het echt je eigen schuld) óf er is iets mis met je PC.

Browsers (ja niet alleen Chrome, ik weet het wat moet je nu meuk noemen en boos op zijn) gebruiken inderdaad veel geheugen, maar dat komt ook omdat de meeste browsers een stuk meer zijn dan een interface naar een website. Een browser heeft tegenwoordig gewoon veel meer functies dan simpel een website bekijken, dus dan ga je automatisch ook een stuk meer geheugen gebruiken. Jij roept dat het allemaal onnodig is, maar je vergeet daarbij dat de doelgroep van Chrome vrij groot is. Daarom moet je dus wel veel functies toevoegen (die dingen waar jij meuk tegen schreeuwt).

Niet iedere gebruiker is immers hetzelfde. Neem een developer console: ik gebruik die nooit, dus wat mij betreft is iedere byte aan geheugen die wordt gebruikt onnodig. Tegelijkertijd gebruik jij misschien de password manager niet, die ik wel weer gebruik. Conclusie is dus dat je heel veel functies hebt die moeten werken, en alles modulair en 100 instellingen geven over het algemeen gewoon niet de meest gebruiksvriendelijke manier van ontwerpen is.

[computerjunky]

Lezen is ook een vak... Nergens zeg ik dat Chrome 32 gb gebruikt maar 6 tot 8 gb os voor Chrome niets bijzonders en als je gales heb doe 8 tot 12 gb nodig hebben en 16 gb ram in je pc hebt... En dan negeren we nog het steeds grotere gebruik zonder reden van windows (die in realiteit maar 650 mb nodig heeft maar 3 gb niet vreemd meer vind).

En waarom is het mij schuld als het bij alle andere browsers wel kan. Bij Firefox gebruik ik zelfs geen tabs maar nieuwe vensters en die is niet zo hongerig.

[batjes]

Is een keuze. Google kiest er bij Chrome voor om zo veel mogelijk meuk in het geheugen te plaatsen, dan hoef je niet te wachten om data van storage ergens op te halen. Dat maakt de browser een stuk sneller in gebruik. Ook de opzet van multithreaden komt er op neer dat elk tab zijn eigen losstaande browser venster is. Wat de stabiliteit weer ten goede komt.