Google repareert 26 kwetsbaarheden in Chrome 97 waaronder één kritieke

Google heeft in de nieuwe versie van Chrome 26 bugs gerepareerd. Een daarvan krijgt het 'Critical'-label mee. Dat is een use-after-free in de browser die door Googles eigen onderzoekers werd ontdekt.

De veranderingen zitten in versie 97.0.4692.99 van de browser. Dat is de stable-versie. Dezelfde bugfixes zijn ook doorgevoerd in het extended stable-channel. Dat is versie 96.0.4664.110 voor Windows en macOS. In de versies zijn in totaal 26 bugfixes doorgevoerd. Zestien daarvan hebben een 'High'-classificatie, en nog eens zes zijn als 'Medium' ingeschaald. Dat betreft bugs die door externe onderzoekers zijn ontdekt en aan Google zijn doorgegeven.

Een groot deel van de bugs zijn use-after-free-kwetsbaarheden. Die zaten onder andere in de Vulkan-renderingengine, in Omnibox en in de printfunctie. Ook zaten er meerdere heap buffer overflows in de browser.

De ernstigste bug is CVE-2022-0289. Die staat als 'Critical' aangemerkt, al zijn details erover niet publiek bekend. Het gaat om een use-after-free in de Safe Browsing-feature. De bug werd ontdekt door een onderzoeker van Googles eigen Project Zero-team dat naar bugs speurt. Google schrijft nergens of de kwetsbaarheden in het wild worden misbruikt. Als dat gebeurt, noemt het bedrijf dat doorgaans wel.

Reacties (14)

[witchdoc]

use-after-free-kwetsbaarheden? misschien even uitleggen wat het precies is zodat ik (en anderen) lekker lui kan zijn en het niet zelf moet opzoeken?

Use-After-Free (UAF) is a vulnerability related to incorrect use of dynamic memory during program operation. If after freeing a memory location, a program does not clear the pointer to that memory, an attacker can use the error to hack the program.
source

[Reactie gewijzigd door witchdoc op 24 juli 2024 00:10]

[R4gnax]

Lekker incomplete uitleg.
Een programma kan dynamisch om werkgeheugen vragen aan het OS (alloceren) en op dat moment moet het ook weer vrijgegeven worden als je er mee klaar bent. Dat gebeurt automatisch wanneer het programma sluit, maar tussentijds moet je dat handmatig doen. Als je om een blok geheugen vraagt dan krijg je een verwijzing terug, een zgn. pointer, naar de plek van dat blok. Het is mogelijk om wanneer dat blok geheugen vrijgegeven is per ongeluk nog steeds die pointer te blijven gebruiken. Normaal gezien leidt dat tot het OS wat daarop keihard 'nee!' roept en het programma uit veiligheidsoverwegingen afsluit met een kritieke fout. Een zgn. segmentation fault.

Maar... geheugen elke keer vanuit het OS opvragen en terug vrij geven is vrij duur qua performance. Dus wat een boel applicaties doen, is werken met een interne buffer. Het programma zelf houdt een stevige poel geheugen in reserve en doet z'n eigen boekhouding om verzoeken om geheugen-allocatie en -vrijgave via die poel te laten lopen.

Dit is waar een Use-After-Free probleem kan ontstaan: het geheugen blijft binnen hetzelfde programma hergebruikt worden, dus het OS slaat geen alarm als je die oude pointer per ongeluk blijft hergebruiken, terwijl door die alternatieve 'slimme' gebufferde geheugen-allocatie implementatie datzelfde blokje geheugen ondertussen al uitgegeven kan zijn aan een ander stuk logica binnen het programma.

Op dat moment wordt het voor een hacker puzzelen om te zien of je het programma en die slimme allocator dusdanig kunt 'sturen' naar een staat waar je met die oude pointer wat data ergens heen kunt sturen (of data vandaan uit kunt lezen!) wat niet de bedoeling zou mogen zijn.

