Google ontdekte in 2021 recordaantal van 58 zerodays

Beveiligingsonderzoekers van Google hebben in 2021 58 zerodays ontdekt. Dat is het hoogste aantal bugs dat in het wild werd misbruikt sinds de Project Zero-afdeling in 2014 begon die op te zoeken. Dat komt grotendeels door betere detectiemethodes, zegt het bedrijf.

De bugs werden ontdekt door experts bij Project Zero, Googles interne bugtrackingteam. Dat speurt op internet naar kwetsbaarheden, waaronder kwetsbaarheden die ook actief worden misbruikt door aanvallers. Sinds die afdeling halverwege 2014 begon met het specifiek tracken van zerodays zijn er niet zoveel gevonden, schrijft Google. Het vorige dubieuze record vond in 2015 plaats, toen er 28 werden ontdekt. In 2020 ontdekten de onderzoekers 25 zerodays.

De onderzoekers denken niet dat het aantal actieve aanvallen erg toeneemt. Het is moeilijk dat met zekerheid te zeggen, want zerodays zijn per definitie de enige actieve aanvallen die gevonden worden. Het is dus niet te zeggen hoeveel actieve aanvallen er in totaal zijn als die niet worden ontdekt. Google denkt dat juist dat laatste meespeelt in dit nieuwe record. Het zou makkelijker worden zerodays te ontdekken. Ook zouden bedrijven sneller informatie delen over kwetsbaarheden.

Volgens de beveiligingsonderzoekers kan de securityindustrie echter nog meer doen om zerodays tegen te gaan. De onderzoekers zeggen dat de meeste zerodaykwetsbaarheden lijken op bugs waarvan eerder al details naar buiten zijn gekomen. Op twee na gebruikten alle ontdekte zerodays zulke methodes, zeggen de onderzoekers. Het gaat dan om 17 use-after-freebugs, zes out-of-boundsbugs, vier buffer overflows en vier integer overflows. De meeste kwetsbaarheden werden gevonden in Chrome en in Safari's WebKit, maar ook in Internet Explorer.

Google raadt softwaremakers aan om de status van actieve aanvallen in hun openbare informatie te zetten, zoals securitybulletins of blogs. Ook zouden bedrijven vaker en meer gedetailleerde samples van exploits moeten delen. Google doet ook een concrete aanbeveling op het gebied van software. Het bedrijf zegt dat er meer aandacht moet komen voor geheugencorruptiekwetsbaarheden. Die zouden het vaakst voorkomen, zegt het bedrijf. Dat zou in 39 gevallen zo zijn.

Reacties (25)

[Dennisb1]

Ben benieuwd wat het verdienmodel is waarom Google dit zo graag wil doen

[gorgi_19]

Deels uit imago, deels uit filosofie, als je hun blog destijds mag geloven. Aanleiding schijnt ook de ontdekking van HeartBleed te zijn.

quote: https://security.googlebl...ouncing-project-zero.html

Beyond securing our own products, interested Googlers also spend some of their time on research that makes the Internet safer, leading to the discovery of bugs like Heartbleed.
(....)
You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of "zero-day" vulnerabilities to target, for example, human rights activists or to conduct industrial espionage. This needs to stop. We think more can be done to tackle this problem.

Project Zero is our contribution, to start the ball rolling. Our objective is to significantly reduce the number of people harmed by targeted attacks. We're hiring the best practically-minded security researchers and contributing 100% of their time toward improving security across the Internet.

[Reactie gewijzigd door gorgi_19 op 25 juli 2024 06:22]

[Remz]

Ze vinden meestal zerodays in hun eigen product Chrome, dus het betaald zich alleen al terug omdat hun eigen product er beter van wordt en het imago van Chrome als veilige browser blijft bestaan. Ze willen niet Internet Explorer achterna gaan.

Het zal niet direct in geld uit te drukken zijn, maar waarschijnlijk zien ze de kosten van dit project als verwaarloosbaar t.o.v. het grotere doel. Of wie weet zien we het ooit terug op Killed By Google.

[Twanne]

Ik kan me voorstellen dat de overheid ze hiervoor wel een zakcentje toestopt.
Niet per sé om ze zelf te gaan gebruiken (al kan dat misschien wel), maar je lost ook beveiligingslekken op die anderen tegen je kunnen gebruiken.

