-froot: a volte ritornano, e ricordi sul mercato del lavoro

Leggo da Securiteam che il demone telnet di Solaris ha una vulnerabilità che si sfrutta in modo simile alla vulnerabilità che AIX aveva nel 1996. Non credo che i due problemi abbiano in realtà la stessa origine, sia perché se lo stesso exploit avesse funzionato su Solaris, allora si sarebbe saputo, sia perché la vulnerabilità di AIX, pur essendo sfruttata principalmente con rlogin, era in realtà del programma login. Tuttavia vale la pena di notare di nuovo come ci siano in giro vulnerabilità banali da sfruttare, che aspettano solo di essere scoperte, e che nel caso specifico derivano da una logica completamente sbagliata dal punto di vista della sicurezza (vedi commenti al codice nell’articolo).

Perché ricordo così bene il problema di login su AIX? Nel 1996 mi ero laureato da poco, e stavo facendo un po’ di attività di sicurezza al Dipartimento di Informatica a Pisa, in attesa di capire che fare della mia pelle e della mia laurea. La mia tesi, per la parte pratica, aveva sfruttato come base una vulnerabilità di sendmail per fare dell’attività di “penetration testing”.

Un giorno dei mei amici venne da me e mi disse che un loro conoscente, che era sistemista in una grossa azienda, gli aveva detto che questa azienda stava installando un firewall basato su AIX. Allora chi si occupava di sicurezza i prodotti li conosceva tutti, e io sapevo che quel prodotto era una ciofeca. Presero quindi accordi per una demo. Il nostro scopo era mostrarci competenti e far vedere quanto fosse cattiva la loro scelta, in modo da installargli noi un firewall come si deve. Al momento concordato, io sfruttai la stessa vulnerabilità di sendmail, che era attivo e non patchato sul “firewall”, per aprirmi un xterm (la vulnerabilità era nota da quasi un anno). Di lì, sfruttai la vulnerabilità del login (almeno l’rlogin non lo avevano lasciato aperto da remoto) per diventare root. Tempo della demo: circa due minuti.

Il motivo per cui racconto questo episodio non è chiacchierare del passato, ma metterci la moralina finale legata al mercato del lavoro. Dopo che l’azienda seppe dell’esperimento, chiese spiegazioni al fornitore del firewall che disse semplicemente che il sistema non era ancora completamente configurato, e installò le patch per le due vulnerabilità. Naturalmente il fornitore rimase quello, e anche il prodotto, che nonostante le patch ad AIX rimaneva ovviamente una ciofeca. Fu allora, e qui arriva la morale, che cominciai a capire che quello che conta per entrare nelle grosse aziende non è tanto la competenza quanto il canale.

Posted in ict, Sicurezza, Varie | Comments Off on -froot: a volte ritornano, e ricordi sul mercato del lavoro

Sicurezza e macchine virtuali

L’uso di macchine virtuali come meccanismo per tenere separati ambienti diversi ha una lunga storia, l’ambiente più noto è stato senz’altro il VM/CMS dei mainframe IBM. L’uso di macchine virtuali ha  sempre avuto risvolti positivi sulla sicurezza in termini di segregazione e confinamento, ma è solo negli ultimi anni, grazie principalmente a VMware, che la virtualizzazione ha trovato il suo spazio anche nel contesto dei PC e dei sistemi distribuiti. Io ho usato pochissimo il VM, e solo come utente, mentre invece uso VMware da parecchio, e penso che questi meccanismi possano aiutare molto per la sicurezza, anche del singolo utente. Ho ancora almeno una versione 1.1.2 del 1999, periodo in cui VMware era solo su linux, ed essendo Windows98 il sistema operativo Microsoft più diffuso, gli utenti di VMware dicevano che “VMware aveva messo Windows 98 nel posto che gli compete: una finestra di un sistema operativo vero” 😉 Parto dalla mia esperienza personale. Ho cominciato ad usare VMware per avere una macchina virtuale Windows98  in un ambiente confinato, per usarci Office (OpenOffice, che allora era ancora solo Staroffice, non era ancora un’alternativa), per usare l’hardware che con linux mi dava problemi (lo scanner e una stampante che allora era mal supportata) e per accedere a quei siti che, accidenti a loro, erano accessibili solo con Explorer. Questo voleva dire che avevo una macchina virtuale Windows98 sempre attiva sul mio Desktop KDE, in modalità host only (ora naturalmente c’è XP). Sul linux sottostante, squid garantiva ai programmi autorizzati da Zone Alarm l’accesso alla rete, mentre samba mi permetteva di condividere fra macchina Windows e macchina Linux le sole directory necessarie. Dal punto di vista della configurazione, la cosa non è mai stata complicata. Dal punto di vista dell’hardware, l’unica vera esigenza è sempre stata quella di avere parecchia memoria fisica, perché VMware ne usa parecchia e swappare rende il tutto decisamente poco utilizzabile. Certo, la macchina virtuale è più lenta, ma per usare Office non ci sono grandi esigenze. Le prime versioni di VMware non avevano snapshot ed eseguivano una sola macchina virtuale per volta, quindi una serie di altre cose che si possono fare adesso non erano possibili. Per la normale navigazione e la posta, usavo Mozilla, naturalmente su linux. Adesso VMware ha anche la possibilità di prendere uno o più “snapshot” (istantanee) della memoria: se non ci piace qualcosa che è cambiato nel nostro sistema, ad esempio un programma che abbiamo installato, possiamo tornare a uno snapshot che abbiamo preso e la macchina torna esattamente nelle condizioni originali, molto più che disinstallando o cancellando. Poi, adesso è possibile eseguire più macchine virtuali contemporaneamente. Molte prove di configurazioni di rete le faccio su macchine virtuali, anziché configurare magari sei o sette macchine per ricreare l’ambiente di un cliente. Naturalmente, è chiaro che con un solo processore sotto ci sono delle sincronizzazioni che non permettono di fare certe prove in un ambiente virtuale, ma non è il genere di cose di cui mi occupo.

