Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Metriche di sicurezza

Ogni volta che si parla di sicurezza, materia alquanto delicata soprattutto in virtù degli avvenimenti dell’ultimo periodo, qualche animo “sensibile” tende a tirare fuori i migliori scarponi da alpinista per tentare la più impossibile delle rampicate: specchi ultralisci cosparsi di olio sintetico.

In un commento al post di punto informatico già sommariamente analizzato su questo canale che fa riferimento alla vulnerabilità OpenSSL di debian e derivate, l’autore dell’articolo[1] risponde che:

Lo dice l'articolo che tu stesso citi: la segnalazione della vulnerabilità è delle 16:48 del 13 maggio. La disponibilità della patch nei repository (per gli aggiornamenti automatici) è delel 19:12 dello stesso giorno. Circa tre ore per risolvere una vulnerabilità.

Visto che l’autore nell’articolo parlava di Nimda e CodeRed la mia domanda è: qual’è la risposta se applichiamo la stessa metrica (disponibilità della patch) ai due nefasti episodi? La risposta sorprendente la si ritrova su wikipedia:

Both Code Red, and Nimda were hugely successful exploiting well known and long solved vulnerabilities in the Microsoft IIS server

Cioé la patch esisteva già da diversi mesi prima dell’attacco. L’exploit infatti è stato ottenuto – come spesso accade – facendo il reverse engineering della pezza. Evidentemente sistemare i bachi più velocemente possibile, può non servire ad una emerita cippa. È molto meglio cercare di mantenere la qualità del codice molto alta ed introdurre misure difensive a tappeto (ASLR, protected mode).

La qualità del codice (leggasi numero di bachi di sicurezza) quindi, almeno secondo la mia modestissima opionione, rimane la metrica più affidabile in attesa di qualche illuminazione.

C’è un altro aspetto che mi infastidisce però della risposta sopra menzionata e che mi costringe ad aprire una parentesi retroattiva[2]: il tentativo di minimizzare a tutti costi il pasticcio colossale che è stato il baco in OpenSSL. Grazie ad un plugin per wireshark di Luciano Bello (lo scopritore del baco) è possibile decriptare il contenuto di una conversazione SSL; questo significa che anche se nel browser compare il simbolo del lucchetto (image) la certezza matematica che la comunicazione sia sicura non si può più avere (almeno senza trafficare a bassi livelli). Chi mi dice infatti che durante una transazione bancaria dall’altra parte del filo non ci sia un server Debian/derivato non patchato? In parole povere anche se non sono direttamente utente Debian, la mia sicurezza è stata comunque messa a repentaglio nei secoli dei secoli grazie ad un certo Kurt Roeckx: che si badi bene non è developer esperto di crittografia pasticcione, ma semplicemente un tabaccaio che, non capendo una cippa di numeri casuali ed entropia, ha ritenuto opportuno sistemare tutto da solo:

What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.

Però per risolvere la vulnerabilità ci sono volute solo 3 ore! (e ci credo è bastato rimettere a posto del codice che ha sempre funzionato). Complimenti!

-quack 


[1] La stessa opinione è stata spesso manifestata dal management di Mozilla. Per fortuna però almeno loro hanno capito che c’era qualcosa che non va e che bisogna individuare un’altra metrica più oggettiva e soprattutto funzionante.
[2] Lo so, non vuol dire niente ma mi piace lo stesso.
[3] C’è da aggiungere che patchare un server Debian senza rigenerare tutte le chiavi è altrettanto inutile

Potrebbero interessarti anche:
Commenti (10):
1. zakk
venerdì 25 luglio 2008 alle 1:25 AM - unknown unknown unknown
   

la mia metrica di sicurezza ideale (non so se qualcuno la usi): il numero di ore in cui un sistema sempre patchato all'ultima release è vulnerabile da remoto.

openssl non ci fa una bella figura qui (parliamo di anni, credo) ma mi sono sempre tenuto ben distante da debian.

   
2. Luca
venerdì 25 luglio 2008 alle 8:53 AM - unknown unknown unknown
   

concordo...e sono felice di non usare debian

   
3. Michele
venerdì 25 luglio 2008 alle 9:42 AM - unknown unknown unknown
   

Concordo in pieno con tutto quello che hai scritto nel post.

È sempre molto facile (per gli altri) criticare quello che fa Microsoft.

   
4. dan
venerdì 25 luglio 2008 alle 9:50 AM - unknown unknown unknown
   

E poi non è vero che la patch per OpenSSL è stata distribuita dopo poche ore, perchè su Ubuntu è stata distribuita in automatico solo in questo mese cioè a luglio, NON a maggio. Quindi tutti gli utenti fino ad luglio erano in pericolo!

   
5. Alessandro
venerdì 25 luglio 2008 alle 12:42 PM - unknown unknown unknown
   

@dan

La patch su Ubuntu è stata distribuita in automatico il [url=http://forum.ubuntu-it.org/index.php/topic,187240.0.html]13 maggio[/url]

@Paperino

Concordo più o meno su tutto. Resto dell'idea comunque che,open o closed che sia,inanzitutto si deve usare la testa.

   
6. Alessandro
venerdì 25 luglio 2008 alle 12:46 PM - unknown unknown unknown
   

Scusate....però il link lo si estrapola facilemente

Pensavo funzionasse così...

   
7. Paperino
venerdì 25 luglio 2008 alle 7:21 PM - unknown unknown unknown
   

@zakk:

il problema di una tale metrica è che non rende giustizia dei problemi causati da bachi già patchati (Nimda, CodeRed)

   
8. dark
venerdì 25 luglio 2008 alle 7:54 PM - unknown unknown unknown
   

@alessandro

la patch è stata distribuita in automatico solo il 26 giugno:

Ubuntu Security Notice USN-620-1 June 26, 2008

www.ubuntu.com/.../usn-620-1

   
9. Alessandro
sabato 26 luglio 2008 alle 12:25 PM - unknown unknown unknown
   

@dark

la patch di cui si stava parlando è quella che ho linkato sopra (o almeno ci ho provato a linkarla ;D ) e la puoi trovare a

www.ubuntu.com/.../usn-612-1

ed è datata 13 Maggio.

Il mio inglese non è forte,ma il bug incriminato del generatore casuale è quello che ti ho messo sopra.

@Paperino

Come faccio a creare un link?

   
10. Alessandro
sabato 26 luglio 2008 alle 12:25 PM - unknown unknown unknown
   

@Paperino

Come non detto...

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)