[vDorst]

De programmeertaal Rust zou al een goede stap kunnen zijn.
Rust zal de meeste geheugen issues eruit halen.

Ook ik heb ondervonden dat je toch fouten kan maken, het was een opstapeling van....
In mijn embedded ARM project in Rust, heb ik toch memory corruptie voor elkaar gekregen.
Ik had een fout gemaakt in de berekening of er nog ruimte was in een vaste capaciteit vector en om data te pushen heb ik de push_unchecked() gebruikt omdat ik al vooraf had gecontroleerd of de data op de vector zou passen.
push_unchecked() slaat de controle over of het nog wel in de vector past en daardoor wordt het sneller.
Als ik push() had gebruikt was de foute berekening wel naar voren gekomen door een panic op de ARM processor.

[RoestVrijStaal]

Waarom dan het niet gelijk goed doen en een programeertaal gebruiken waarbij de programmeur niet aan geheugenbeheer hoeft te doen?

[Myri]

Ik begrijp de hele discussie ook niet zo goed.
Bv: .NET is managed en zorgt er door middel van de CLR toch al voor dat je geen gekke dingen gaat doen in geheugen dat niet van je app is? En dat bestaat ondertussen toch al sinds 2002..

[fretnn]

Managed talen zijn meestal trager en hebben een runtime nodig en om die redenen worden voor bepaalde toepassing gekozen voor unmanaged talen.

[Myri]

Klopt, er zijn zeker geldige toepassingen voor unmanaged talen. Maar het is niet omdat je unmanaged gaat werken dat je applicatie ook beter / performanter zal werken. Te vaak is het een drogreden waarbij het éne kamp tegenover het andere kamp staat zonder objectieve feiten.

[Burning]

Er wordt altijd geheugen beheer gedaan. Het enige wat je doet door een taal te gebruiken waarbij dat niet hoeft is het probleem verplaatsen en er van uit gaan dat iemand anders zijn werk wel goed gedaan heeft.

[uiltje]

Het maakt nogal wat uit of je dat centraal doet in de runtime van een omgeving of overal in een applicatie en alle bibliotheken. Ja, het probleem is daarmee verplaatst, en in de praktijk gemitigeerd. Je kan er vanuit gaan dat de implementatie is gedaan door een expert en dat er testen zijn uitgevoerd.

Of denk je dat er bij verkeerde array toegang in Java (om maar een voorbeeld te noemen) er geen ArrayOutOfBoundsException wordt gegooid? Nou dan.

[SillieWous]

Je vergeet te vertellen dat een runtime een bak overhead met zich mee brengt. Daarmee wordt het voor embedded en performance toepassingen al snel niet interessant.

[Erwin1967]

Daarentegen zijn de hedendaagse processoren ongelofelijk snel geworden. In de tijd van de 6502 moest je inderdaad klokcycles tellen voor de performance. Geheugenmanagement is altijd belangrijk ook voor bijvoorbeeld .Net applicaties. Persoonlijk vind ik dat de zgn. managed omgevingen uitnodigen voor slordig programmeren door niet meer te controleren en te vertrouwen op exceptions.

[dieAndereGozer]

Daarentegen zijn de hedendaagse processoren ongelofelijk snel geworden

Die opmerking kreeg ik ook naar mijn hoofd tijdens de opleiding toen ik begon over de efficiëntie van de code tijdens het college.
Als een processor 10 % sneller wordt maar jouw inefficiëntie 12 % meer overhead geeft, ga je erop achteruit.

Los van het hele energie verhaal en prestatieverlies natuurlijk.

[uiltje]

Och, och. Het is een eenmalige overhead die zeker niet in de tientallen procenten loopt in een normaal proces. Met jouw redenatie moeten we weer terug naar assembler. Voor embedded moet je natuurlijk wel oppassen, maar vergeet niet dat e.g. Android ook grotendeels managed code is, en Apple gebruikt nu Switch in plaats van Objective C.

[Reactie gewijzigd door uiltje op 25 juli 2024 06:22]

[dieAndereGozer]

