Olimpo Informatico

[Zeus News]

Commenti all'articolo Linux, sventato hacking del nuovo kernel
Il team degli sviluppatori di Linux ha scoperto uno strano bug nel codice del nuovo kernel, attualmente in fase di sviluppo. Ma era davvero soltanto un bug?

[Francesco Orsenigo]

Domanda: è normale che qualche malintenzionato possa aver messo le mani sul codice sorgente di Linux?
Chi è stato a fare la modifica?

[Stefano Barni]

no, ovviamente non è normale che qualcuno possa introdursi in uno dei server che ospitano l'albero di sviluppo del kernel linux e faccia modifiche di nascosto.

potrebbe essersi trattato di una intrusione dall'esterno, operata sfruttando una falla di sicurezza non patchata, oppure potrebbe anche trattarsi di un'azione imputabile a qualcuno vicino al team di sviluppo e quindi autorizzato ad accedere al server.

al momento non si hanno notizie precise al riguardo, e ci sono tutti i motivi per presumere che gli amministratori di sistema coinvolti stiano indagando: qualora la vicenda avesse sviluppi notevoli pubblicheremo un aggiornamento.

[Giancarlo]

Bisognerebbe mettere una taglia da 250 mila euro sulla testa del tizio che ha scoperto la vulnerabilità dell'albero di sviluppo del kernel Linux :-)

[Sandro kensan]

Ho letto il 3d che parla della scoperta della backdoor, molto simpatico e poi moltro istruttivo,

il ragazzo molto meticoloso dice che gli sembra che quell'assegnazione non faccia qualche cosa di corretto e che potrebbe dare privilegi di root, l'altro gli risponde che sì, è vero! e hanno brindato allo scampato pericolo...

poi è intervenuto Torvald a dire che comunque sarebbe arrivato al suo pc e avrebbe visto la modifica di quella routine e la avrebbe esaminata attentamente, quella routine non viene mai modificata se non in presenza di bachi nuovi...

Gli hacker che sono alla guida del progetto non sono programmatori qualsiasi e quindi già a quel livello le backdoor vengono scoperte, poi si passa ai livelli successivi di tutti quelli che vogliono imparare dal codice fatto da "maestri", difficile che una modifica a pezzi importanti non venga esaminata bit dopo bit e quindi scovare cracker, o nazioni che abbiano interesse a spiare cittadini o altre nazioni...

Mi viene in mente che la Cina e molte altre nazioni non abbiano più voglia di servirsi di backdoor americane, vogliono passare a Linux, forse la Cia o aziende che hanno interessi in gioco vogliono avere un aporta di sevizio pure su Linux o vogliono parlarne male.

Hanno fatto i conti senza l'oste...^_^

[Sandro kensan]

Ho capito che non avevo compreso bene, infatti McVoy Ceo di una start-up che produce un suo software di nome... si è accorto che il CVS del ramo di sviluppo del kernel non combaciava con la versione presente nei server protetti, parlavano dimodifiche automatiche che avevano lasciato il posto a modifiche manuali.

Quindi McVoy ha scritto nella ml degli sviluppatori del kernel linux facendo presente il problema (ogni notte parte uno script che verifica la congruenza tra i due file). Si parla quindi di *paranoia* di doppia verifica e di sistemi di sicurezza ridondanti.

A chi gli chiedeva dove fosse la modifica fatta McVoy ha citato la routine di wait e quindi è stato relativamente facile trovare la backdoor. Il file di log attribuisce la modifica a uno dei kernel guru ma l'attribuzione è falsa.

Ovviamente ho spedito le mie congratulazioni a McVoy, comunque adesso le difese saranno moltiplicate di un ordine di grandezza. Si parla di modifiche firmate con GnuPG, sistemi CVS replicati su più macchine (come è attualmente), poi mi pare di avere capito che ci saranno cheksum sofisticati, insomma i più paranoici della crew di linux avranno ampio spazio...

