Chrome udsender en presserende nul-dages rettelse – opdater nu!

Google udsendte en masse sikkerhedsrettelser til Chrome- og Chromium-browserkoden tidligere på ugen ...

...kun for at modtage en sårbarhedsrapport fra forskere hos cybersikkerhedsvirksomheden Avast samme dag.

Googles svar var at skubbe ud en anden opdatering så snart det kunne: en fejlrettelse, der håndterer CVE-2022-3723, beskrevet med Googles sædvanlige vi-kan-hverken-bekræfte-eller-benægte legalisme:

Google er opmærksom på rapporter om, at en udnyttelse af CVE-2022-3723 findes i naturen.

(Apple bruger også regelmæssigt en lignende uengageret smag af OMG-alle-der-er-en-0-dages notifikation, og bruger ord om, at det "er opmærksom på en rapport om, at [et] problem kan være blevet aktivt udnyttet".)

Denne Chrome-opdatering betyder, at du nu leder efter et versionsnummer af 107.0.5304.87 eller senere.

Forvirrende nok er det det versionsnummer, man kan forvente på Mac eller Linux, mens Windows-brugere kan få 107.0.5304.87 or 107.0.5304.88, og nej, vi ved ikke, hvorfor der er to forskellige tal der.

For hvad det er værd, blev årsagen til dette sikkerhedshul beskrevet som "typeforvirring i V8", som er jargon for "der var en udnyttelig fejl i JavaScript-motoren, der kunne udløses af upålidelig kode og upålidelige data, der tilsyneladende kom uskyldigt ind udefra".

Løst sagt betyder det, at det er næsten sikkert, at blot at besøge og se en booby-fanget hjemmeside – noget, der ikke skal føre dig i fare i sig selv – kan være nok til at starte useriøs kode og implantere malware på din enhed uden popups. eller andre downloadadvarsler.

Det er, hvad der er kendt i cyberkriminalitetsslang som en drive-by installation.

"Kendskab til rapporter"

Vi gætter på, at i betragtning af, at et cybersikkerhedsfirma rapporterede denne sårbarhed, og i betragtning af den næsten øjeblikkelige offentliggørelse af en one-bug-opdatering, blev fejlen afsløret i løbet af en aktiv undersøgelse af en indtrængen på en kundes computer eller netværk.

Efter et uventet eller usædvanligt indbrud, hvor åbenlyse adgangsstier simpelthen ikke dukker op i logfilerne, vender trusselsjægere sig typisk til de grove detaljer i de registrerings- og responslogfiler, de har til rådighed, og forsøger at samle systemet sammen. niveauspecifikationer af, hvad der skete.

I betragtning af, at browser remote code execution (RCE) udnyttelser ofte involverer at køre upålidelig kode, der kom fra en ikke-pålidelig kilde på en uventet måde, og lancerede en ny udførelsestråd, der normalt ikke ville dukke op i logfilerne...

…adgang til tilstrækkeligt detaljerede retsmedicinske "trusselsrespons"-data kan ikke kun afsløre, hvordan de kriminelle kom ind, men også præcis, hvor og hvordan i systemet de var i stand til at omgå de sikkerhedsbeskyttelser, der normalt ville være på plads.

Enkelt sagt, at arbejde baglæns i et miljø, hvor du kan afspille et angreb igen og igen og se, hvordan det udvikler sig, vil ofte afsløre placeringen, hvis ikke den nøjagtige funktion, af en udnyttelig sårbarhed.

Og som du kan forestille dig, er det meget, meget nemmere at fjerne en nål sikkert fra en høstak, hvis du har et kort over alle spidse metalgenstande i høstakken til at starte med.

Kort sagt, hvad vi mener er, at når Google siger "det er opmærksom på rapporter" om et angreb, der blev lanceret ved at udnytte Chrome i det virkelige liv, er vi klar til at antage, at du kan oversætte dette til "fejlen er virkelig, og den er virkelig kan udnyttes, men fordi vi faktisk ikke selv undersøgte det hackede system i det virkelige liv, er vi stadig på sikker grund, hvis vi ikke kommer lige ud og siger: 'Hej alle sammen, det er en 0-dag'. ”

Den gode nyhed om fejlopdagelser af denne art er, at de sandsynligvis udfoldede sig på denne måde, fordi angriberne ønskede at holde både sårbarheden og de nødvendige tricks for at udnytte den hemmelige, vel vidende at det ville fremskynde opdagelsen af ​​teknikken eller bruge den for vidt. dermed forkorte dens værdi i målrettede angreb.

Nutidens browser RCE-udnyttelse kan være djævelsk komplekse at opdage og dyre at anskaffe sig, i betragtning af hvor meget indsats organisationer som Mozilla, Microsoft, Apple og Google lægger i at hærde deres browsere mod uønskede kodeudførelsestricks.

Med andre ord betyder Googles hurtige patching-tid, og det faktum, at de fleste brugere vil modtage opdateringen hurtigt og automatisk (eller i hvert fald semi-automatisk), at vi andre nu ikke kun kan indhente skurkene, men komme tilbage foran dem.

Hvad skal jeg gøre?

Selvom Chrome sandsynligvis vil opdatere sig selv, anbefaler vi altid at tjekke alligevel.

Som nævnt ovenfor, leder du efter 107.0.5304.87 (Mac og Linux), eller en af ​​dem 107.0.5304.87 , 107.0.5304.88 (Windows).

Brug Mere > Hjælp > Om Google Chrome > Opdater Google Chrome.

Browserens open source Chromium-smag, i det mindste på Linux, er også i version 107.0.5304.87.

(Hvis du bruger Chromium på Linux eller en af ​​BSD'erne, skal du muligvis kontakte din distroproducent for at få den nyeste version.)

Vi er ikke sikre på, om Android-versionen af ​​Chrome er berørt, og i så fald hvilket versionsnummer vi skal holde øje med.

Du kan se efter eventuelle kommende opdateringer til Android på Googles Chrome frigives blog.

Vi antager, at Chrome-baserede browsere på iOS og iPadOS ikke er berørt, fordi alle Apple App Store-browsere er tvunget til at bruge Apples WebKit-browsing-undersystem, som ikke bruger Googles V8 JavaScript-motor.

Interessant nok beskrev Microsofts udgivelsesbemærkninger til Edge i skrivende stund [2022-10-29T14:00:00Z] en opdatering dateret 2022-10-27 (to dage efter at denne fejl blev rapporteret af forskerne), men gjorde det ikke angiv CVE-2022-3723 som en af ​​sikkerhedsrettelserne i den build, som var nummereret 107.0.1418.24.

Vi antager derfor, at leder efter enhver Edge-version, der er større end dette, vil det indikere, at Microsoft har udgivet en opdatering mod dette hul.

Du kan holde øje med Edge-patches via Microsofts Edge sikkerhedsopdateringer .

---