venerdì 7 settembre 2018

Viste le ripetute amarezze...

...che mi ha provocato l'istituzione, sia nella sua incarnazione centrale sia in quella locale, desidero togliermi un sassolino dalla scarpa e scrivere cose che altrimenti non avrei mai scritto.

Io ed i miei collaboratori abbiamo appena ricevuto l'accettazione di un articolo sulle Communications of the ACM. Una delle riviste informatiche più prestigiose al mondo. Viene pubblicata dal 1958 (61 anni). L'articolo è un "viewpoint" (articolo breve che descrive "opinions and views that pertain to issues of broad interest to the computing community") e non un full research paper. E' comunque una grandissima soddisfazione perché il processo di revisione è estremamente selettivo e rigoroso.

Tanto per avere un'idea, ogni mese vengono pubblicati solo 2 viewpoint. Alcuni mesi 1, talvolta nessuno.

Nel 2018 sono stati pubblicati solo 2 viewpoint su temi di sicurezza informatica, come il nostro. Gli autori erano (i link sono alle pagine Wikipedia degli autori):
  • Eugene Spafford (Professor of computer science at Purdue University)
  • Fred Schneider (Samuel B. Eckert Professor of Computer Science and chair of the at Cornell University computer science department).
Tra gli autori degli altri viewpoint del 2018:
  • Harold Lawson (ACM, IEEE, and INCOSE Fellow, IEEE Charles Babbage Computer Pioneer, and INCOSE Systems Engineering Pioneer)
  • Margaret Martonosi (ACM Fellow, H.T. Adams '35 Professor of Computer Science and the Director of the Keller Center for Innovation in Engineering Education at Princeton University)
  • Sheldon Jacobson (Founder Professor in Computer Science at the University of Illinois at Urbana-Champaign)
  • Stephen Wicker (Professor of Electrical and Computer Engineering at Cornell University and a Fellow of the IEEE)
  • Shane Greenstein (Martin Marshall Professor of Business Administration and co-chair of the HBS Digital Initiative at Harvard University),
  • Illah Nourbakhsh (Professor of Robotics at The Robotics Institute, Carnegie Mellon University)
  • Julia Hirschberg (Percy K. and Vida L. W. Hudson Professor of Computer Science and Chair of the Computer Science Department at Columbia University).
Lungi da me (e dai miei collaboratori) l'intenzione di confrontarci con persone di questo calibro: al loro confronto noi siamo dei dilettanti. Comunque, ripeto, dopo le ripetute amarezze che mi ha provocato l'istituzione ci tenevo a fare questo post.



mercoledì 18 aprile 2018

Attacchi informatici al cervello

Si, avete letto bene.

Nulla di particolarmente sorprendente. Come spiegato qui, degli esperti in sicurezza informatica hanno analizzato dei "neurostimolatori", dispositivi da impiantare sotto la pelle e collegare direttamente al cervello per mitigare i sintomi di alcune malattie (dolori cronici, problemi di movimento come quelli provocati dal Parkinson). Ovviamente hanno trovato il modo di modificare in modo non autorizzato la configurazione di un neurostimolatore già impiantato. Il che "could prevent the patient from speaking or moving, cause irreversible damage to their brain, or even worse, be life-threatening". L'attacco non è particolarmente sofisticato: essenzialmente è bastato ricostruire il formato dei segnali con i quali è programmato il neurostimolatore ed osservare che il protocollo ha garanzie di autenticazione e riservatezza praticamente inesistenti.

Ho scritto che questo evento non è sorprendente perché problemi di questo genere sono frequentissimi nei dispositivi elettronici, anche in quelli biomedicali. Vedi ad esempio le pompe di insulina ed i pacemaker (si, i pacemaker).

Ciò accade per molti motivi, uno dei quali è il fatto che le aziende che realizzano dispositivi biomedicali di solito sono competenti in elettronica e biomedica, ma non sono competenti in sicurezza informatica. Nessuno farebbe realizzare i dischi dei freni di un'automobile ad un'azienda specializzata in costruzioni in cemento armato. Purtroppo la società non si è ancora resa conto che un dispositivo contenente un calcolatore non è un dispositivo arricchito con qualche nuova caratteristica; è qualcosa di radicalmente diverso. Per comprendere quell'oggetto non è sufficiente essere competenti "nel dispositivo"; purtroppo è indispensabile essere competenti anche in informatica, altrimenti si ottengono dispositivi come questi. Dispositivi dai quali dipendono la vita delle persone ma che sono realizzati con tecniche del tutto inadeguate dal punto di vista informatico.

Questo evento si allaccia ad un tema a cui ho accennato brevemente al termine della lezione di "Reti di Calcolatori II e Principi di Sicurezza Informatica" di ieri. Quando uno studia i problemi di sicurezza, spesso gli attacchi gli sembrano intricati, complicati, mere possibilità teoriche di scarso interesse pratico. Questo è un approccio sbagliatissimo. Non si deve pensare in termini di "cosa so fare io", ma nei termini di "cosa può fare uno con motivazioni e competenze adeguate". Ragionando in questi termini uno sarebbe portato a concludere che realizzare il Pantheon o l'Acquedotto di Segovia è intricato, complicato, di scarso interesse pratico (nessuno di noi sarebbe in grado di realizzarli, neanche coinvolgendo altre persone....).

Questo problema è frequentissimo, al punto che gli esperti di sicurezza hanno formulato una sorta di principio apparentemente scherzoso ma profondissimo: "chiunque è in grado di progettare un protocollo di sicurezza che lui non è in grado di aggirare". Quello del neurostimolatore è un esempio da manuale. Il problema è che un protocollo di sicurezza non deve essere progettato da "chiunque". Deve essere progettato dagli esperti. I quali esperti sanno perfettamente che è meglio scegliere uno dei protocolli già esistenti e consolidati senza progettarne di nuovi, perché farne uno nuovo è troppo complicato; si cade quasi sempre nella trappola di cui sopra (si inventa un protocollo apparentemente indistruttibile, poi lo analizza un altro esperto e lui lo aggira con poco sforzo).

PS Il blog  in cui ho trovato la notizia sulla vulnerabilità dei neurostimolatori è fantastico. Ogni giorno viene analizzato un articolo scientifico, nei settori informatici più disparati. La selezione dei lavori e soprattutto la capacità di sintesi di Adrian Colyer sono davvero eccezionali.

martedì 27 marzo 2018

La lezione di oggi e lo scandalo Cambridge Analytica vs Facebook

Oggi nel corso di "Reti di Calcolatori II e Principi di Sicurezza Informatica" abbiamo completato la discussione di OAuth2, un protocollo fondamentale nella nostra vita quotidiana.

Ho dimenticato di evidenziare che questa è proprio la tecnologia alla base dell'enorme scandalo di cui sta parlando mezzo mondo, cioè il caso Cambridge Analytica-Facebook. Il caso è stato sviscerato ampiamente quindi non c'è molto da aggiungere; forse due punti di vista interessanti sono questo (descrizione di come uno sviluppatore abbia ottenuto tonnellate di dati che non gli servivano e che non pensava neanche di ottenere) e questo (analisi più ampia e profonda dei rischi potenziali per la società).

Dal nostro punto di vista ed in estrema sintesi, il problema è che quando i RO (resource owners, cioè gli utenti) assegnano ai C (applications, ad esempio Cambridge Analytica) la delega ad operare sulle proprie risorse sugli RS (resource server, ad esempio Facebook), quasi sempre lo fanno senza rendersi conto esattamente di cosa stanno facendo. Non si rendono cioè conto di quali informazioni personali stanno rendendo disponibili e cosa sia possibile fare con quelle informazioni.

Nel caso specifico Cambridge Analytica in realtà è accaduta una cosa ancora più sottile. I RO hanno fornito la delega ad una applicazione C (si chiamava thisisyourdigitallife) che aveva un certo scopo dichiarato (costruire un profilo della personalità). Poi questa applicazione ha usato i dati estratti da RS per scopi diversi da quelli dichiarati: li hanno venduti ad una terza parte (cioè Cambridge Analytica), la quale ha usato quei dati per operazioni di carattere politico.

Il problema dei C che usano la delega per uno scopo diverso da quello dichiarato lo abbiamo menzionato proprio stamani, ma mi sono dimenticato di evidenziare questo importantissimo esempio.

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.