Google repareert opnieuw twee zerodays in Chrome

Google heeft opnieuw twee zerodays in Chrome gerepareerd. De twee kwetsbaarheden zaten in de JavaScript-engine V8 en in de Site Isolation-functie en werden volgens het bedrijf actief uitgebuit. Het is de derde keer in korte tijd dat er zerodays in Chrome worden gedicht.

Het gaat om twee kwetsbaarheden die de classificatie 'Hoog' hebben gekregen, blijkt uit de changelog van Chrome 86.0.4240.198 voor Windows, macOS en Linux. Het gaat om CVE-2020-16013 en CVE-2020-16017. Er zijn op dit moment geen uitgebreide details bekend over de kwetsbaarheden. Wel zegt Google dat de eerste een foutieve implementatie is van V8, de JavaScript-engine in Chrome. De andere is een use-after-free-kwetsbaarheid in de Site Isolation-functionaliteit. Google zegt dat beide kwetsbaarheden actief werden uitgebuit, maar geeft daar geen details over. Het is dus niet bekend of de kwetsbaarheden alleen met elkaar werden misbruikt of ook afzonderlijk.

De twee lekken werden ontdekt door externe beveiligingsonderzoekers, die er een niet gespecificeerde beloning voor hebben gekregen. Een lek werd afgelopen maandag aangedragen, het andere op woensdag.

Google heeft in de afgelopen tijd vaker zerodays gepatcht in de browser. Begin november dichtte het ook al twee kwetsbaarheden in V8. In oktober bleek er een actief aangevallen kwetsbaarheid in de fontlibrary van de browser te zitten.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (18)

Overigens zijn deze vulnerabilities (net als die van nieuws: Google patcht zeroday in V8-engine in Chrome van 3 november) ook ruim binnen een week tijd in elk geval gepatched en dus ook binnen hun eigen Project Zero normen. De datums waarop de CVE's zijn aangemaakt geeft dus ook niet aan wanneer het lek gevonden is. Zo is CVE-2020-16018 bijvoorbeeld ook nog leeg, op het moment.

Bronnen:
https://vulmon.com/vulnerabilitydetails?qid=CVE-2020-16013 en
https://vulmon.com/vulnerabilitydetails?qid=CVE-2020-16017

[Reactie gewijzigd door CH4OS op 12 november 2020 11:24]

Die informatie staat ook gewoon in het gelinkte artikel van Google.

[$TBD][1147206] High CVE-2020-16013: Inappropriate implementation in V8. Reported by Anonymous on 2020-11-09

[$TBD][1146709] High CVE-2020-16017: Use after free in site isolation. Reported by Anonymous on 2020-11-07

Wel mooi dat het apart aangegeven moet worden dat Google zich deze keer aan zijn eigen richtlijnen houd.

Die informatie staat ook gewoon in het gelinkte artikel van Google.

Dat het daar ook staat, betekend niet direct dat iedereen daar naar kijkt, zoals de reacties bij het artikel van 3 november ook duidelijk laat zien. Schijnbaar leest dus niet iedereen even goed, vandaar dat ik het hier dus even vooraf al aangeef.

Wel mooi dat het apart aangegeven moet worden dat Google zich deze keer aan zijn eigen richtlijnen houd.

Dat was met het bericht op 3 november j.l. dus ook het geval. Ik begrijp dus niet waarom je deze keer zegt.

[Reactie gewijzigd door CH4OS op 12 november 2020 11:48]

De vorige keer was kantje boord en Microsoft kreeg niet eens 7 dagen de tijd, want Google speelde de informatie pas enkele dagen later door nadat ze het zelf hadden binnen gekregen.

Het is ondertussen ook al meerdere keren voorgekomen dat Google zich niet hield aan de 7 dagen voor zulke kritieke exploits, ze hebben een aantal keer de 90 dagen niet eens gehaald.

Actief in het wild misbruikte exploit, reported 06-09, fixed 20-10
https://chromereleases.go...pdate-for-desktop_20.html
Op die pagina staat er nog een met classificatie "high" waar ze ook 15 dagen de tijd namen.

Actief in het wild misbruikte exploit, reported: 22-01, fixed, 24-02. Reported 27-01, fixed 24-02.
https://chromereleases.go...e-for-desktop_24.html?m=1

Actief in het wild misbruikte exploit, reported 12-10, fixed 31-10.
https://chromereleases.go...pdate-for-desktop_31.html

Afgelopen 12 maanden zijn er een handje vol exploits die actief misbruikt werden door Google gepatched. Slechts 3 daarvan waren binnen hun eigen Project Zero richtlijnen. Het is inderdaad uitzonderlijk dat Google nu 2 keer achter elkaar zich wel aan haar eigen afspraken gehouden heeft.

Waar ik nieuwschierig naar ben is, of bijna alle exploits te maken hebben met geheugen issues. Of in ieder geval hoeveel procent van de gevallen.

De meeste exploits hebben te maken met geheugen issues. Daar is Chrome niet uniek in. Het geheugen waar een aanvaller normaal niet bij kan, wil zo'n aanvaller juist graag bij komen. Zo zorgen hackers/crackers er bv voor dat de CPU instructies gaat uitvoeren die je niet wilt.

