skip to main | skip to sidebar
51 commenti

Meltdown e Spectre, le cose da sapere e da fare (senza panico)

Ultimo aggiornamento: 2018/01/07 00:40.

Se avete sentito parlare in toni drammatici di due importanti falle informatiche annunciate in questi primi giorni del 2018, rilassatevi.

Sì, il problema è serio, ma se non siete informatici per lavoro (per esempio gestite una banca o un servizio cloud) probabilmente vi basta aggiornare il vostro Windows, Mac, Linux, Android o iOS e le vostre applicazioni (in particolare il browser) come consueto, senza panico. Forse dovrete aggiornare anche il firmware del vostro processore. Se invece siete informatici per lavoro, vi aspettano giorni difficili e mi dispiace molto per voi.

In estrema sintesi, Meltdown e Spectre sono i nomi dati a gravi difetti di progettazione e di funzionamento presenti in buona parte dei processori fabbricati dal 1995 in poi da Intel e in alcuni di quelli prodotti da AMD e progettati da Arm. Sono processori usati in computer, tablet, telefonini e molti altri dispositivi (comprese le auto “intelligenti”). Non si tratta dei soliti difetti di app o sistemi operativi: qui sono proprio i chip stessi a essere fallati.

Specificamente, Meltdown è un difetto dei processori della Intel (e del futuro Cortex-A75 della Arm), mentre Spectre (in due varianti) tocca non solo i processori di Intel ma anche quelli di AMD (Ryzen) e Arm usati sugli smartphone, secondo The Register. Meltdown è risolvibile via software; Spectre per ora no.

Questi difetti hanno una caratteristica comune: entrambi risiedono nelle funzioni di speculative execution dei processori e intaccano le barriere protettive fondamentali che isolano un processo da un altro (per esempio un’app da un’altra). Normalmente un’app non può spiare i dati usati da un’altra app, ma con Meltdown e Spectre questo isolamento cade, e cade malamente, come racconta questo articolo tecnico.

Questo consente per esempio a una pagina Web o a un’app ostile di rubare password (persino da un gestore di password), chiavi crittografiche, Bitcoin e altre criptovalute, mail, foto, documenti o altri dati o di eseguire istruzioni a suo piacimento sul vostro dispositivo. Basta usare del Javascript in un browser non aggiornato. In altre parole, è male.

Per i sistemi aziendali che usano macchine virtuali, è stato dimostrato che un attacco eseguito su una macchina virtuale può leggere la memoria fisica della macchina ospite (host) e da lì leggere la memoria di un’altra macchina virtuale presente sullo stesso host. Per chi gestisce o usa servizi cloud, insomma, è malissimo.

Tanto per darvi un’idea di quanto sia brutta questa situazione, il CERT statunitense aveva inizialmente consigliato di cambiare tutti i processori ("Fully removing the vulnerability requires replacing vulnerable CPU hardware.") (copia su Archive.is). Poi si è ricreduto.

Non risulta al momento che ci siano attacchi attivi che sfruttano queste falle, ma è probabilmente solo questione di tempo [2017/01/05 19:00: sono arrivati]. Le dimostrazioni di efficacia di queste falle realizzate dagli esperti, invece, sono già in circolazione:






Siccome cambiare processore non è granché fattibile nella maggior parte dei dispositivi, è necessario ricorrere a correzioni software, da scaricare tramite aggiornamenti del firmware, del sistema operativo e delle applicazioni.

Nonostante le preoccupazioni iniziali su possibili riduzioni delle prestazioni dei processori dovuti a queste correzioni, le prime indicazioni non rivelano rallentamenti avvertibili in circostanze normali [2018/01/07 00:40 segnalati tempi quasi doppi per il mining della criptovaluta Monero].

  • Per il firmware, Intel ha annunciato di aver già pubblicato aggiornamenti correttivi per “la maggior parte dei processori introdotti negli ultimi cinque anni”, ma solo per Meltdown; Spectre rimane. AMD ha pubblicato delle informazioni di base; Arm ha messo online un elenco dei prodotti vulnerabili e le patch per Linux.
  • Per i dispositivi Apple, iOS risulta già corretto dalla versione 11.2, macOS dalla 10.13.2 e tvOS dalla 11.2 (watchOS non richiede aggiornamenti correttivi). Il browser Safari dovrebbe ricevere a breve un aggiornamento.
  • Per Linux è disponibile un aggiornamento (piuttosto manuale). Il kernel 4.14.11, rilasciato il 3 gennaio, risolve le falle. Per sapere quale kernel avete, il comando (a terminale) è uname -r o uname -a.
  • Per i dispositivi Android sono disponibili gli aggiornamenti della patch 2018-01-05 (almeno per i telefonini e tablet supportati dai produttori); per sapere se il vostro Android è aggiornato, seguite Impostazioni - Sistema - Informazioni sul telefono (o tablet) - Livello patch di sicurezza.
  • Firefox è corretto dalla versione 57.0.4. Se avete una versione precedente, aggiornatela.
  • Google Chrome sarà corretto dalla versione 64, che dovrebbe uscire il 23 gennaio; nel frattempo conviene attivare la site isolation come descritto qui