Je kan natuurlijk wel een ad absurdo gebruiken, maar dat maakt jouw punt niet valide, eerder minder.

[uiltje]

Dat is natuurlijk onzin, ik zie veel vaker dat return values niet worden gecontroleerd, en als je een exceptie "negeert" is hij nog niet weg. Sorry, maar makkelijker is makkelijker, en de mensen die nu die fouten maken in Java zouden er 100 bij maken in e.g. C of C++.

[davekok]

Ja maar een hoop van die overhead komt voort uit allemaal dingen die niets te maken heeft met geheugen beheer. Zoals het moet op alle architecturen werken. Of het moet allemaal extreem dynamisch zijn. Of er moet een VM gebruikt worden. De overhead zou ook een stuk verlaagd kunnen worden. Het extreem dynamisch programmeren heeft zichzelf nooit bewezen. Je ziet dat alle talen steeds meer type hints ondersteunen. Aan OO komen ook steeds meer beperkingen. En gewoon machine code genereren voor een bepaalde arch, wordt ook langzaam aan weer normaal.

Ik denk dus dat het verschil tussen managed en unmanaged talen steeds verder zal afnemen. En dat we ergens in het midden eindigen.

[gimbal]

En voor technologie wat al 10+ jaar doorontwikkeld wordt is dat geen ongeldige aanname om te doen.

[vDorst]

Ik weet niet of zulke talen er zijn, maar je zal altijd wel iets met geheugen beheer doen.
Bij Rust hoeft je niet direct iets met geheugenbeheer te doen. Veel dingen gebeuren automagisch en worden checks uitgevoerd zodat je niet buiten je geheugen leest/schrijft.

Mijn project processor heeft beperkt geheugen en is dynamisch geheugen alloceren minder wenselijk.
Daarom werk ik met vaste buffers om tijdelijk data in te bewaren en voor de snelheid wilde ik niet bij welke byte een controle uitvoeren.

[uiltje]

Da's nogal gevaarlijk, maar je kan er in ieder geval voor kiezen om de belangrijke dingen buiten die buffer te laten. Dan zorgt het runtime er in ieder geval voor dat die niet kwetsbaar zijn door de geheugen scheiding. Dan zijn dingen als de Heartbleed bug nog steeds onmogelijk. En ik neem aan dat je een "clear" functie hebt om de gegevens in de buffer te vernietigen mits performance minder belangrijk is dan de security.

Natuurlijk is het gebruik van een veilige taal om de veiligheid daarna in de prullenmand te gooien zonde. Maar ik snap het wel; ik heb zelfs zoiets gruwelijks moeten doen in Java.

[vDorst]

Ik maak gebruik van de crate heapless https://crates.io/crates/heapless
Hiermee maak ik een fixed memory pool waarin 4x mijn data vector past.
Met heapless moet je verschillende stappen doorlopen om de geheugen locaties te kunnen gebruiken.
Eerst alloceren vanuit de pool, initialiseren locatie en vector en dan pas kan je het geheugen gebruiken.
heapless maakt goed gebruik van het Rust typesysteem, om ervoor te zorgen dat je deze stappen moet door lopen. Na dat de data is geconsumeerd wordt door Rust deze locatie weer terug gegeven aan de pool.

[dieAndereGozer]

De programmeertaal Rust zou al een goede stap kunnen zijn.
Rust zal de meeste geheugen issues eruit halen.

In mijn embedded ARM project in Rust, heb ik toch memory corruptie voor elkaar gekregen.

Toch wel mooi hoe je je eigen opmerking gelijk onderuit haalt.

[TwiekertBOB]

25 zerodays zijn nog steeds geen days. Tenminste, als ik mijn wiskundelessen nog goed heb onthouden.

Wat serieuzer: wel erg veel. Ik vraag me dan ook af of dit nu goed nieuws is dat ze gevonden zijn, of juist slecht nieuws dat er uberhaupt zoveel zijn.

[Reactie gewijzigd door TwiekertBOB op 25 juli 2024 06:22]

[Cergorach]

Ja het is slecht nieuws dat er zoveel zijn, het is goed nieuws dat ze gevonden zijn! Maar... Weinig gevonden zerodays in een stukje software betekend nog niet dat dit een veiliger stukje software is met minder zerodays...