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 () 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