Il problema principale è Windows.
  • Microsoft Edge, Internet Explorer 11, Windows 10, Windows 8.1 e Windows 7 SP1 sono corretti con l’aggiornamento KB4056890 del 3 gennaio scorso (come spiegato nella Client Guidance for IT Pros, nella Server Guidance e nell’Advisory ADV180002 di Microsoft) e con l’aggiornamento KB4056892: lanciate Windows Update per aggiornarvi.
  • Tuttavia ci sono conflitti con alcuni antivirus, per cui gli aggiornamenti non si installano sui dispositivi che hanno quegli antivirus (la lista è in continua evoluzione; Kaspersky era già a posto da fine dicembre). Siamo insomma all’ironia che gli antivirus ostacolano la sicurezza.
  • Esiste un’app gratuita per verificare la corretta installazione degli aggiornamenti in Windows: si chiama SpecuCheck.

Per i computer, i tablet e i telefonini (almeno quelli aggiornabili), insomma, il problema è risolvibile, anche se ci sarà sicuramente qualcuno che non si aggiornerà perché si crede più intelligente degli altri o perché ha un capo che si crede più intelligente degli altri. Ma restano i vecchi smartphone e tutti gli altri dispositivi connessi a Internet, quelli dell’Internet delle Cose, come sistemi di monitoraggio e controllo remoto, “smart TV”, automobili, impianti di domotica, che forse non vedranno mai un aggiornamento.

Se volete saperne di più, in italiano potete leggere per esempio Siamogeek o Il Post; in inglese c’è una panoramica dettagliata su Gizmodo e nei siti dedicati alle vulnerabilità, ossia Meltdownattack.com e Spectreattack.com.

Se siete responsabili informatici di un’azienda, potreste trovare ispirazione in questi consigli per definire un piano d’azione. Preparate i fazzoletti.



2018/01/05 19:00


Come facilmente prevedibile, cominciano ad arrivare i primi attacchi, basati su Spectre.