[Reactie gewijzigd door R4gnax op 24 juli 2024 00:10]

[well0549]

Heb je hier met .net dan ook last van? Of werkt het daar anders?

Doet de garbage collector het daar automatisch?

[R4gnax]

Heb je hier met .net dan ook last van? Of werkt het daar anders?
Doet de garbage collector het daar automatisch?

In .NET kun je hier in principe geen last van hebben.
Tenzij je code gebruikt die om performance redenen terug valt op pointers, wat expliciet vereist dat je deze gebruikt binnen speciale 'unsafe' markeringen. (Naam zegt het eigenlijk al, heh?)
Of tenzij je bijv. je eigen geheugen poel opricht als buffer en deze vervolgens via de Memory<> en Span<> classes (welke eigenlijk ook veredelde wrappers om 'unsafe' en pointers zijn) direct aan gaat spreken en het heft in eigen handen neemt.

Wat je in .NET nog wel eens wilt zien is een andere vorm van use-after-free.
Wat je colloquiaal 'use-after-disposed' zou noemen. Dat heeft niets met geheugenlocaties en security te maken, maar mogelijk wel met stabiliteit en correctheid van een programma.

In .NET heb je bepaalde classes die 'unmanaged' resources afhandelen. Denk bijv. aan iets als System.IO.Stream wat om een file handle zit. Deze unmanaged resources moeten op een gegeven moment weer vrijgegeven worden. Dat doe je door de class instances te disposen. (Dit soort classes implementeren in de regel allemaal een interface IDisposable - vandaar de naam.)

Als je probeert om nadat zo'n instance ge-disposed is, er nog iets mee te doen zul je - als de developer die de class gepend heeft, het werk goed gedaan heeft (wat jammer genoeg lang niet iedereen doet) prompt een ObjectDisposedException terug krijgen.


Uiteraard zegt dit niets over de .NET runtime zelf.
Daar kunnen natuurlijk nog wel use-after-free bugs in zitten. (Hoewel, dacht ik, een groot deel van .NET tegenwoordig in zichzelf geschreven is. Dus dat zou ook nog wel eens mee kunnen vallen.)

[Reactie gewijzigd door R4gnax op 24 juli 2024 00:10]

[well0549]

Thanks voor je uitgebreide antwoord.

Ik dacht ook al zoiets, een als je gewoon bij de managed types blijft is er niets aan de hand.

Overigens is de stream denk ik nog wel veilig, alleen als je m koppelt aan file handle gebeurt er op de achtergrond natuurlijk heel wat, maar de gewone stream is denk ik wel veilig

[R4gnax]

Overigens is de stream denk ik nog wel veilig, alleen als je m koppelt aan file handle gebeurt er op de achtergrond natuurlijk heel wat, maar de gewone stream is denk ik wel veilig

De stream is zo veilig als de unmanaged delen van de implementatie die er achter ligt. Dat is het hem dan ook: het vlak waar het fout kan gaan, klein houden.

[beerse]

Sinds ik wat actiever een Chromebook gebruik, vraag ik mij bij updates van Chrome af hoe het zit met de updates van ChromeOS. Die versie zie ik in de regel mee bewegen met in ieder geval het zelfde major-nummer: Sinds gisteren dus ook versie 97-punt-nogwat. Daarnaast: Chrome en Chromium hebben ook een onderlinge afhankelijkheid. Zie bijvoorbeeld https://www.chromium.org/

ff verder gespiekt: https://chromestatus.com/features gaat wel heel erg in detail. Links kan een versie nummer worden geselecteerd. Daar staat zelfs versie 99 al vermeld. Wel zie ik daar dat de versies allemaal praktisch gelijk lopen.

[Verwijderd]

Volgens mij loopt het allemaal gelijk wat betreft de browser onderdelen (net zoals dat gebeurd op Mac en Windows). Wat mij verteld is over het onderliggende OS is dat het twee verschillende partities (harde schijven) heeft. Een is actief en de ander is passief. De passieve partitie wordt geupdate en als je herstart 'switched' ChromeOS gewoon van partitie. Hierdoor heb je ook niet die (Windows) update wachttijden.
Als de update misloopt kan je ook weer terug switchen naar de andere partitie.

