image

Kritiek lek in Google Chrome maakt remote code execution mogelijk

woensdag 7 oktober 2020, 10:06 door Redactie, 5 reacties

Een kritiek beveiligingslek in Google Chrome maakt remote code execution mogelijk, waardoor een aanvaller in het ergste geval volledige controle over het onderliggende systeem kan krijgen. Google heeft gisterenavond een nieuwe versie van de browser uitgebracht waarin het probleem is verholpen.

De kwetsbaarheid is aanwezig in het onderdeel van Chrome dat wordt gebruikt voor het uitvoeren van betalingen. Technische details over het beveiligingslek zijn nog niet gegeven, behalve dat het lek gebruikt kan worden om een use after free te veroorzaken. Vervolgens is het mogelijk om willekeurige code met rechten van de gebruiker uit te voeren. De kwetsbaarheid, aangeduid als CVE-2020-15967, werd op 11 september door beveiligingsonderzoeker Man Yue Mo van GitHub aan Google gerapporteerd. Welke beloning de onderzoeker voor zijn bugmelding krijgt is nog niet bekend.

Naast de bovengenoemde kritieke kwetsbaarheid zijn in de nieuwe Chrome-versie 34 andere beveiligingslekken met een lagere impact verholpen. Het gaat onder andere om beveiligingslekken met het stempel "high", waardoor een aanvaller code binnen de context van de browser had kunnen uitvoeren. Het is dan mogelijk om bijvoorbeeld data van andere websites te lezen of aan te passen. Ook kwetsbaarheden om uit de Chrome-sandbox te ontsnappen vallen hieronder.

Nieuwe features

Chrome 86.0.4240.75 introduceert ook verschillende nieuwe features. Zo waarschuwt de browser voor onveilig verstuurde webformulieren. Het gaat dan om webformulieren op https-sites die via een onbeveiligde verbinding worden verstuurd. Dit is volgens Google een risico voor de security en privacy van gebruikers, aangezien een aanvaller op deze manier verstuurde formulieren kan onderscheppen, lezen en aanpassen.

De nieuwe browser blokkeert ook standaard uitvoerbare bestanden, archiefbestanden en disk-images die op https-sites via http worden aangeboden. Tevens waarschuwt Chrome voor andere "mixed content" downloads die via http plaatsvinden, met als uitzondering downloads van audio-, video- en tekstbestanden.

Tevens gaat Google in Chrome 86 experimenteren met de weergave van url's in de adresbalk. Een testgroep zal niet meer de volledige url te zien krijgen. In plaats daarvan wordt alleen het domein weergegeven. Gebruikers hebben nog wel de optie om de volledige url te bekijken.

Ook start Google in deze versie van de browser met het uitschakelen van FTP. Bij één procent van de gebruikers wordt de FTP-ondersteuning uitgeschakeld. Gebruikers kunnen FTP nog wel zelf inschakelen. Met de lancering van Chrome 87 zal FTP standaard bij de helft van alle gebruikers worden uitgeschakeld. Uiteindelijk zal FTP-support in Chrome 88 volledig verdwijnen.

De nieuwe Chrome-versie wordt bij de meeste gebruikers automatisch geïnstalleerd. Aangezien er ook een kritieke kwetsbaarheid is verholpen probeert Google alle gebruikers binnen dertig dagen naar de nieuwe versie te krijgen.

Reacties (5)
07-10-2020, 10:23 door Anoniem
Use after free is zo makkelijk te voorkomen. Pointer op nul zetten, pointer controleren voor elk gebruik.
07-10-2020, 11:26 door Anoniem
Door Anoniem: Use after free is zo makkelijk te voorkomen. Pointer op nul zetten, pointer controleren voor elk gebruik.
Je gaat voorbij aan het probleem dat er niet "een pointer" is maar dat die pointer gecopieerd kan zijn in andere variabelen die je niet automatisch kunt terugvinden om ze op nul te zetten.
Talen waarin dit is opgelost door deze laag af te schermen van de gebruiker en bijvoorbeeld alles via een dubbele indirectie te doen waarbij er wel 1 pointer is die zijn altijd minder efficient. Het is dus een keuze tussen de meest optimale uitvoeringssnelheid en een extra laag die je beschermt tegen memory management fouten.
(net zoals met array bounds checking)
07-10-2020, 13:08 door Anoniem
Door Anoniem:
Door Anoniem: Use after free is zo makkelijk te voorkomen. Pointer op nul zetten, pointer controleren voor elk gebruik.
Je gaat voorbij aan het probleem dat er niet "een pointer" is maar dat die pointer gecopieerd kan zijn in andere variabelen die je niet automatisch kunt terugvinden om ze op nul te zetten.
Talen waarin dit is opgelost door deze laag af te schermen van de gebruiker en bijvoorbeeld alles via een dubbele indirectie te doen waarbij er wel 1 pointer is die zijn altijd minder efficient. Het is dus een keuze tussen de meest optimale uitvoeringssnelheid en een extra laag die je beschermt tegen memory management fouten.
(net zoals met array bounds checking)

Het maakt niet uit hoe diep er naar gerefereerd wordt, je kunt altijd testen of die pointer nul is. Een pointer naar een pointer maakt geen verschil. Een pointer wijst naar een adres in het geheugen.

Qua uitvoering maakt dat echt geen enkel meetbaar verschil. Een pointer is elementair en controle daarvan is snel.
07-10-2020, 14:11 door Anoniem
dat wordt gebruikt voor het uitvoeren van betalingen.
Dus blijkbaar is dat geen 'generieke' browser code. Ben je dan weer lekker mee...
07-10-2020, 15:28 door Anoniem
backdoors die na een aantal jaar gedicht moet worden :)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.