All’inizio di questa settimana, Google ha distribuito una serie di correzioni di sicurezza per il codice dei browser Chrome e Chromium, per poi ricevere lo stesso giorno una segnalazione di vulnerabilità da parte dei ricercatori della società di cybersicurezza Avast. La risposta di Google è stata quella di rilasciare un altro aggiornamento non appena possibile: una correzione di un solo bug relativo a CVE-2022-3723, descritta con il consueto legalismo di Google “non possiamo né confermare né smentire”: Google è a conoscenza di segnalazioni che indicano l’esistenza di un exploit per CVE-2022-3723 in natura. (Anche Apple utilizza regolarmente una notifica di tipo OMG-ogni-tutto-c’è-un-giorno-0, utilizzando parole del tipo “è a conoscenza di una segnalazione che [un] problema potrebbe essere stato attivamente sfruttato”). Questo aggiornamento di Chrome significa che ora dovete cercare un numero di versione pari a 107.0.5304.87 o successivo. Questo è il numero di versione da aspettarsi su Mac o Linux, mentre gli utenti di Windows potrebbero trovare 107.0.5304.87 o 107.0.5304.88 e, no, non sappiamo perché ci siano due numeri diversi. Per quel che vale, la causa di questa falla di sicurezza è stata descritta come “confusione di tipo in V8”, che in gergo significa “c’era un bug sfruttabile nel motore JavaScript che poteva essere innescato da codice non attendibile e dati non attendibili che arrivavano apparentemente innocenti dall’esterno”.
In parole povere, ciò significa che è quasi certo che la semplice visita e visualizzazione di un sito web con una trappola esplosiva – qualcosa che non dovrebbe condurvi da solo verso il pericolo – potrebbe essere sufficiente per lanciare codice rogue e impiantare malware sul vostro dispositivo, senza alcun popup o altri avvisi di download. Si tratta di ciò che in gergo criminale è noto come installazione drive-by. Dato che una società di cybersicurezza ha segnalato questa vulnerabilità e data la pubblicazione quasi immediata di un aggiornamento con un solo bug, riteniamo che la falla sia stata scoperta nel corso di un’indagine attiva su un’intrusione nel computer o nella rete di un cliente. Dopo un’intrusione inaspettata o insolita, in cui i percorsi di ingresso più ovvi non compaiono nei registri, i cacciatori di minacce si rivolgono in genere ai dettagli dei registri di rilevamento e risposta a loro disposizione, cercando di ricostruire le specifiche a livello di sistema di ciò che è accaduto. Dato che gli exploit di esecuzione di codice remoto (RCE) dei browser spesso comportano l’esecuzione di codice non attendibile proveniente da una fonte non attendibile in modo inaspettato e l’avvio di un nuovo thread di esecuzione che normalmente non comparirebbe nei registri l’accesso a dati forensi di “risposta alle minacce” sufficientemente dettagliati può rivelare non solo come i criminali sono entrati, ma anche esattamente dove e come nel sistema sono riusciti ad aggirare le protezioni di sicurezza normalmente in vigore.
In poche parole, lavorare a ritroso in un ambiente in cui è possibile riprodurre più volte un attacco e osservarne lo svolgimento, spesso rivela la posizione, se non l’esatto funzionamento, di una vulnerabilità sfruttabile. E, come potete immaginare, estrarre con sicurezza un ago da un pagliaio è molto, molto più facile se si dispone di una mappa di tutti gli oggetti metallici appuntiti presenti nel pagliaio. In breve, quello che vogliamo dire è che quando Google dice “è a conoscenza di segnalazioni” di un attacco lanciato sfruttando Chrome nella vita reale, siamo pronti a supporre che questo si possa tradurre in “il bug è reale e può davvero essere sfruttato, ma poiché non abbiamo effettivamente indagato sul sistema violato nella vita reale, siamo ancora su un terreno sicuro se non usciamo allo scoperto e diciamo: ‘Ehi, tutti, è uno 0-day'”. La buona notizia di questo tipo di scoperte di bug è che probabilmente si sono svolte in questo modo perché gli aggressori volevano mantenere segreta sia la vulnerabilità che i trucchi necessari per sfruttarla, sapendo che vantarsi della tecnica o usarla troppo diffusamente avrebbe accelerato la sua scoperta e quindi ridotto il suo valore negli attacchi mirati. Gli odierni exploit RCE dei browser possono essere diabolicamente complessi da scoprire e costosi da acquisire, considerando l’impegno profuso da organizzazioni come Mozilla, Microsoft, Apple e Google per rendere i loro browser più resistenti ai trucchi per l’esecuzione di codice indesiderato. In altre parole, i tempi rapidi di patch di Google e il fatto che la maggior parte degli utenti riceverà l’aggiornamento in modo rapido e automatico (o almeno semi-automatico), significa che il resto di noi può non solo mettersi al passo con i truffatori, ma anche superarli.
Cosa fare?
Anche se probabilmente Chrome si aggiornerà da solo, consigliamo sempre di controllare comunque. Come già detto, è necessario cercare il file 107.0.5304.87 (Mac e Linux), oppure uno dei file 107.0.5304.87 e 107.0.5304.88 (Windows).
Utilizzate Altro > Aiuto > Informazioni su Google Chrome > Aggiorna Google Chrome.
Anche il browser open-source Chromium, almeno su Linux, è attualmente alla versione 107.0.5304.87. (Se si usa Chromium su Linux, si può aggiornare la versione 107.0.5304.87). (Se si utilizza Chromium su Linux o su una delle BSD, potrebbe essere necessario verificare con il produttore della distro per ottenere la versione più recente). Non sappiamo se la versione Android di Chrome sia interessata e, in tal caso, quale sia il numero di versione da tenere d’occhio. È possibile verificare eventuali annunci di aggiornamenti per Android sul blog Chrome Releases di Google. Presumiamo che i browser basati su Chrome su iOS e iPadOS non siano interessati, perché tutti i browser dell’App Store di Apple sono costretti a utilizzare il sottosistema di navigazione WebKit di Apple, che non utilizza il motore JavaScript V8 di Google. È interessante notare che al momento della stesura di questo articolo [2022-10-29T14:00:00Z], le note di rilascio di Microsoft per Edge descrivono un aggiornamento datato 2022-10-27 (due giorni dopo la segnalazione di questo bug da parte dei ricercatori), ma non elencano la CVE-2022-3723 tra le correzioni di sicurezza presenti in quella build, che è stata numerata 107.0.1418.24. Si presume quindi che la ricerca di una versione di Edge superiore a questa indichi che Microsoft ha pubblicato un aggiornamento contro questa falla. È possibile tenere d’occhio le patch di Edge tramite la pagina degli aggiornamenti di sicurezza di Edge di Microsoft.