Quali sono i vantaggi di una configurazione di questo tipo? Primo: uso abitualmente un ambiente linux senza rinunciare ad applicazioni e hardware supportati solo da Windows. Mi riferisco naturalmente ad utilizzi “seri”: far girare un videogioco sotto VMware è ragionevole solo per giochi che non chiedano troppo alla grafica, e comunque l’audio è sempre mediocre; tuttavia un generico “carico del processore” è gestito abbastanza bene, e c’è il vantaggio che molte cose si fanno comunque sotto linux, che anche con KDE è molto più leggero di un Windows “contemporaneo”. Tuttavia, uso tranquillamente i programmi che chiedono molto alla virtualizzazione, e anche l’utility di ripulitura del disco di PGPDesktop non ha problemi (anche se in questo caso, non bisogna dimenticare che nel disco fisico “sotto” quello virtuale i dati possono esserci ancora). Secondo: posso “provare” configurazioni e programmi senza rischiare di contaminare il mio ambiente di lavoro. Ad esempio, se devo provare qualche programma di provenienza un po’ troppo “strana”, lo provo su una copia di una macchina virtuale, e poi butto via l’intera macchina.

La macchina virtuale non ha accesso diretto a Internet, e quindi l’unico traffico che fa uscire è quello che io ho abilitato: niente scan e comunicazioni strane, a meno che naturalmente non passino da squid. Altre comunicazioni le abilito cofigurando proxy tcp generici, quando serve: sembra complicato, ma in realtà l’ultima volta che mi è servito attivare un nuovo proxy è stato qualche anno fa. Quindi, niente virus che fanno lo scan della rete, e virus che fanno lo scan della rete non vedono la mia macchina virtuale; questo è un vantaggio del non usare VMware in modalità bridge. In realtà si tratta di una precauzione di cui non ho mai avuto bisogno: il solo fatto di navigare e gestire la posta con Mozilla su linux, salvando gli attachment da vedere con Office su VMware, ha fatto sì, insieme ad un po’ di buon senso, che le mie macchine virtuali non si prendessero mai un virus, da quando le uso e quindi almeno dal 1999. Al punto che ogni tanto salvo apposta qualche attachment che sicuramente è un virus per farlo vedere ad Antivir, ed assicurarmi che sia efficace e aggiornato 😉 Naturalmente, per le macchine reali linux, il mio vero ambiente di lavoro, di virus neanche parlarne.

Altro piccolo consiglio per chi usa cose come eMule: mettetelo su una macchina virtuale… Altro uso: le applicazioni obsolete. In salotto ho un PC con Windows XP destinato ai bimbi, e molto più “pompato” dei miei. Tuttavia, alcuni giochi per bimbi pensati per Windows98 funzionano male. Così, ci ho messo il player di VMware con Windows 98 (tanto ormai le licenze mi avanzano), e i giochi “legacy” li usano lì. Naturalmente, essendo bambini e imparando in fretta, sanno già che per usare quei giochi prima devono far partire VMware 😉 , che in modalità full screen offre un ambiente assolutamente normale, e su una macchina pompata anche l’audio funziona bene. Il discorso vale per qualsiasi applicazione che abbia bisogno di sistemi obsoleti: ho avuto solo qualche problema con vecchi giochi per il DOS, ma devo ammettere che non ci ho perso molto tempo. Per il Prince of Persia originale, uso dosemu 😉

Limiti? Naturalmente ce ne sono. La macchina virtuale non è completamente isolata. Interagisce con il sistema attraverso due moduli del kernel, che in caso di vulnerabilità permettono un accesso diretto all’hardware, e anche VMware ha avuto ovviamente la sua dose di vulnerabilità. Tuttavia, si tratta di sfruttare vulnerabilità specifiche in un contesto decisamente più controllato di quello di una macchina Windows “reale”. La mitigazione del rischio è più adeguata a molti contesti.

Inoltre, la macchina virtuale ha accesso ad alcune directory via samba, e quindi alle informazioni contenute. Di nuovo: VMware è un ottimo sistema di segregazione e confinamento, ma non è una panacea.

Ultima nota: io naturalmente uso anche macchine fisicamente separate, a seconda del tipo di attività; è però un mio problema personale 😉 , non è certo la situazione in cui può lavorare una persona normale. Se poi qualcuno non se la sente di usare VMware su linux, può sempre usarlo su Windows… certo, l’effetto non è lo stesso.

Posted in ict, Sicurezza | 2 Comments

E che dire di Javascript?

Un articolo di Wired che descrive in modo abbastanza chiaro i problemi dell’uso di Javascript nel Web 2.0. Di nuovo, il problema, molto più che il linguaggio in sè, è l’uso che ne viene fatto. Anche questo in realtà non è un problema nuovo: quando i cgi sono diventati di uso comune, era pieno di siti in cui venivano utilizzati come cgi degli script fatti in casa, che trasformavano il sito in un colabrodo. Adesso il problema è con le applicazioni Javascript e PHP, ma la base è sempre quella: la sicurezza ai programmatori non viene insegnata, o se viene insegnata, spesso si tratta di concetti astratti o validi solo per specifici contesti e linguaggi, senza formare realmente una capacità di riconoscere e affrontare metodicamente i problemi. E comunque, anche dove questa capacità ci sia, non è certo molto richiesta…

Posted in Sicurezza | Comments Off on E che dire di Javascript?