Google dicht opnieuw zerodaykwetsbaarheid in Chrome die actief wordt misbruikt

Google heeft zijn Chrome-browser een update gegeven om twee beveiligingsproblemen te verhelpen. Een van de twee kwetsbaarheden wordt actief misbruikt. Criminelen kunnen hiermee binnen de browser verhoogde rechten verkrijgen om systemen binnen te kunnen dringen.

Het gaat om twee kwetsbaarheden waarvan Google de ernst als 'hoog' heeft geschat. De kwetsbaarheid met aanduiding CVE-2019-13721 betreft een use-after-free-probleem in PDFium, gevonden door iemand met de alias banananapenguin. PDFium is Googles opensourceproject voor het weergeven en tonen van printpreviews van pdf's in Chrome.

De tweede kwetsbaarheid is gevonden door twee medewerkers van Kaspersky en betreft eveneens use-after-free, maar 'in audio'. Het is deze kwetsbaarheid, met aanduiding CVE-2019-1372, waarvan Google aanwijzingen heeft ontvangen dat misbruik in de praktijk al plaatsvindt.

Use-after-freekwetsbaarheden betreffen problemen die manipulatie van data in het geheugen mogelijk maken, waardoor aanvallers hun rechten binnen software kunnen verhogen. Bij Chrome opent dit de weg om doelwitten een gemanipuleerde site te laten bezoeken, zo rechten te verwerven om uit Chromes afgeschermde sandbox te komen en vervolgens code te kunnen uitvoeren om systemen waarop de browser draait, bijvoorbeeld over te nemen.

Details geeft Google niet vrij 'totdat een meerderheid van de gebruikers een update met een fix heeft uitgevoerd'. Het bedrijf dichtte in maart ook al zerodaykwetsbaarheden. Toen had Google aanwijzingen dat deze als onderdeel van een keten van exploits werden misbruikt om aanvallen via Chrome uit te voeren. De update van nu brengt de buildversie naar Chrome 78.0.3904.87. Standaard ontvangen gebruikers deze automatisch.

Reacties (28)

Stable Channel Update for Desktop
The stable channel has been updated to 78.0.3904.87 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.

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. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 2 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

• [$7500][1013868] High CVE-2019-13721: Use-after-free in PDFium. Reported by banananapenguin on 2019-10-12
• [$TBD][1019226] High CVE-2019-13720: Use-after-free in audio. Reported by Anton Ivanov and Alexey Kulaev at Kaspersky Labs on 2019-10-29

Google is aware of reports that an exploit for CVE-2019-13720 exists in the wild.

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

Hier het release bericht. Vanaf 78.0.3904.87 dus veilig, check Help --> About Chrome voor de versie en updates.

De kwetsbaarheid met aanduiding CVE-2019-13721 betreft een use-after-free-probleem

Alle populaire browsers waren tot eind 2017 goeddeels geschreven in C/C++. Dit omdat een browser hoge performance-eisen heeft. Eind 2017 begin Firefox met het integreren van in Rust geschreven componenten. Een proces dat volgens mij redelijk ver gevorderd is. Bij Rust moet je wel heel raar bezig zijn (en bewust binnen een unsafe blok) wil je een use-after-free hebben. Of andersom, een use-before-initialization (ook memory leaks zouden uit de wereld moeten zijn, maar die vormen niet echt een veiligheidsrisico). Tenslotte zouden buffer overruns verleden tijd moeten zijn.
Het zou interesant zijn om te zien of deze vrij drastische overstap van programmeertaal voor minder kwetsbaarheden heeft gezorgd. Helaas is het gebruik van Firefox niet zo heel erg hoog meer. Daardoor kunnen we niet één-op-één gaan vergelijken of Firefox inderdaad minder (veiligheids)kwetsbaarheden heeft dan Chrome: een browser die meer gebruikt wordt zal ook meer klappen krijgen.