Erg slim idee moet ik zeggen. Maar geen idee hoe en wanneer de updates doorkomen. Volgens mij is dat gewoon een doorlopend process zoals dat met de browser ook is.

[beerse]

Over ChromeOS kan ik vooral vertellen naar aanleiding van wat dieper onderzoek uit nieuwsgierigheid met een laptop en ChromiumOS. Na installatie van ChromiumOS heeft de opslag in zo'n laptop iets van 28 partities waarvan de meeste niet echt een praktische maat hebben.

Wel heb ik bij elkaar gesprokkeld dat het partitie gebruik qua gebruik wel vergelijkbaar is met wat vroeger met unix systemen ook gebruikelijk was: eigen partities voor van alles en nogwat. Vroeger was het om er voor te zorgen dat het vol lopen van 1 deel de opslag in andere delen niet in de weg zou zitten. Nu met ChomiumOS zie ik dat het ook voor rechten en plichten wordt gebruikt.

Daarnaast wordt het volgens mij ook gebruikt om 2 partities over elkaar heen te mounten. De onder liggende is dan read-only en bevat de gedownloade/geïnstalleerde bestanden. Daar overheen een partitie die wel beschrijfbaar is voor de gebruiker. Bij de update wordt gewoon de onderliggende partitie beschreven en blijven de wijzigingen voor de gebruiker wel aanwezig.

[Verwijderd]

Intressant, ik zat ook hier nog te lezen over de vele partities:
https://www.berrange.com/tags/chromebook/

The important partitions are
KERN-A – holds the 1st (primary) kernel image
KERN-B – holds the 2nd (backup) kernel image
ROOT-A – ChromeOS root filesystem to go with primary kernel
ROOT-B – ChromeOS root filesystem to go with backup kernel
EFI-SYSTEM – EFI firmware files – empty by default
STATE – ChromeOS user data partition

De reserveringen zijn ook interessant. Microsoft doet ook zoiets door ruimte te reserveren voor toekomstige updates. Alleen doen hun dit op de primaire (C:\) partitie wat niet zo charmant is als dit afschermen in een (voor de eindgebruiker onzichtbare) partitie.

[beerse]

Mooi verhaal achter de linkt. Maar let wel op, dat is (zeer) gedaterede informatie. Sinds 2013 is er best veel ontwikkeling geweest met ChromeOS. De routines die ooit gebruikt werden voor dual-boot chromebooks blijken geen van allen meer te werken. Naar mijn idee ook en vooral omdat het partitie gebruik door google nog wel eens wordt aangepast.

Voor het gebruik van vergelijkbare constructies op microsoft platformen: Dat zal praktisch niet gaan zolang ze gebruik blijven maken van drive-letters. Ook missen ze andere constructies die bij unix en linux al jaren ingebouwd zitten. Als ik nu zie hoe ze bij updates/upgrades met partities om gaan hebben ze nog heel veel te leren en in te halen. En misschien nog meer oude constructies op te ruimen.

[Anonymoussaurus]

Die staat als 'Critical' aangemerkt, al zijn details erover niet publiek bekend.

@TijsZonderH, zie de blogpost (voor het geval de reden erachter je niet bekend was):

Security Fixes and Rewards

Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix.

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 00:10]

[Kenhas]

Je reactie is gewijzigd dus misschien stond het anders maar wat bedoel je nu net met je post?

Er staat dat details niet publiek bekend zijn en jij reageert met (als vertaling) dat details geheim worden gehouden. Is dat niet hetzelfde dan?

[Anonymoussaurus]

Mijn quote bevat het essentiële stukje "until a majority of users are updated with a fix.". In het artikel staat niet wanneer het wél bekend gemaakt wordt.

En die edit was een typo fix.

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 00:10]