Il recente bug segnalato nel software di gestione Bind potrebbe mettere in difficoltà molte grandi aziende e gli Isp di tutto il mondo. Va quindi aggiornata la lista delle vulnerabilità e vanno presi i necessari accorgimenti. Vediamo come.
Si tratta di uno dei più complessi e pericolosi problemi di sicurezza venuti alla luce nell’ultimo periodo. È stato scoperto un bug nel software utilizzato in molti Dns (Domain Name System) server, e consentirebbe ai cosiddetti malicious hacker di creare grossi problemi agli Internet service provider e ai corporate Web server. Da questi, inoltre, sarebbe possibile rubare dati confidenziali ed eseguire codice arbitrario.
In realtà i bug sono più di uno e sono relativi a più di una versione di Bind, il software di gestione dei Dns. Il primo, riguarderebbe Isc Bind 8 e un buffer overflow nel codice di gestione delle transaction signature (Tsig handling code). Andando nel dettaglio, durante il processing di una firma di transazione (Tsig), Bind 8 verifica l’eventuale presenza delle Tsig che includono erroneamente chiavi valide. Se una Tsig di questo genere viene trovata, Bind salta il resto delle operazioni e va direttamente alla porzione di codice designata alla restituzione di un messaggio di errore. Il Buffer Overflow interviene proprio in questa fase, per cui un attacker dotato di uno competenza sufficiente è in grado di prendere privilegi sulla macchina target e di eseguire codice arbitrario.
Un altro problema riguarda Isc Bind, versione 4. Questo contiene un buffer overflow in nslookupComplain() Il buffer che sarebbe vulnerabile consiste in un array di caratteri definito in locale e utilizzato per generare un messaggio di errore destinato al syslog. Anche in questo caso, un hacker potrebbe sfruttare questa vulnerabilità mandando delle query Dns formattate in una maniera particolare, al fine di generare dei problemi di tipo Denial of Service (DoS) o di generare l’esecuzione di codice arbitrario.
La situazione attuale
Dopo la segnalazione dei Bug, avvenuta da parte del Cert, reperibile in forma integrale alla Url http://www.cert.org/advisories/CA-2001-02.html, si è assistito a tre fenomenologie principali. La prima consiste nell’incremento esponenziale delle scansioni effettuate su intere classi e finalizzate all’individuazione di macchine adibite a Dns, con le versioni affette sopra indicate. Ancora una volta la correlazione tra incidente, segnalazioni ed exploit è stata comprovata.
Un altro fenomeno di interesse risiede nel mancato coordinamento tra Isc (Internet Software Consortium, il “gestore” del codice sorgente di Bind) e alcuni indipendent software vendor, che si occupano di “replicare” il software e di distribuirlo all’interno delle release dei loro sistemi operativi. Come lo stesso Computer Emergency Response Team ha dichiarato nell’advisor che abbiamo citato sopra, non tutti gli Isv hanno proceduto ad aggiornare le proprie release, pertanto ci si trova di fronte ad una palese disomogeneità di versioni software.
Mentre anche la struttura informatica di Network Associates è stata sottoposta ad una serie di probes/attacchi aventi come obiettivo il Domain name System, un’altra problematica è venuta alla luce e riguarda il Bind forum presso www.isc.org. Rimanendo sul generale diremo che una nota mailing list di operatori dell’information security ha sollevato dubbi circa il coordinamento tra lo stesso forum ed il Cert, nonché sull’efficacia del coordinamento in ordine ai rilasci di versioni aggiornate del software.
In questo caso abbiamo assistito ad una delle prime “uscite pubbliche” del Cert nuova versione, cioè con le policy di diffusione dei bug vincolata a parametri di tempistica predefinita e contro la full disclosure, cioè la documentazione di basso livello dei bug. D’altro canto sembra che la comunità blackhat non abbia sofferto più di tanto il problema, in quanto sono circolati sui forum numerosi posting contenenti il sorgente degli exploit. Quello che è ancora una volta interessante è il modo ancora non uniforme di gestire l’informazione e la difficoltà finanche di gestire le policy in maniera organica.
Un altro esempio interessante, in ordine al bug reporting, è dato da Rfp, che individua in cinque giorni il termine massimo di divulgazione in caso di “silenzio” da parte del vendor interpellato. Personalmente ci sembra una buona opzione.
Nelle pagine di Linea Edp abbiamo più volte parlato di full disclosure e di bug reporting; del resto anche l’esistenza di rubriche quali BugReport in www.netstime.com sono testimonianza del nostro interesse sull’argomento.
Quello che ci interessa particolarmente ora è come minimizzare l’impatto sulle infrastrutture. Se ne desume che un’attenta valutazione ed analisi dei nuovi report può essere d’aiuto.
