Chrome fixar den åttonde nolldagen 8 – kontrollera din version nu

Google har precis patchat Chromes åttonde nolldagarshål årets hittills.

Nolldagar är buggar för vilka det fanns noll dagar som du kunde ha uppdaterat proaktivt...

…eftersom cyberbrottslingar inte bara hittade felet först, utan också kom på hur man kunde utnyttja det för skändliga syften innan en patch förbereddes och publicerades.

Så, snabbversionen av den här artikeln är: gå till Chromes Trepricksmeny (⋮), välj Hjälp > Om Chrome, och kontrollera att du har version 107.0.5304.121 eller senare.

Avslöjar nolldagar

För två decennier sedan blev nolldagar ofta allmänt kända mycket snabbt, vanligtvis av en (eller båda) av två anledningar:

• Ett självspridande virus eller mask släpptes för att utnyttja felet. Detta tenderade inte bara att uppmärksamma säkerhetshålet och hur det missbrukades, utan också för att säkerställa att fristående, fungerande kopior av den skadliga koden sprängdes långt och brett för forskare att analysera.
• En buggjägare som inte motiverades av att tjäna pengar släppte exempelkod och skröt om det. Paradoxalt nog, kanske, skadade detta samtidigt säkerheten genom att ge en "gratis gåva" till cyberkriminella att använda i attacker direkt, och hjälpte säkerheten genom att locka forskare och leverantörer att fixa det, eller komma på en lösning, snabbt.

Nuförtiden är nolldagarsspelet ganska annorlunda, eftersom samtida försvar tenderar att göra mjukvarusårbarheter svårare att utnyttja.

Dagens defensiva lager inkluderar: ytterligare skydd inbyggda i själva operativsystemen; säkrare verktyg för mjukvaruutveckling; säkrare programmeringsspråk och kodningsstilar; och kraftfullare verktyg för förebyggande av cyberhot.

I början av 2000-talet, till exempel – eran av supersnabbspridande virus som t.ex. Kod Röd och SQL Slammer – nästan vilken stackbuffert som helst, och många om inte de flesta heap-buffertspill, skulle kunna förvandlas från teoretiska sårbarheter till praktiska exploateringar i snabb ordning.

Med andra ord, att hitta exploateringar och "släppa" 0-dagar var ibland nästan lika enkelt som att hitta den underliggande buggen i första hand.

Och med många användare som kör med Administrator privilegier hela tiden, både på jobbet och i hemmet, behövde angripare sällan hitta sätt att koppla ihop exploateringar för att ta över en infekterad dator helt.

Men på 2020-talet, fungerande exekvering av fjärrkod – buggar (eller kedjor av buggar) som en angripare på ett tillförlitligt sätt kan använda för att implantera skadlig programvara på din dator bara genom att till exempel locka dig att titta på en enda sida på en webbsida som är fångad – är i allmänhet mycket svårare att hitta och värda mycket mer pengar i cyberunderground som ett resultat.

Enkelt uttryckt, de som får tag i zero-day bedrifter nuförtiden tenderar att inte skryta om dem längre.

De tenderar också att inte använda dem i attacker som skulle göra "hur och varför" av intrånget uppenbart, eller som skulle leda till att fungerande prover av exploateringskoden blir lätt tillgängliga för analys och forskning.

Som ett resultat av detta uppmärksammas ofta nolldagar i dessa dagar först efter att ett hotresponsteam kallas för att undersöka en attack som redan har lyckats, men där vanliga intrångsmetoder (t.ex. nätfiskade lösenord, saknade patchar eller glömda servrar) inte verkar har varit orsaken.

Buffertspill exponeras

I det här fallet, nu officiellt utsett CVE-2022-4135, buggen var rapporterad av Googles egen Threat Analysis Group, men hittades inte proaktivt, eftersom Google medger att det är "medveten om att en exploatering […] existerar i naturen."

Sårbarheten har fått en Hög svårighetsgrad och beskrivs enkelt som: Hög buffertspill i GPU.

Buffertspill betyder i allmänhet att kod från en del av ett program skriver utanför minnesblocken som officiellt tilldelats det, och trampar på data som senare kommer att litas på (och därför implicit kommer att litas på) av någon annan del av programmet.

Som du kan föreställa dig är det mycket som kan gå fel om ett buffertspill kan utlösas på ett listigt sätt som undviker en omedelbar programkrasch.

Överflödet kan till exempel användas för att förgifta ett filnamn som någon annan del av programmet är på väg att använda, vilket får det att skriva data där det inte borde; eller för att ändra destinationen för en nätverksanslutning; eller till och med för att ändra platsen i minnet från vilken programmet kommer att köra kod härnäst.

Google säger inte uttryckligen hur denna bugg skulle kunna utnyttjas (eller har utnyttjats), men det är klokt att anta att någon form av fjärrkodexekvering, som till stor del är synonymt med "smyg implantation av skadlig programvara", är möjlig, med tanke på att buggen innebär felhantering av minnet.

Vad göra?

Chrome och Chromium uppdateras till 107.0.5304.121 på Mac och Linux, och till 107.0.5304.121 or 107.0.5304.122 på Windows (nej, vi vet inte varför det finns två olika versioner), så se till att kontrollera att du har versionsnummer lika med eller nyare än dessa.

För att kontrollera din Chrome-version och tvinga fram en uppdatering om du är efter, gå till Trepricksmeny (⋮) och välj Hjälp > Om Chrome.

Microsoft Edge, som du säkert vet, är baserad på Chromium-koden (den öppna källkodskärnan i Chrome), men har inte haft en officiell uppdatering sedan dagen innan Googles hotforskare loggade denna bugg (och har inte haft en uppdatering som uttryckligen listar eventuella säkerhetskorrigeringar sedan 2022-11-10).

Så vi kan inte berätta för dig om Edge påverkas eller om du bör förvänta dig en uppdatering för denna bugg, men vi rekommenderar att du håller ett öga på Microsofts officiella utgåva anteckningar utifall att.

---