Google dicht voor derde keer in maand tijd actief misbruikte lekken in Chrome

Google heeft een beveiligingsupdate uitgebracht voor Chrome waarmee twee actief misbruikte kwetsbaarheden zijn gedicht. Details geeft Google nog niet, naast dat het om use after free- en information leak in core-lekken gaat.

De update fixt vier beveiligingsproblemen, waarvan twee kwetsbaarheden in de praktijk zijn misbruikt. Het gaat om CVE-2021-37975 en -37976 die actief werden misbruikt. Eerstgenoemde maakte use after free in Chromes JavaScript-engine V8 mogelijk en was door een anonieme onderzoeker ontdekt. De tweede kwetsbaarheid was door Google-onderzoekers ontdekt. Beide kwetsbaarheden werden eind september aan Google gecommuniceerd.

Het derde lek, dat voor zover Google weet nog niet actief werd misbruikt, betrof een use after free-kwetsbaarheid in Safe Browsing. Deze kwetsbaarheid werd door een onderzoeker van de Qi'anxin Group ontdekt. Over de vierde kwetsbaarheid wordt nog niks gedeeld.

Pas als een groot deel van de gebruikers de 94.0.4606.71-update geïnstalleerd hebben, wil Google meer delen over de kwetsbaarheden. Het is de derde beveiligingsupdate in een maand tijd waarmee actief misbruikte kwetsbaarheden gedicht worden. Daarmee is met de update ook het dertiende actief misbruikte lek van 2021 gedicht.

Reacties (18)

Dit is niet echt iets nieuws—we (Chrome) hebben in september inderdaad vier Stable channel updates gepubliceerd, waar april en juni eenzelfde aantal zagen. Op basis van het afgelopen jaar lijkt het maandelijkse gemiddelde drie updates te zijn.

Chrome is (1) een open source project dat (2) door miljarden mensen gebruikt wordt, met als primaire functionaliteit om (3) onbetrouwbare inhoud van derde partijen uit te voeren en weer te geven. Samen maakt dat het project een zeer interessant doel voor beveiligingsonderzoek, en daar betalen we ook voor. Het lijkt me zelfs wenselijk om updates sneller naar gebruikers uit te rollen, één van de redenen waarom we de releasefrequentie verlagen van zes weken naar vier.

Zoals @- peter - benoemd is het kijken naar andere talen inderdaad een optie, maar dat is lang niet altijd de juiste oplossing. Fuzzing, sandboxing, statische analyse, run-time analyse, investeren in betere, veilige opties in de C++ standaard alsmede ideeën zoals MiraclePtr zijn allemaal opties die aangegrepen worden. Dit zie je ook vaak terugkomen in de release notes .

Was dat in april en juni ook ivm even ernstige actief misbruikte lekken?

Praktisch elke release heeft zulke fixes, en die worden doorgaans in de notes vermeld, maar vaak ook in de changelogs als er (nog) geen CVEs aan verbonden zijn.

Het is niet altijd makkelijk vast te stellen of iets actief misbruikt wordt; veel lekken worden op de zwarte markt verkocht, of zelfs buiten de zwarte markt. Soms worden ze héél nauwkeurig toegepast zodat er op schaal niets te vinden of meten is. In mijn ogen is het beter om als standpunt aan te nemen dat zodra een lek bekend is het misbruikt kan worden, en op die basis zo snel mogelijk te handelen.

Ik dacht dat het open source project chromium was en dat chrome een software distributie is van chromium met extra google dingen. Zijn die google dingen ook open source? Want dat kan ik niet vinden.

Die use after free bug zal wel ernstig zijn geweest voor de ernstigheid "high", aangezien er $20.000 is uitgekeerd. Dat is volgens mij één van de grootste bedragen die zijn uitgekeerd in de laatste stable releases. Daarbij zijn de N/A en TBD fixes natuurlijk niet in meegenomen, dus wat dat betreft is het een beetje onzeker. In augustus is er ook een use after free bug ontdekt die een onderzoeker heeft ontdekt. Deze onderzoeker heeft er toen ook $20.000 voor gekregen: https://chromereleases.go...pdate-for-desktop_31.html.

Je zou toch verwachten dat men intern naar Rust of iets dergelijks over stapt. Die memory bugs blijven steeds voor problemen zorgen, ook al zullen ze goede tooling hebben voor detectie.

Overstappen op een andere programmeertaal doe je niet zomaar, helemaal niet met een taal als Rust waar je allerlei trucs uit moet halen voor binaire compatibiliteit met andere programmeertalen. Daarnaast moet je natuurlijk je programmeurs intern opnieuw opleiden om het efficiënt te gebruiken (want veel veiligheid in Rust gaat ten koste van performance, dus moet je goed weten welke code je wel of niet kan gebruiken op veel plekken).

Daarnaast heeft Rust ook beperkingen, zoals de enorme complexiteit die je nodig hebt om binaire bomen te bouwen die in veel algoritmes nog steeds het efficiëntste werken. Veel C libraries bestaan nog niet in voldoende volwassenheid dus zullen met de hand geschreven moeten worden of er moeten bindings geschreven worden die dezelfde kwetsbaarheden achterlaten achter de C-muur. Voor formaten waar de library in feite de standaard bepaalt (daar zijn er minstens twee van op afbeeldingsgebied) is dat helemaal veel week.