Dit is vrij normaal, CVE's kunnen op voorhand al uitgedeeld worden aan organisaties, die ze dan gebruiken op het moment dat er een vulnerability is. De 'aanmaak datum' staat dan echter wel al vast.

Chrome heeft hun eigen "CNA" (CVE Numbering Authority), die waarschijnlijk van te voren blokken van CVE's aanvraagt bij MITRE.

[Reactie gewijzigd door dlatch op 12 november 2020 11:12]

Dit is vrij normaal, CVE's kunnen op voorhand al uitgedeeld worden aan organisaties, die ze dan gebruiken op het moment dat er een vulnerability is. De 'aanmaak datum' staat dan echter wel al vast.

Dat snap ik. Omdat bij het vorige nieuwsbericht mensen ook al snel reageerden dat het buiten hun eigen beleid (al dan niet vanuit Project Zero) zou zijn - kijkend naar de registratiedatum van de CVE - leek het mij verstandig om dat nu even voor te zijn.

Chrome heeft hun eigen "CNA" (CVE Numbering Authority), die waarschijnlijk van te voren blokken van CVE's aanvraagt bij MITRE.

Dat kan en zou mij zeker niet verbazen. Maar betekend wel dat de registratiedatum van de CVE dus niet leidend is, waar sommigen daar wel van uit gaan.

Wellicht is het zo kritiek dat de cve pas publiek gevuld wordt als een ruime meerderheid gepatched is.

Ik kijk met smart uit naar een volledige browser in Rust geprogrammeerd. De meest voorkomende bugs komen tegenwoordig in complexe programma's in C en C++ door foutjes van de programmeur betreffende geheugen.(use-after-free zoals in dit Artikel) Rust helpt de ontwikkelaar hierbij, en de kans is dan aanzienlijk kleiner.

Het zal zo zelfs zijn, dat in de toekomst C & C++ niet eens meer veilig beschouwd zullen worden voor veilige software voor de overheid, en vele bedrijven. Er is niets voor niets MISRA C en dergelijke standaarden gekomen vanwege dat mensen fouten maken. Vaak wil je in software gewoon 100% dingen afdekken, zonder dat een programmeur de mogelijkheid heeft om een fout te maken. Mensen zijn niet te vertrouwen. Ook niet met de beste bedoelingen.

[Reactie gewijzigd door Immutable op 12 november 2020 13:47]

Er bestaat al een (volledige) browser in rust toch?https://servo.org/ of lees ik verkeerd?

Servo is geen volledige browser, het is een onderdeel van.

Heb net een update gedaan naar Versie 86.0.4240.198 (Officiële build) (64-bits)
dus deze kwam na 10h vanmorgen.

Ik mag aannemen dat Google toch ook wel een eigen tak heeft die kwetsbaarheden zoekt in zijn eigen software, en die los staan van de ontwikkelaars van de software? Of kunnen er gewoon zoveel bugs in zitten dat niet 99% valt te dekken met een eigen groep die naar kwetsbaarheden zoekt ?

Het precieze antwoord op je vraag kan ik niet geven, maar zoals altijd met software development zie je dat de testers zich vooral concentreren op de recent toegevoegde / aangepaste functionaliteit. Dat je elders per abuis iets omver gooit als developer, tja... Dat wordt niet altijd gezien bij het testen.

Of Google zijn eigen tak heeft durf ik niet te zeggen. Al ga ik er wel een beetje van uit. Maar vergeet dan niet dat het dan 1 tak tegen de rest van de hacker wereld is. Die zijn natuurlijk in de meerderheid waardoor ze meer kans hebben om de fouten op te sporen. En de prijs zal in de illegale handel hoger liggen waardoor hun "motivatie" groter is om het te vinden.

Ook denk ik dat je als onderzoeker van Google nog een nadeel zou hebben. Ik denk dat die de codes al meerdere malen gezien heb waardoor je in een vast patroon komt te zitten qua denken. Een beetje als "o ja dit stukje code doet dit".

Op dergelijke bugs stuit je meestal niet bij het testen, maar eerder toevallig als een derde partij iets ontwikkelt voor jouw browser of jouw software gebruikt. Die groep is dus duizenden keren groter dan eender welk testteam dat je kan oprichten... En inderdaad, in zoveel regels code zitten er enorm veel bugs waarvan de meerderheid wellicht nooit gevonden zal worden.

Ik ben de tel al kwijt hoe vaak ik binnen de eerste 10 minuten bij het gebruik van een nieuwe website of app (bijvoorbeeld een vernieuwde bank app die "nog beter" is) reeds op fouten bots waarvan je denkt hoe die ooit door een testteam (of UAT: user acceptance test) zijn geraakt.

't is ook wonderlijk hoeveel sources ik open waarbij de editor al meteen met warnings begint te zeuren over ongeinitialiseerde variabelen, untyped pointers. etc. Sommige programmeurs zijn wel erg lui ook.