Fonti aggiuntive: Bruce Schneier, The Verge, Google Project Zero, Medium, ANSA, CERT, The Register, VirusBulletin, Sophos, BleepingComputer, BBC, Repubblica.
Invia un commento
I commenti non appaiono subito, devono essere tutti approvati manualmente da un moderatore a sua discrezione: è scomodo, ma è necessario per mantenere la qualità dei commenti e tenere a bada scocciatori, spammer, troll e stupidi.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui e/o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (51)
queste patch Intel per i microcode dei processori sono scaricabili da qualche parte?
ovvero: gli utenti finali possono applicarle in autonomia oppure togca aspettare che questi aggiornamenti vengano distribuiti dai produttori pc attraverso un nuovo bios?
Sembrerebbe che AMD non ne sia affetto, se non in particolari condizioni e solo con Linux, tant'è che Torvalds ha caricato ieri una patch per disabilitare il fix per le CPU AMD su Linux...
In questo tweet ( https://twitter.com/patocheclub/status/948814442015444993 ) un diagramma riassuntivo.
Ubuntu sembra che rilascerà una patch il 9 gennaio (anche per le vecchie versioni del kernel supportate)
https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/
"Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible"
Approfitto per chiarire un passaggio che è uscito nello stesso modo (non chiaro) anche su tutti i media che ho letto.
ARM non è un fabbricante di processori, quindi non esistono chip di marca ARM o realizzati da ARM.
ARM è una società che progetta processori che vengono poi realizzato su licenza è in forma “personalizzata” da molti costruttori in una quantità molto elevata di modelli diversi.
La enorme diversità di modelli è dovuta al fatto che i “core” ARM vengono in realtà utilizzati dalle case costruttrici (ST, Texas Instruments, Nexperia, eccetera) all’interno dei microcontrollori (MCU), è sono questi ultimi ad essere impiegati in milioni di pezzi nei ridotti elettronici, industriali o consumer che siano.
Un microcontrollore (MCU) non è un microprocessore (CPU). È un circuito integrato (un chip) che contiene una CPU, in questo caso progettata da ARM, più diverse altre cose: una memoria per contenere il programma (EEPROM), una memoria dati RAM, ed una vasta serie di “periferiche”.
Queste ultime sono circuiti con vari scopi fra cui quelli che servono a collegarsi all’esterno, perciò “porte di I/O” (linee di segnale a cui collegare qualcosa); porte seriali di diversi tipi; interfacce di ingresso e uscita analogici (ADC e DAC).
A queste si aggiungono le altrettanto essenziali periferiche per uso interno, principalmente i “timer”, ma anche altre numerose funzioni che qui non cito.
Tutto questo costituisce un microcontrollore, che nelle sue numerosissime varianti è perciò il componente fondamentale di un numero immenso di prodotti elettronici.
in tutto questo c'è un passaggio che non mi è molto chiaro, buona parte degli smartphone android hanno a bordo snapdragon o ekynox e qualcuno kirin anche questi microprocessori sono coinvolti ?
per debian stabile stretch è uscito un aggiornamento per meltdown: https://security-tracker.debian.org/tracker/CVE-2017-5754 Non ho notato rallentamenti su vari computer con cpu intel.
Per raspberry pi non ci sono problemi: https://raspberrypi.stackexchange.com/questions/77240/is-the-raspberry-pi-vulnerable-to-the-spectre-or-meltdown-exploit
Per Android, solo alcuni device con certe cpu sono affetti: https://developer.arm.com/support/security-update
per debian stabile stretch è uscito un aggiornamento per meltdown: https://security-tracker.debian.org/tracker/CVE-2017-5754 Non ho notato rallentamenti su vari computer con cpu intel.
Per raspberry pi non ci sono problemi: https://raspberrypi.stackexchange.com/questions/77240/is-the-raspberry-pi-vulnerable-to-the-spectre-or-meltdown-exploit
Per Android, solo alcuni device con certe cpu sono affetti: https://developer.arm.com/support/security-update
Debian ha rilasciato il kernel linux con le patch
https://www.debian.org/security/2018/dsa-4078
Anche Ubuntu ha rilasciato i kernel aggiornati
https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-5754.html
Notate che (come già detto da Paolo) i kernel linux hanno le patch per "meltdown" ; per "spectre" ancora non esiste una soluzione.
In Debian e in Ubuntu le patch sono state "backported" nei kernel delle release (dunque non c'e' bisogno di aggiornare al kernel 4.14.11).
In Debian/stretch il kernel 4.9.65-3+deb9u2 ha le patch per meltdown; è già disponibile per il download.
In Ubuntu il kernel con le patch non è ancora nei repository AFAICT
niente da fare. Windows update mi dice che il sistema è aggiornato ma l'ultimo aggiornamento porta la data del 24 dicembre scorso.
Ciao Paolo, ho un dubbio: un possessore di Windows Phone, sistema 8.1, per intenderci quei dispositivi che non vengono più prodotti e che registrano un fuggi fuggi generale da parte degli sviluppatori delle app, ebbene rischia di più? Lo chiedo perché sono mesi che non escono più aggiornamenti di sistema...
In Linux, i microcodici nuovi per i processori in genere sono installati dal kernel;
i microcodici per i processori Intel si possono in genere trovare qui
https://downloadcenter.intel.com/search?keyword=linux+microcode

Per Debian e Ubuntu, il pacchetto intel-microcode rende disponibile al kernel i microcodici;
a quanto si legge qui
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367
la versione 20171215 contiene i microcodici contro alcuni attacchi meltdown e anche spectre (variant 2)

le potete scaricare da qui

https://tracker.debian.org/pkg/intel-microcode

https://launchpad.net/ubuntu/+source/intel-microcode
Domanda, che tu sappia le falle sono utilizzabili anche su console come Xbox 360, PS3, Xbox one e PS4?
Comunque per fortuna hanno scoperto queste falle prima che venissero sfruttate per un attacco di massa, ora devo recuperare la versione dei processori di tutti i dispositivi che ho in casa...
Beh, potrebbe esser l'occasione per portarsi a casa qualche cpu performante "da server" a prezzo stracciato :F

Comunque, tutti han fatto la guerra a Flash, ma com'è che nessuno abbia nulla da eccepire su JavaScript? Le peggio cose le ho sempre viste fare grazie a "loro".
Questo è l'esempio perfetto che userò d'ora in poi per spiegare come mai nonostante sia esperto di informatica, appassionato di ogni oggetto tecnologico, sempre il primo a comprare e provare nuovi prodotti... non comprerò mai e poi mai telecamere da piazzare in casa (ip camere, allarme, etc..).

Non importa quanto tu sia previdente, accorto, esperto... L'informatica ha raggiunto un grado di complessità tale che non è più una scienza esatta, ormai è probabilistica, quasi filosofica.
Non importa quante password, firewall e precauzioni sei in grado di configurare, ogni mese escono notizie di bug nei software, vulnerabilità dei prodotti o di server violati... Non ESISTE un modo sicuro al 100% di avere una telecamera in casa con la certezza che in ogni momento non possa esserci qualcuno che fa un video mentre te ne stai sul divano.
Forse esagero, ma a me sembra un grandissimo casino... A livello utente basta aggiornare e si va a posto, anche i rallentamenti, se ci sono, sono minimi nell'utilizzo quotidiano. Personalmente ho aggiornato W10 e non ho notato nulla di differente.
La preoccupazione nasce da tutto ciò che è rete, dati messi ovunque, scambiati tra ditte anche a nostra insaputa... Se un server non viene aggiornato e viene bucato... Boh, forse sono catastrofico o forse solo incompetente, ma il danno ha una base esposta potenzialmente immensa e la sua riparazione è nella volontà, capacità, possibilità dei vari tecnici e delle ditte a loro capo. Come sempre, ma di solito la finestra per sfruttare qualche falla è più piccola, stavolta pare un'autostrada...
Non puoi fare a meno di JavaScript, sarebbe come dire di fare a meno di HTML.

Perche' anche i browser richiedono aggiornamento? E perche' Chrome se la prende cosi' comoda, se la situazione e' tanto grave?
Roby10 scrive:
Questo è l'esempio perfetto che userò d'ora in poi per spiegare come mai nonostante sia esperto di informatica, appassionato di ogni oggetto tecnologico, sempre il primo a comprare e provare nuovi prodotti... non comprerò mai e poi mai telecamere da piazzare in casa (ip camere, allarme, etc..).

Circa un anno fa ho installato una telecamera di una nota marca, con la funzionalità di controllo remoto tramite app. Di punto in bianco è entrata nell'app una seconda telecamera, che inquadrava l'interno di un'abitazione, con tanto di persone che andavano avanti e indietro, anche in vestaglia! E c'è di più: quella telecamera aveva anche uno speaker, e volendo avrei potuto mandare un messaggio da remoto! Ovviamente non l'ho fatto, l'ho subito rimossa e ho segnalato il problema al produttore. Ma una magagna del genere è per me più che sufficiente per essere totalmente d'accordo con te! :-D
Non vorrei passare per complottista..
Ma secondo voi i Big Brother come NSA etc. non ne erano a conoscenza?
Altro che le backdoor a volte invocate.
A pensar male spesso ci si azzecca.
Che si fa dal punto di vista firmware? Aggiornamento del bios della motherboard?
Che capita se la propria mobo è di una certa casa che il supporto non sa cosa sia e che quindi dopo due anni dall'uscita smette di supportare le sue motherboard appena rilasciata la nuova serie col nuovo chipset (tipo gigabyte tanto per fare un nome a caso)?
L'aggiornamento per Windows 7 SP1 è il KB4056894; per quanto mi riguarda l'ho trovato disponibile solo da stasera

https://support.microsoft.com/en-us/help/4056894/windows-7-update-kb4056894
"Esiste un’app gratuita per verificare la corretta installazione degli aggiornamenti in Windows: si chiama SpecuCheck"



E come hai detto che funziona, SpecuCheck?
Il problema è che è praticamente impossibile capire dove e come scaricare tali aggiornamenti di sicurezza per i processori intel Core i3. Sul sito Intel ci sono mille spiegazioni tecniche e non si capisce affatto dove trovare il link per la patch correttiva....boh...
Ho provato a cliccare sui link forniti per Windows, ma mi sembra d capire che sono aggiornamenti validi solo per Windows 10 e Windows 2016 Server, c'è qualche link anche per Windows 7 SP1?
Sul sito della Intel non ci sono i download delle patch semplicemente perché se ne occupano i vendor dei sistemi operativi.

Quindi, per Windows mi pare di capire che siano già in distribuzione gli aggiornamenti. Aspettiamo.
Marco Morocutti,

ARM non è un fabbricante di processori, quindi non esistono chip di marca ARM o realizzati da ARM.

Grazie della segnalazione: ho corretto e chiarito il concetto.
Firefox è corretto dalla versione 57.0.4. Se avete una versione precedente, aggiornatela.

E per firefox ESR e i browser alternativi basati su firefox ESR?

Io sto switchando a cyberfox perché FF57 non lo posso vedere, la nuova grafica stilizzata tipo android 5 per me è un pugno in un occhio.
(Si, sono "reo confesso", ho bloccato gli aggiornamenti di firefox già alla 56... :X ... ma data la perdita di compatibilità per le estensioni non credo affatto di essere l'unico... :D )
(ps: sto su arch linux con l'ultimo kernel aggiornato)

Tra l'altro io questa moda della grafica "stilizzata" che sta colpendo tutte le major release (da android5, a kde5, a firefox 57 e diversi altri browser) proprio non la capisco... erano così belle le vecchie grafiche sondate con le icone belle colorate... :?
@unknown
mi pare di capire che gli aggiornamenti per win 7 saranno disponibili dal 23 gennaio.
Ciao Paolo,
a quanto pare per i server il calo di prestazioni non è indifferente. Almeno così dicono quelli di Epic Games che riportano anche un grafico. Ti linko la notizia

https://multiplayer.it/notizie/193420-fortnite-i-recenti-problemi-di-connessione-di-fortnite-sono-dovuti-al-calo-prestazionale-causato-dalla-vulnerabilita-meltdown.html

@ Fabregas, dipende da quale tipo di processore hai sullo Smartphone, sul mio lumia 630 e lumia 530 è installato un cortex A7 che a quanto pare non rientra tra i processori vulnerabili. Verifica attentamente quale processore c'è sul tuo
Un chiarimento: non è che Spectre non è stato patchato, è che in linea di massima va patchato a livello di singola applicazione.

Meltdown permette potenzialmente a qualunque applicazione di leggere qualunque indirizzo di memoria, anche quella dedicata al kernel (praticamente il sistema operativo), quindi va inevitabilmente patchato a livello di kernel o di processore.

Spectre permette a un'applicazione di leggere "solo" qualunque indirizzo di memoria a lei stessa allocato.
Potrebbe non sembrare preoccupante, ma lo è per applicazioni che eseguono al loro interno codice terzo cercando di limitare quello che possono leggere. Esempio tipo, browser che esegue Javascript ma facendolo accedere solo alla pagina in cui risiede, e non ad esempio alle password salvate nel browser stesso.
Per questo motivo è principale preoccupazione del browser evitare o limitare Spectre, limitarlo a livello di kernel o processore è più difficile (per come agisce, non perché il campo di azione è più limitato) rispetto a Meltdown, ma fortunatamente questo è meno grave, dal punto di vista del kernel.
@AmiC:
Javascript è solo un linguaggio di programmazione, nient'altro.
Ciascun browser esegue a modo suo codice scritto in linguaggio javascript.
Qualunque falla "di javascript" è in realtà una falla del browser, di come esegue quel codice.
Flash è (ormai quasi "era") un software terzo eseguito all'interno del browser. È vulnerabile quindi a tutte le falle di Flash, più a quelle del browser.
E Flash è sempre stato stracolmo di falle, con conseguenze solitamente più gravi di quelle dei browser.
@Tukler
"Solo" un linguaggio di programmazione?! Dici poco!
Anche ActionScript è un linguaggio di scripting (di Flash), peraltro paragonato a JS.
La mia domanda è: i benefici di lasciar eseguire codice JS a qualsiasi pagina web sono superiori ai rischi che si corrono permettendo alle pagine di eseguire JS?
Secondo me (e molti altri, a giudicare dal successo di add-ons come NoScript), no.
Solo che disabilitando i JS talvolta i siti risultano inusabili.

Una domanda...dalle prime notizie sembra che l'applicazione delle patch crei un sovraccarico ai processori a paragone delle identiche operazioni svolte prima...dal punto di vista di spesa energetica e' possibile stimare quanto potra' impattare Meltdown a scala mondiale?? (anche considerando quanti processori immpattati). Grazie
@AmiC
Tuker intendeva (la semplifico ai minimi termini) ActionScript sta a Flash come JS sta al browser. Se te la prendi con Flash per simmetria dovresti prendertela col browser.
@Leonardo Di Lena
Non vedo tutta questa simmetria, e ad ogni modo non vedo masse di indignati verso i vari "browser", anche quando questi ultimi, sapendo di questa debolezza delle CPU, si prendono un mese per metterci una pezza (Chrome).
@AmiC:
"Solo" un linguaggio di programmazione?! Dici poco!

Già, dire che javascript ha un bug è come dire che html ha un bug perché un browser non interpreta bene un elemento.
O più o meno come dire che la lingua italiana ha un bug perché io ho commesso un errore grammaticale.

La mia domanda è: i benefici di lasciar eseguire codice JS a qualsiasi pagina web sono superiori ai rischi che si corrono permettendo alle pagine di eseguire JS?

Assolutamente sì, da una decina di anni a questa parte.

a giudicare dal successo di add-ons come NoScript

Forse 10 anni fa, sì.

Solo che disabilitando i JS talvolta i siti risultano inusabili.

A occhio direi la maggior parte dei siti più visitati. Diversi di questi sono addirittura scritti interamente con framework javascript, e senza di questo al massimo se ne può usare una versione alternativa fortemente ridotta.
Anche molte app mobile sono scritte in javascript, e sempre più lo saranno.

@Leonardo di Lena
Tuker intendeva (la semplifico ai minimi termini) ActionScript sta a Flash come JS sta al browser. Se te la prendi con Flash per simmetria dovresti prendertela col browser.

Esattamente, nick a parte:P

@AmiC:
non vedo masse di indignati verso i vari "browser"

Nel 2017, la peggiore vulnerabilità di Google Chrome ha cvss score 9.3, dopo di questa ne vengono altre 3 con 7.5
Adobe Flash, nel solo 2017, ha 57 vulnerabilità con score 10.0 e 3 con score 9.3

Capito perché le masse di indignati sono diverse?:D

si prendono un mese per metterci una pezza (Chrome)

In realtà la pezza l'hanno già messa il 5 gennaio, quella del 23 sarà la correzione più sistematica.
@Tukler
Io non ho mai parlato di bug di JS, bensì della necessarietà o meno di sviluppare siti che rendano obbligatorio abilitare i JS, e di come ormai non si possa fare a meno di lasciarli abilitati, esponendosi a tutti i rischi del caso.

Tu stesso dici che il primo filtro contro spectre dev'essere il browser, e non posso fare a meno di notare come questa vulnerabilità sia stata portata alla ribalta (scoperta non so...) da Project Zero.
La rendi pubblica il 3, e fornisci una "mitigazione" il 23? A me sembra un intervento tardivo, dato che giocavano in casa!

Il 5 cos'han fatto, han disabilitato di default SharedArrayBuffer?
E nonostante non si stia parlando di una vulnerabilità dei Browser, che non comparirà in nessuna delle loro liste delle Common Vulnerabilities and Exposures, sta proprio a chi sviluppa Browser porre una prima pezza, poichè è sfruttabile tramite browser!

Ciò detto, i tanto famigerati Spettri e Fusioni hanno un CVSS Score di 4.7
9.3 è comunque parecchiotto! :)
Anche perchè di Flash posso farne a meno, del Browser no.
@AmiC:
Da come scrivi ("i JS") mi sembra che non sia molto aggiornato sul tema.
Javascript è un linguaggio di scripting lato client (e quindi semmai i pericoli intrinsechi sarebbero dello scripting lato client su browser, non di javascript), col quale vengono scritte intere applicazioni, che possono girare su browser se il javascript viene eseguito da browser, oppure come applicazioni mobile, mentre sul backend rimangono praticamente solo le api di accesso al database.
Rinunciare allo scripting lato client, quando l'esecuzione di questo non ha dimostrato vulnerabilità degne di nota da più di un anno a questa parte, mi sembra un tantino illogico.

Il discorso su Spectre è che questa coinvolge praticamente solo applicazioni che eseguono script esterni dentro sandbox (quindi principalmente browser), e su queste ultime è relativamente facile da correggere, quindi era logico che la priorità fosse correggere Meltdown a livello di sistema e Spectre a livello di singola applicazione (ma non significa assolutamente che Spectre fosse una vulnerabilità loro).
Tutte le altre applicazioni con Spectre potrebbero solo leggere la memoria a loro stesse dedicate, quindi dal punto di vista del sistema operativo era un'urgenza minore rispetto a Meltdown. Tra l'altro nel frattempo anche Spectre sta venendo affrontata a livello di sistemi operativi.

Il 5 cos'han fatto, han disabilitato di default SharedArrayBuffer?
Esatto, e diminuito la precisione dei timer. Operazioni necessarie e sufficienti a rendere impraticabili sia Meltdown che Spectre.
Il discorso più ampio è che questi due sono risolti, ma ci possono essere altri attacchi basati su meccanismi simili a cui prima non si era pensato, quindi è un discorso che va affrontato più sistematicamente a livello di progettazione delle sandbox e separazione dei processi del browser, ed è quello che faranno.

poichè è sfruttabile tramite browser

Sfruttabile tramite browser sì, ma coinvolge il solo browser. Sempre rimanendo a Flash, ci sono state miriadi di attacchi che tramite Flash potevano coinvolgere l'intero sistema.

i tanto famigerati Spettri e Fusioni hanno un CVSS Score di 4.7

Questo fa pensare sia al calcolo dello score che è forse un po' poco intuitivo (compromissione totale della riservatezza, ma impatto su integrità e disponibilità nullo, quindi punteggio basso), sia al fatto che si trovano ogni giorno vulnerabilità molto più gravi, queste due hanno fatto notizia perché così generalizzate e originali.

9.3 è comunque parecchiotto! :)

Esatto, ma se guardi bene quella vulnerabilità è sfruttabile tramite HTML, non tramite Javascript!
Che facciamo, eliminiamo HTML?:P
Ma come si e' arrivati ad avere lo STESSO errore su processori di produttori assolutamente diversi?? "scopiazzatura" di architetture o utilizzo di un concetto di programmazione fondamentalmente errato che anche con diverse implementazioni ha mantenuto gli stessi difetti?
@Tukler
Scrivo "i JS" come abbreviazione di "i codici JavaScript", come peraltro vedo fare in diverse pubblicazioni a tema informatico.

Il mio punto era che nel costruire siti per nulla tecnici vedo ricorrere "ai JS" anche quando è possibile evitarlo, cose che ormai si posson fare egregiamente anche grazie ad HTML5, od ai fogli di stile.
Questo rende più complesso (o impossibile) individuare "i JS" malevoli tramite estensioni come NoScript o GreaseMonkey, col risultato che finiamo per autorizzare la qualunque, o non navigare affatto.
@AmiC
Da come scrivi ("i JS") mi sembra che non sia molto aggiornato sul tema.

Scrivo "i JS" come abbreviazione di "i codici JavaScript", come peraltro vedo fare in diverse pubblicazioni a tema informatico.

Copyright © 2007 Pearson Paravia Bruno Mondadori S.p.a.

Anche il resto, sono tutti dibattiti che erano attuali 10 anni fa ma non più oggi.

Comunque Greasemonkey (che è a sua volta javascript:D) sarebbe inutile per bloccare codice js "malevolo", viene eseguito quando il dom è già caricato.

Per curiosità, per caso ti occupi di SEO?
@Tukler
Nel senso che credi abbia letto uno di questi libri, o che credi tema Caffeine? :D

Copyright © Ulrico Hoepli Editore S.p.A. 2014

So che GreaseMonkey è JS, infatti io non demonizzo il linguaggio, disapprovo il lasciarlo parlare troppo liberamente a sconosciuti!

PS: se posso imparare lo faccio sempre molto volentieri, mi spiegheresti quindi perchè continui a sottintendere che io sia rimasto a 10 anni fa?
@AmiC
Nel senso che credi abbia letto uno di questi libri, o che credi tema Caffeine? :D

Scusami ma non ho proprio capito il riferimento a Caffeine:(

Copyright © Ulrico Hoepli Editore S.p.A. 2014

Premetto che quello non è certo un libro specialistico, né sulla programmazione in Javascript né sulla sicurezza in ambito web, quindi il linguaggio che usa è comunque quello adatto al suo contesto, diverso da quello del discorso che stiamo commentando.
In ogni caso, la frase a cui fai riferimento in quel libro usa "i Javascript" (per quanto comunque linguaggio un po' improprio) inteso come "gli script Javascript" (espressione che usa poco più in là), parlando del fatto che converrebbe separare gli script Javascript dai file HTML e spostarli in file a parte, e non è usato con riferimento al Javascript in generale (ci torno dopo).

So che GreaseMonkey è JS, infatti io non demonizzo il linguaggio, disapprovo il lasciarlo parlare troppo liberamente a sconosciuti!

Sì questo era chiaro, è solo una battuta perché trovavo ironico il fatto che si parli di evitare l'esecuzione di Javascript... scrivendo altro Javascript da eseguire:D Poi ovvio che il contesto è diverso:)
@AmiC
Nel senso che credi abbia letto uno di questi libri, o che credi tema Caffeine? :D

Scusami ma non ho proprio capito il riferimento a Caffeine:(

Copyright © Ulrico Hoepli Editore S.p.A. 2014

Premetto che quello non è certo un libro specialistico, né sulla programmazione in Javascript né sulla sicurezza in ambito web, quindi il linguaggio che usa è comunque quello adatto al suo contesto, diverso da quello del discorso che stiamo commentando.
In ogni caso, la frase a cui fai riferimento in quel libro usa "i Javascript" (per quanto comunque linguaggio un po' improprio) inteso come "gli script Javascript" (espressione che usa poco più in là), parlando del fatto che converrebbe separare gli script Javascript dai file HTML e spostarli in file a parte, e non è usato con riferimento al Javascript in generale (ci torno dopo).

So che GreaseMonkey è JS, infatti io non demonizzo il linguaggio, disapprovo il lasciarlo parlare troppo liberamente a sconosciuti!

Sì questo era chiaro, è solo una battuta perché trovavo ironico il fatto che si parli di evitare l'esecuzione di Javascript... scrivendo altro Javascript da eseguire:D Poi ovvio che il contesto è diverso:)
@AmiC
Nel senso che credi abbia letto uno di questi libri, o che credi tema Caffeine? :D

Scusami ma non ho proprio capito il riferimento a Caffeine:(

Copyright © Ulrico Hoepli Editore S.p.A. 2014

Premetto che quello non è certo un libro specialistico, né sulla programmazione in Javascript né sulla sicurezza in ambito web, quindi il linguaggio che usa è comunque quello adatto al suo contesto, diverso da quello del discorso che stiamo commentando.
In ogni caso, la frase a cui fai riferimento in quel libro usa "i Javascript" (per quanto comunque linguaggio un po' improprio) inteso come "gli script Javascript" (espressione che usa poco più in là), parlando del fatto che converrebbe separare gli script Javascript dai file HTML e spostarli in file a parte, e non è usato con riferimento al Javascript in generale (ci torno dopo).

So che GreaseMonkey è JS, infatti io non demonizzo il linguaggio, disapprovo il lasciarlo parlare troppo liberamente a sconosciuti!

Sì questo era chiaro, è solo una battuta perché trovavo ironico il fatto che si parli di evitare l'esecuzione di Javascript... scrivendo altro Javascript da eseguire:D Poi ovvio che il contesto è diverso:)
@AmiC
PS: se posso imparare lo faccio sempre molto volentieri, mi spiegheresti quindi perchè continui a sottintendere che io sia rimasto a 10 anni fa?

Ovviamente, chiarisco, non dico che "tu" come persona sei indietro di 10 anni, ma che sono i discorsi ad esserlo.

In 10 anni è cambiato totalmente il modo di scrivere Javascript, il modo di scrivere applicazioni web, e quello che fa un browser in generale.
Non lo dico per parlare di me ma solo per fare un esempio, la prima applicazione web seria che ho scritto, proprio nel 2007/2008, non aveva una riga di Javascript (fondamentalmente perché al tempo la pensavo come te:P), l'ultima è scritta interamente in Javascript (Angular).

10 anni fa in Javascript si scriveva giusto qualche script immerso nell'HTML, per un paio di animazioni o, se proprio eri avanti (e io non lo ero), caricare qualche contenuto in AJAX.
Allora il rapporto tra HTML e Javascript era almeno 90-10 in favore di HTML, i browser iniziavano con difficoltà (e relative vulnerabilità) a supportare tutto, ed era, allora sì, molto comune parlare di "i Javascript" (sottointendendo però comunque "gli script Javascript immersi nell'HTML").
Oggi ci sono framework per applicazioni web (e non solo) dove il paradigma è totalmente invertito, si scrive codice Javascript con dell'HTML dentro, e il rapporto finale può essere tranquillamente almeno 80-20 in favore del Javascript.

Questo non per dire che Javascript sia più importante di HTML, ma che è un linguaggio del web tanto quanto lo sono HTML e CSS, non certo di meno.
I browser lo supportano da anni, i motori Javascript sono infinitamente più collaudati (e performanti) di quanto lo erano 10 anni fa.
Come dicevo su, Chrome nel 2017 ha avuto più gravi vulnerabilità sfruttabili tramite HTML che tramite Javascript. E probabilmente continueranno ad esserci vulnerabilità tanto nell'interpretare HTML quanto Javascript quanto CSS, dovute magari a nuove caratteristiche che verranno implementate in uno qualunque di questi linguaggi, non al fatto che il linguaggio sia l'uno o l'altro.
Si tratta sempre di interpretare un linguaggio con cui puoi fare tanto (ormai anche con HTML e CSS puoi fare cose inimmaginabili 10 anni fa), e la vulnerabilità è nel come il singolo browser lo interpreta.

Discorso totalmente diverso è eseguire un programma terzo, come Flash (che sparirà presto, e non sarà rimpianto), o peggio Java o - un attimo che trattengo i conati di vomito:D - ActiveX. O i plugin dei riproduttori video eseguiti all'interno del browser, o il plugin di Adobe Reader.
Tutte cose strapiene di vulnerabilità, e fortunatamente tutte sostituite da funzioni del browser stesso, molto più semplici da gestire dal punto di vista della sicurezza.

Tornando al discorso della "pari dignità" tra HTML e Javascript, e facendo un parallelo con quello del libro, parlando di un framework Javascript ci si potrebbe chiedere se è meglio lasciare l'HTML dentro i file Javascript oppure spostarlo fuori.
Quindi si potrebbe potenzialmente dire che si dovrebbero "spostare gli HTML" inteso come "gli elementi HTML". Questo sarebbe l'equivalente della frase del libro, invertendo il paradigma HTML/Javascript, una frase un po' impropria ma possibile.

Ma tutt'altra cosa sarebbe riferirsi a Javascript, o a HTML, in sé utilizzando il plurale.
Dire "disabilitare i Javascript", come scrivevi tu due volte e come, non a caso, scrive proprio l’altro libro di 10 anni fa, equivale oggi in tutto e per tutto a dire "questo browser supporta gli HTML5" invece che "supporta HTML5".
Per questo che è una frase che stona, e che fa pensare a un riferimento a una realtà ormai datata.

Ti chiedevo se ti occupi di SEO perché mi è capitato di sentire discorsi simili proprio da persone che magari lavoravano nello sviluppo web diversi anni fa, nel frattempo hanno abbandonato lo sviluppo per dedicarsi ad altri aspetti del web, e sono rimasti un po' fermi ai paradigmi di allora.