Rust is een goede taal voor dit soort dingen, maar het is geen heilige graal. Dat gezegd hebbende wordt er al wel met Rust geëxperimenteerd in Chrome, maar zelfs al zou nu iedereen fulltime worden gezet op het omzetten van de oude C++ code naar Rust dan zou het vertalen nog maanden als niet jaren duren. Chromium heeft 34 miljoen regels code (waarvan een gedeelte vast autogegenereerd is), dat herschrijf je niet zomaar even.

Google wil liever hun bestaande C++ code base veiliger maken, dat scheelt ze miljoenen. Dat is ook een van de redenen dat ze veel tijd en geld investeren in projecten als fuzzers, compilers en codeanalyse.

Heeft ook weinig zin om over te stappen. Rust is mooi, maar echt niet perfect (en nog vrij nieuw).

Chrome is nu het meest lucratieve doelwit in de browsermarkt om aan te vallen. Ze ontkomen er niet meer aan, hoe goed ze hun best ook doen, welke taal ze ook gebruiken, hoeveel ogen ook naar de code kijken. Gaten gaan gevonden worden.

Elke keer je applicatie herschrijven in de latest and greatest language is gewoon niet te doen. Oa Golang en Rust zou ik ook meer beschouwen als onderzoekstalen, want er zijn gewoon lastige onderwerpen die bekeken moeten worden voordat het echt toepasbaar is. De use-after-free is gewoon een lastige om op te lossen en de deadcode detectie is over de jaren echt stukken beter geworden door deze situaties in de AST te detecteren. Je kan sinds een paar jaar met flags ook memory address en gebruiken laten sanitizen waardoor use-after-free gedetecteerd moet worden.

Je moet het alleen wel aanzetten en is ook niet iets wat je even doet door potentiële neveneffecten. Je zal dus een bepaalde volwassenheid moeten hebben qua testing, linting en code scanning voordat je hier aan kan beginnen. Nu steekt Google er zelf al veel tijd in, maar ik verwacht dat ze nog wel de rest van dit decennium nodig hebben om voor Chromium en de meeste winst zal zitten in het kunnen droppen van support voor oude formaten en bibliotheken.

De volgende echt grote stap is als we daadwerkelijk compilers en code wiskundig kunnen bewijzen, maar dat is een kostbare onderneming. We zullen daarvoor flink wat veranderingen moeten doormaken. En tot die tijd is het niet zo erg dat bugs in Chromium naar voren komen als daarmee browsers zoals Chrome, Edge, Opera, etc allemaal tegelijk geholpen worden.

“Waarom is er nog brand? Huizen zijn toch van steen?”

De fundamenten van het internet wankelen. Er is een nieuwe security architectuur nodig.

Er is absoluut niets mis met de fundamenten van het internet vanuit een security oogpunt. De zwakheden zijn 'gepathed' met extra laagjes/diensten, bovenop diezelfde fundamenten van het internet.

De fundamenten van het internet wankelen o.a. dankzij Google.

Is vrij ondoenlijk en ook tevens de moeite niet waard, als je die tijd stopt in het moderniseren van het C++ gebruik haal je waarschijnlijk meer winst.

Waarom zijn er nog in Cobolt ontwikkelde applicaties in gebruik, is een vraag van hetzelfde kaliber. Een programma in een andere programmeertaal gaan schrijven betekend simpelweg de complete applicatie herschrijven, dat doe je niet zomaar, dat doe je ook niet in 1 2 3. Daarnaast is het maar de vraag of dergelijke bugs niet in Rust kunnen voorkomen en heeft Rust vast ook eigen quirks, zoals elke taal dat heeft.

Een andere optie is om te transpilen inderdaad, maar dan weet je ook niet of het helemaal perfect gaat. Best practices voor C++ hoeven niet per se op te gaan voor Rust of welke andere taal dan ook.

[Reactie gewijzigd door CH4OS op 1 oktober 2021 13:30]

Als Google een lek (in de browser) dicht, is het altijd in Chrome (hun brand). Maar worden de meeste van deze lekken niet gedicht in Chromium?
Dat betekend namelijk dat het lek voor alle op Chromium gebaseerde browsers wordt gedicht en niet alleen in Chrome.

Chrome is een fork, hier werkt Google zelf op. Veel werk wordt naar Chromium overgezet, maar niet alles.

Bij Chromium is Google 1 van de vele developers. Al zijn ze ook daar eindredacteur, tot nu toe lijken ze geen commits zonder goede reden te weigeren. Doorgaans zijn de commits van Google gewoon de commits voor Chrome. Net als dat de Chromium commits vanuit Microsoft gewoon de 'vrijgegeven' commits van Edge zijn.

Nu volg ik het allemaal al een tijdje niet zo veel meer, maar dat was dacht ik +/- hoe het ongeveer werkte

Use After Free verwijst specifiek naar de poging om geheugen te benaderen nadat het is vrijgemaakt, wat een programma kan doen crashen of, in het geval van een Use-After-Free fout, mogelijk kan resulteren in de uitvoering van willekeurige code of zelfs volledige code-uitvoering op afstand mogelijk kan maken.

[Reactie gewijzigd door Evert de Wit op 1 oktober 2021 13:16]

Hebben we het hier over Google Chrome of Chromium de browser engine?

[Reactie gewijzigd door Peran op 1 oktober 2021 19:37]