Credo che se la NSA vorrà inserire porte di servizio in Linux debba usare la tecnologia presente nei prossimo ventennio...:) D'altronde entrare in casa dei cinesi senza che se ne accorgano penso sia il sogno della CIA.

La mia idea è che ci dovrebbero essere sistemi completi localizzati anche come responsabili e non solo a livello di macchine, in ogni area geografica e che le modifiche fatte in America/Europa/Asia debbano essere verificate nelle altre aree (America-(sud/nord)/Europa/Asia).

[Stefano Barni]

non credo si possa parlare di paranoia riguardo i controlli di routine effettuati sull'integrita' dei sorgenti del kernel.

bisogna tenere presente come avviene lo sviluppo: i programmatori lavorano sparsi nel mondo, quindi è più che mai necessario disporre di uno strumento che consenta la modifica distribuita del codice. qualcosa, insomma, che impedisca a due persone di modificare contemporaneamente lo stesso file, col risultato che l'ultimo a "salvare" ricoprirebbe le modifiche dell'altro.

servono, cioè, meccanismi di check-out ("estrazione" di una copia del file dal deposito, con la logica che il primo che la effettua blocca tutti gli altri) e check-in ("reinserimento" della copia nel deposito, distinta per versione, con conseguente disponibilità del file per modifiche da parte di altri).

tradizionalmente, lo sviluppo del kernel linux è stato gestito per anni con cvs, strumento collaborativo libero molto diffuso.

alcuni sviluppatori, inoltre, inviavano le loro patch direttamente a torvalds, che, dopo averle scrutinate, le inseriva personalmente nell'albero del cvs.

qualche tempo fa, torvalds ha scelto di servirsi, per il proprio lavoro sul kernel, di bytekeeper, un software analogo a cvs. tale scelta provocò non poche polemiche, perché bytekeeper è proprietario e solo tra breve ne sarà rilasciata una versione open. forse proprio per questo motivo diversi sviluppatori preferirono continuare a servirsi di cvs.

di conseguenza, è necessario un meccanismo di sincronizzazione tra i due alberi: quello di bytekeeper, manutenuto direttamente da linus (al quale i più stretti collaboratori continuano a sottomettere materiale via email) e quello cvs, sincronizzati con aggiornamenti quotidiani.

è assolutamente normale che vi siano controlli di integrità sul materiale che transita da un repository all'altro, e, anzi, sarebbe imprudente non effettuare tali verifiche, se non altro per scongiurare il rischio che banali problemi di comunicazione corrompano uno dei due alberi; la verifica automatica che ha evidenziato la modifica sospetta rientrava proprio in questo gruppo di controlli.

del resto, anche l'implementazione della firma digitale (gnupg) delle modifiche non sembra essere un eccesso di prudenza: servirebbe a rendere ancora più difficile mettere le mani di nascosto sui sorgenti, senza appesantire significativamente il lavoro degli sviluppatori. perché non approfittarne? l'unico problema è, al momento, l'impossibilità di modificare in tal senso bytekeeper, in quanto esso non è (ancora) rilasciato sotto licenza libera.

[Sandro kensan]

Grazie molte Stefano, hai scritto cose che riassumono info lette qua e la per lo più in inglese e quindi mi è difficile comprenderle a pieno.

Questa staria tra il tecnico, lo spy story e i guru di linux secondo me è molto appassionante, io non ne so molto ma tu...

Grazie molte.

[Sandro kensan]

Si chiama proprio bytekeeper? Io avevo letto bitkeeper su kernel trap, http://www.bitkeeper.com/

[Stefano Barni]

è bitkeeper, hai ragione, bytekeeper è una mia svista

[Paolo de Bonis]

Pecato che queste cose le si dicano solo nelle comunità di free software e non in ambienti tipo istituzioni governative o altro!
Scusate, mi sbaglio, alla NASA queste cose le dicono ed anche in Cina, dove il software proprietario, per entrare, deve far vedere almeno parte del codice....