[$7500][1013868] High CVE-2019-13721: Use-after-free in PDFium. Reported by banananapenguin on 2019-10-12

Weet iemand toevallig of zulke kwetsbaarheden vaker voorkomen? Ik heb het openen van PDF's in een browser altijd beschouwd als een mogelijke attack vector, maar nooit echt nagegaan of die vrees ook gegrond is.

PDF is complex, en daardoor een rijke bron van vulnerabilities. Ik zet altijd de interne viewer uit. Onder Ubuntu heb je het voordeel dat evince onder apparmor draait, zodat de meeste exploits tandeloos zijn. En welke PDF viewer je ook gebruikt, zorg voor automatische updates (ook weer een voordeel van distro's als Ubuntu).

Ik meen wel eens eerder gehoord te hebben van kwetsbaarheden in de directe weergave van pdf-bestanden in de browser. Ik dacht bij Firefox. Inderdaad heb ik dit om die reden zelf niet aan staan. Het is iets onhandiger, maar bij mij moet een pdf-bestand echt gedownload worden, of ik bekijk het in Google Cache als ik er via Google kom.

Er is niet voor niets een standaard classificatie voor dat type bug. Maar het is niet zo dat dat per se aan pdf is gekoppeld.
Zoiets kan voorkomen bij alle complexe software. Wat vroeger bij flash vast ook wel vaak werd gevonden of toen Acrobat nog de standaard pdf-viewer van browsers was. Maar het wordt natuurlijk erger zodra e.e.a. door derden beïnvloed kan worden, zoals pdf, html, audio, video etc op het web.

[Reactie gewijzigd door ACM op 1 november 2019 15:26]

Hmm. Beide exploits al meer dan 3 maanden bekend bij Google. Nu is die grens van 3 maanden ineens wel flexibel? Terwijl er 1 in het wild misbruikt wordt

Hypocriet bedrijf is het ook.

Waarom je een -1 krijgt weet ik ook niet. CVE-2019-13721 is 17 juli al aangemeld. En hypocriet is het zeker. Google is er altijd als de kippen bij om Microsoft aan de schandpaal te nagelen.

Gaan we weer.

CVE nummers worden voor grote organisaties vooraf uitgegeven zonder dat deze direct gebruikt worden. Dat de afgifte datum van een CVE niet overeenkomt met het moment dat een bug gemeld word of bekend is dus helemaal niet gek.

quote: https://cve.mitre.org/abo...ntry_created_in_cve_entry

What does DATE ENTRY CREATED signify in a CVE Entry?
The "Date Entry Created" date in a CVE Entry indicates when the CVE ID was issued to a CVE Numbering Authority (CNA) or the CVE Entry published on the CVE List.

This date does not indicate when the vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE. That information may or may not be included in the description or references of a CVE Entry, or in the enhanced information for the CVE Entry that is provided in the U.S. National Vulnerability Database (NVD).

quote: https://github.com/RedHatProductSecurity/CVE-HOWTO

Why was the CVE assigned days/weeks/months before going public?
Mitre has a "Date Entry Created" field in their database, this is the date the CVE was either assigned by Mitre to a specific issue, or the date that CVE was given by Mitre to another organization (such as Red Hat) for future use. For example CVE-2015-0201 through CVE-2015-0300 were assigned on November 14, 2014 to Red Hat, as of late January 2015 Red Hat has only used approximately half of these.

[Reactie gewijzigd door Yemoke op 1 november 2019 19:56]

Alleen exploits gevonden door dat speciale Google Security team moeten binnen x tijd vrijgegeven worden.

Alleen exploits gevonden door dat speciale Google Security team moeten binnen x tijd vrijgegeven worden.

Als ze die regel alleen aan de rest van Google op zouden leggen had ik het prima gevonden, maar ze hanteren die regel ook bij alle andere software. Het argument is iets in de trant van "beveiliging is belangrijk en als je het serieus neemt, dan is deze termijn haalbaar". Als je het daar niet mee eens bent heb je pech en maken ze alle details botweg openbaar. Als het Chrome team er niet in slaagt om de deadline die Project Zero voorschrijft te halen (en daarmee wegkomt omdat de bug door iemand anders gevonden is), dan zijn er eigenlijk maar twee conclusies mogelijk: de termijn die Project Zero eenzijdig aan iedereen oplegt is niet realistisch of het team achter Chrome neemt beveiliging niet serieus. Welk van de twee het is kan ik niet zeggen, maar in beide gevallen is Google hard aan het prutsen (of batjes heeft gelijk en ze zijn gruwelijk hypocriet).

Dus dat 'security yeam' kan z'n eigen lekken niet vinden maar die van anderen wel?

Misschien kijk ik verkeerd, maar waar blijkt uit dat ze er al langer dan 3 maanden vanaf wisten?

In de links uit het artikel haal ik dat de lekken met deze update nog geen maand oud (lees: bekend) zijn?

Euhm nee. Banananapenguin heeft het gemeld op 12 oktober:

[$7500][1013868] High CVE-2019-13721: Use-after-free in PDFium. Reported by banananapenguin on 2019-10-12

Google is vaak hypocriet in dit soort gevallen, maar deze keer niet. Netjes binnen twee weken een fix.

Chrome is door de snelheid van ontwikkeling en de featuritis een zieke (lees: dodelijk slechte) browser geworden. Ik blijf bij Firefox - zelfs als er geen website meer werkt, het zij zo. Chrome en enigines zoals Chromium - gebruik ik liever niet. Dat is veel te veel Einheitswurst en dus onveilig.

Firefox timmert weer goed aan de weg, gewoon weer de focus op een echt goede browser

jep mooie add ons ook

zoals HTTPS everywere en zo

Hebben jullie ook last van dat sinds update 78 bepaalde dingen veranderd zijn in Chrome ?
Zoals als je met je muis over een tabblad gaat, dat eronder een soort tooltip onder de tabblad verschijnt ?
En dat als je rechtermuisknop druk in een leeg vlak naast de tabbladen, dat er eerst een mooi menutje verscheen om bijvoorbeeld de gesloten tabbladen te heropenen, dat dit inneens van design veranderd is en enkele knoppen verdwenen zijn. Ik heb gisteren gedowngrade naar versie 77 door deze wijzigingen.
Heel vervelend-.-''

ja das een probleem waar meer mensen over klaagden op het chrome forum op reddit en IIRC er is geen work around beschikbaar anders dan een downgrade

het fijne kan ik je er niet van zeggen want ik heb chrome gedeinstallerd en ben nu firefox only dus ik let niet meer op chrome

#tab-hover-cards en #tab-hover-card-images --> Disabled. Werkt hier gewoon...

interesant daar had ik niets over gelezen in het chrome forum op reddit

En de menu als je rechtermuisknop doet op een lege vlak naast je tabbladen ? Dit is ook veranderd.
Tevens werkt "about://settings" niet meer. Deze geeft niet gevonden pagina aan.
Ik blijf nog wel even wachten tot die bugs opgelost zijn en als het zo blijft doorgaan, ga ik maar weer migreren naar Firefox. Was na versie 32 van Firefox gestopt met Firefox gebruiken en nu moet ik binnenkort denk ik maar weer naar Firefox overstappen.
Google Google Google... waar zijn jullie toch mee bezig

Hoe doet Opera dit eigenlijk? Ik lees bijna nooit over hun patches op Tweakers?

Opera is sinds 2013 Chromium (+ hun eigen sausje), dus zullen dezelfde problemen hebben als Chrome. Ook daarvoor waren ze vooral het onopvallendste kindje van de klas (niet in het nieuws), maar niet zozeer altijd maar heel erg veilig.

Opera heeft wel hele leuke integraties zoals de apps aan de linkerkant.