Google skickade ut ett gäng säkerhetskorrigeringar för webbläsarkoden Chrome och Chromium tidigare i veckan...
…bara för att få en sårbarhetsrapport från forskare på cybersäkerhetsföretaget Avast samma dag.
Googles svar var att trycka ut en ny uppdatering så snart det kunde: en buggfix som hanterar CVE-2022-3723, beskrivs med Googles vanliga vi-kan-varken-bekräfta-eller-förneka legalism:
Google är medvetet om rapporter om att en exploatering för CVE-2022-3723 finns i naturen.
(Apple använder också regelbundet en liknande oengagerad smak av OMG-alla-det-är-en-0-dagars avisering, och använder ord som säger att det "är medveten om en rapport om att [ett] problem kan ha utnyttjats aktivt".)
Denna Chrome-uppdatering innebär att du nu letar efter ett versionsnummer av 107.0.5304.87 eller senare.
Förvirrande nog är det versionsnumret man kan förvänta sig på Mac eller Linux, medan Windows-användare kan få 107.0.5304.87 or 107.0.5304.88, och nej, vi vet inte varför det finns två olika nummer där.
För vad det är värt beskrevs orsaken till detta säkerhetshål som "typförvirring i V8", vilket är jargong för "det fanns en exploateringsbar bugg i JavaScript-motorn som kunde utlösas av opålitlig kod och opålitlig data som kom in uppenbarligen oskyldigt utifrån".
Löst sett betyder det att det är nästan säkert att bara besöka och titta på en booby-fångad webbplats – något som inte är tänkt att leda dig till skada på egen hand – kan vara tillräckligt för att lansera oseriös kod och implantera skadlig kod på din enhet, utan några popup-fönster eller andra nedladdningsvarningar.
Det är vad som är känt i cyberbrottsslang som en drive-by-installation.
"Medveten om rapporter"
Vi gissar, med tanke på att ett cybersäkerhetsföretag rapporterade denna sårbarhet, och med tanke på den nästan omedelbara publiceringen av en en-bugg-uppdatering, att felet upptäcktes under en aktiv undersökning av ett intrång i en kunds dator eller nätverk.
Efter ett oväntat eller ovanligt inbrott, där uppenbara infartsvägar helt enkelt inte dyker upp i loggarna, vänder sig hotjägare vanligtvis till de grymma detaljerna i de detekterings- och svarsloggar de har till sitt förfogande och försöker sätta ihop systemet- nivåspecifikationer för vad som hände.
Med tanke på att exekvering av webbläsares fjärrkod (RCE) ofta involverar att köra otillförlitlig kod som kom från en otillförlitlig källa på ett oväntat sätt, och lanserade en ny körningstråd som normalt inte skulle dyka upp i loggarna...
…tillgång till tillräckligt detaljerade kriminaltekniska "hotsvarsdata" kan inte bara avslöja hur brottslingarna kom in, utan också exakt var och hur i systemet de kunde kringgå säkerhetsskydden som normalt skulle vara på plats.
Enkelt uttryckt, att arbeta baklänges i en miljö där du kan spela om en attack om och om igen, och se hur den utvecklas, kommer ofta att avslöja platsen, om inte den exakta funktionen, för en exploateringsbar sårbarhet.
Och, som du kan föreställa dig, är det mycket, mycket lättare att säkert ta bort en nål från en höstack om du har en karta över alla spetsiga metallföremål i höstacken till att börja med.
Kort sagt, vad vi menar är att när Google säger "det är medvetet om rapporter" om en attack som lanserats genom att utnyttja Chrome i verkligheten, är vi redo att anta att du kan översätta detta till "felet är verkligt, och det är verkligen kan utnyttjas, men eftersom vi faktiskt inte undersökte det hackade systemet i verkligheten själva, är vi fortfarande på säker mark om vi inte kommer rakt ut och säger "Hej alla, det är en 0-dag". ”
De goda nyheterna om buggupptäckter av detta slag är att de förmodligen utvecklades på det här sättet eftersom angriparna ville hålla både sårbarheten och tricken som behövdes för att utnyttja den hemliga, i vetskap om att skryta om tekniken eller använda den för mycket skulle påskynda upptäckten och därmed förkorta dess värde i riktade attacker.
Dagens webbläsare RCE-exploater kan vara djävulskt komplicerade att upptäcka och dyra att skaffa, med tanke på hur mycket ansträngning organisationer som Mozilla, Microsoft, Apple och Google lägger på att hårdna sina webbläsare mot oönskade knep för kodexekvering.
Med andra ord, Googles snabba lappningstid, och det faktum att de flesta användare kommer att få uppdateringen snabbt och automatiskt (eller åtminstone halvautomatiskt), gör att vi andra nu inte bara kan komma ikapp skurkarna, utan komma tillbaka före dem.
Vad göra?
Även om Chrome förmodligen kommer att uppdatera sig själv rekommenderar vi alltid att du kollar ändå.
Som nämnts ovan, letar du efter 107.0.5304.87 (Mac och Linux), eller en av 107.0.5304.87 och 107.0.5304.88 (Windows).
Använda Snarare > Hjälp > Om Google Chrome > Uppdatera Google Chrome.
Den öppna källkodsversionen av Chromium i webbläsaren, åtminstone på Linux, finns också för närvarande i version 107.0.5304.87.
(Om du använder Chromium på Linux eller någon av BSD:erna, kan du behöva kolla tillbaka med din distrotillverkare för att få den senaste versionen.)
Vi är inte säkra på om Android-versionen av Chrome påverkas, och i så fall vilket versionsnummer vi ska hålla utkik efter.
Du kan se efter alla kommande uppdateringsmeddelanden för Android på Googles Chrome släpps blogg.
Vi antar att Chrome-baserade webbläsare på iOS och iPadOS inte påverkas, eftersom alla Apple App Store-webbläsare är tvungna att använda Apples webbläsarundersystem WebKit, som inte använder Googles V8 JavaScript-motor.
Intressant nog, i skrivande stund [2022-10-29T14:00:00Z], beskrev Microsofts releasenotes för Edge en uppdatering daterad 2022-10-27 (två dagar efter att denna bugg rapporterades av forskarna), men gjorde det inte lista CVE-2022-3723 som en av säkerhetskorrigeringarna i den versionen, som var numrerad 107.0.1418.24.
Vi antar därför att letar du efter någon Edge-version som är större än detta kommer att indikera att Microsoft har publicerat en uppdatering mot detta hål.
Du kan hålla ett öga på Edge-patchar via Microsofts Edge säkerhetsuppdateringar sida.
