mercoledì 10 gennaio 2018

Meltdown e Spectre Considerazioni sintetiche

La scorsa settimana sono state rese pubbliche delle vulnerabilità particolamente, diciamo così, "interessanti" in quanto sono dovute ai dispositivi hardware e sono diffuse pressoché ovunque.

Comprendere causa, impatto teorico, impatto pratico, conseguenze, difese è complicato. Più complicato che in alti casi.

Sperando di fare cosa utile, rendo pubbliche alcune considerazioni sintetiche. Scrivo quanto segue al meglio delle mie conoscenze. Se qualcuno rilevasse delle imprecisioni lo prego di segnalarmelo. Alla fine delle considerazioni sintetiche ci sono alcune mie brevissime riflessioni più generali.

1) Le vulnerabilità Meltdown e Spectre sono presenti nella stragrande maggioranza dei dispositivi prodotti negli ultimi anni, dagli smartphone ai server.

Sono quindi presenti in praticamente tutti i sistemi operativi ed ambienti di virtualizzazione più diffusi.

2) Tali vulnerabilità possono permettere a del codice maligno di leggere porzioni di memoria alle quali non dovrebbe avere la possibilità di accedere; memoria di altri processi o del sistema operativo (quindi non il disco).

Un codice maligno può quindi, ad esempio, leggere chiavi crittografiche utilizzate da altri processi (in sessioni HTTPS o VPN attive); leggere password o hash di password utilizzate da altri processi; ottenere informazioni sull'utilizzo della memoria sufficienti per neutralizzare altre difese dei sistemi operativi moderni.

3) Lo sfruttamento da remoto di Meltdown è molto difficile. Condizione "quasi necessaria" per sfruttare Meltdown è la presenza di codice maligno sulla macchina. Presenza che l'attaccante deve ottenere per altre vie, diverse da Meltdown.

4) Quanto sopra vale anche per Spectre, con una eccezione molto particolare e molto importante: i browser.

Poiché i browser caricano codici Javascript da remoto ed è di fatto impossibile garantire che questi codici non siano maligni (cioè non tentino di sfruttare vulnerabilità nel browser), Spectre può essere sfruttata da remoto su tutti i browser.

4-bis) L'effettivo sfruttamento di Spectre richiede che l'utente mantenga aperta la pagina ostile per molto tempo.

5) Tutte le organizzazioni di cui personalmente mi fido (no, non chiedetemi l'elenco) raccomandano di applicare le patch corrispondenti a queste vulnerabilità quanto prima. Patch che sono già state rilasciate o che lo saranno nei prossimi giorni. Tipicamente per i sistemi operativi. In alcuni casi anche per i firmware e per alcuni applicativi.

5-bis) In alcune distribuzioni di Linux le patch indispensabili sono già state rilasciate a partire dal mese di Ottobre 2017 e sono generalmente associate al nome KAISER o KPTI. 

La conoscenza di Meltdown e Spectre tra i ricercatori ed i fabbricanti di software ha infatti iniziato a diffondersi a partire dal mese di Giugno 2016 2017. Il disclose pubblico è stato fatto in anticipo rispetto a quanto pianificato perché molti hanno iniziato a rendersi conto che stava bollendo qualcosa di grosso in pentola. Ad esempio, non era chiaro il motivo delle patch KAISER.

5-tris) L'applicazione delle patch ai sistemi operativi/firmware è generalmente associata ad un calo di prestazioni. Quantificarlo è difficile anche perché dipende fortemente dal workload. Nei workload interattivi, non dovrebbe essere molto marcato.

5-quater) Per le macchine Windows, è indispensabile fare attenzione alla eventuale presenza di antivirus già installati. Alcuni antivirus, infatti, sono al momento incompatibili con tali patch e possono causare un "blue screen of death". 

Al link qui sotto c'è un elenco di compatibilità tra antivirus e patch Windows che dovrebbe essere aggiornato dinamicamente. Non posso garantirne la correttezza. E' fornito da una organizzazione di cui mi fido.

Riflessioni finali

A) Molto, molto spesso, sia le organizzazioni sia "i privati" hanno vulnerabilità che sono più facilmente sfruttabili e potenzialmente più "disruptive" di Meltdown e Spectre.

Questa affermazione non deve essere intesa come una sdrammatizzazione di Meltdown e Spectre. Al contrario, vuole essere un invito alla riflessione: se mezzo mondo è entrato in fibrillazione per vulnerabilità meno sfruttabili e meno disruptive di quelle che sono "tipicamente presenti" allora uno dovrebbe porsi qualche domanda.

B) La necessità di aggiornare i sistemi è, appunto, una necessità. Ormai è ampiamente dimostrato. Non può essere considerata come un caso eccezionale da affrontare ogni tanto quando si ha tempo o in emergenza. E' quindi indispensabile (sarebbe quindi indispensabile) organizzarsi di conseguenza.

C) Ogni volta che si verifica un incidente informatico particolarmente grave o viene scoperta una vulnerabilità particolarmente grave, c'è una costante: l'esortazione ad aggiornare i sistemi il prima possibile.

martedì 19 dicembre 2017

Catene di certificati HTTPS

Nella lezione di Reti di Calcolatori di oggi abbiamo accennato ad un argomento che non è parte del corso, cioè le catene di certificati.

Nel corso abbiamo detto che la chiave pubblica di un Subject viene ottenuta sempre attraverso un certificato emesso da un Issuer che deve già essere presente nel KeySet e nel TrustSet di chi utilizza quel certificato.

Nella realtà accade quasi sempre una cosa più complicata: invece di un certificato arriva una sequenza di certificati in cui:

  • Lo Issuer dell'ultimo certificato della sequenza è il Subject del penultimo certificato;
  • ...
  • Lo Issuer del k-esimo è il Subject del (k-1)-esimo;
  • ...
  • Il primo certificato della sequenza è self-signed.

Solo il Subject=Issuer del primo certificato è nel KeySet e nel TrustSet (il primo certificato della sequenza deve cioè essere già presente nel software di chi usa la catena).

Intuitivamente, la CA che ho già nel KeySet e TrustSet delega un'altra CA-1 a rilasciare certificati; il fatto che io mi fidi di CA implica (trascurando qualche dettaglio) che mi fidi anche di CA-1. Poi CA-1 delega un'altra CA-2 e così via, fino ad arrivare al Subject finale che è certificato da una CA-X che non c'entra nulla con quella nel KeySet e TrustSet. La mia fiducia (implicita) in CA-X è una conseguenza logica della mia fiducia in CA.

Durante la lezione ho cercato di visualizzare una di queste catene ma come mi accade spesso non ci sono riuscito. In realtà è semplicissimo. Il certificato visualizzato dal browser è l'ultimo della catena, ad esempio, nel caso di Gmail:


Il tab "percorso certificazione" mostra una sintesi della catena: 

Andando a scavare nel TrustSet / KeySet di Windows 10 si trova, con un pò di pazienza, il certificato autofirmato che costituisce la "anchor" della catena, cioè l'atto di fede su cui si basa tutto il resto.


A questo punto iniziano infinite domande "ma i certificati intermedi possono essere inseriti nel KeySet? e nel TrustSet? e se dopo mi arriva dall'esterno uno diverso? e se viene revocato un certificato nella catena? e se un Issuer nella catena è già nel mio KeySet ma con una chiave diversa?". E così via. 

La quantità di problemi insiti in questa faccenda è una ulteriore dimostrazione della verità di quella frase che ho mostrato a lezione ed attribuito al quasi-Sheva&Kakà, "chiunque affermi che un problema è risolto facilmente dalla crittografia, dimostra di non avere capito il problema".