On Monday 27 April 2009 09:33:34 pm [email protected] wrote: > Non è l'unica differenza, quella è una e IMHO non è la più importante. Ci > sono molte differenze anche per la presenza o meno di determinati programmi > nell'installazione base (quindi superfici di attacco differenti), per le > scelte dei programmi di default (p.es. Debian installa exim, RedHat > installa postfix), per come sono compilati i programmi (per esempio su > Debian postfix non ha compilato il supporto ldap mentre su RedHat sì), per > le impostazioni di default (selinux su Debian è disabilitato mentre su > RedHat è abilitato), e si potrebbe continuare a lungo.
Credo che questo ragionamento non tenga conto di un fattore IMHO importante. Le "killer applications". Concorderai con me che il webserver più utilizzato in ambiente gnu/linux è apache (http://news.netcraft.com/archives/web_server_survey.html apache serve files su più del 40% di tutti i webserver del mondo, sistemi proprietari compresi), la configurazione dovecot-postfix è anche molto comune. Openssh infine è in pratica in qualsiasi server. Concordo con te nel fatto che vari "moduli" siano abilitati su alcune macchine mentre in altre no, ma questo elemento è riproducibile anche in IIS (http://msdn.microsoft.com/en-us/library/bb757040.aspx). Anche lo stesso .NET framework potrebbe essere presente come potrebbe non essere presente in qualsiasi macchina windows. Secondo questo ragionamento, portato alle sue estreme conseguenze, allora nessun s.o Windows è uguale ad un altro a meno che non si istallino esattamente gli stessi programmi. Per complicare o chiarire il tutto pensa anche ad Apache o Apache Tomcat su Windows che in ambiente Java non è una soluzione poco comune. > > | Un applicativo, magari compilato > | staticamente, gira su tutti i dispositivi che fanno girare qualsiasi > | gnu/linux. > > Sì, ma applicativi compilati staticamente e diffusamente installati su > macchine Linux praticamente non ne esistono. Mi riferivo al malware. Se riuscissi ad avere accesso ad un s.o *nix, la prima cosa è provare a far girare un applicativo staticamente compilato. Questo gira su qualsiasi kernel linux, l'importante è rispettare l'architettura. Non importa che il server dietro sia una debian o fedora o ubuntu. Allo stesso modo un .exe ti gira in qualsiasi s.o Windows (.NET a parte), qui non hai nessun problema di architettura dato che sistemi windows sono sono x86 | x86_64 > Le componenti di base che > hanno realmente ampia diffusione e poca variabilità sono rappresentate da > codice in gran parte vecchio, statico e molto testato (pensa per esempio > alle utility di base come cat, ls, vi, cp, e le libc stesse), quindi > raramente vi si scoprono nuove vulnerabilità. Anche sistemi proprietari hanno i veri del, cd, dir, copy, ecc ecc. Tuttavia mentre in cat, ls, vi, cp e la libc puoi vedere il codice e vedere realmente quello che fanno e se ci possono essere possibili falle, con gli altri tool dei sistemi proprietari non è possibile dire lo stesso. > Il kernel è solo una minima parte del sistema, decisamente importante ma > non l'unica. Per esempio raramente bug nel kernel possono essere sfruttati > per accedere al sistema da remoto; più frequentemente consentono "solo" > local privilege excalation. Concordo e aggiungo che è proprio perchè il kernel linux è gpl che garantisce questa sicurezza. Bug introdotti negli stack protocollari possono essere più facilmente trovati e corretti evitando quindi spiacevoli "remote exploit" e "local privilege excalation". > Il problema in questi casi si sposta quindi dal kernel, che può essere > simile su molte macchine, alle applicazioni in userspace che invece sono > più variabili da macchina a macchina. Un payload che sfruttasse un baco del > kernel, dovrebbe essere veicolato nel sistema sfruttando bug di altri > prodotti, e se ciò non rappresenta normalmente un grosso problema per > un'intrusione condotta manualmente, per un malware che puntasse ad una > diffusione automatica e veloce sarebbe un ostacolo non di poco conto. :-) Stesso identico concetto può essere applicato alle macchine con s.o Windows. Assume quindi un punto focale il sysadmin dato che è lui che stabilisce il livello sicurezza del sistema. > > | Il codice aperto è una prerogativa per un software sicuro, il codice > | viene testato, letto e corretto. Quando si trova un bug capace di > | compromettere la sicurezza di interi sistemi, la patch arriva in poche > | ore dalla scoperta del bug. > > Mi pare che in diverse occasioni ciò sia stato smentito, o perlomeno > ampiamente ridimensionato. La disponibilità del codice semplifica la > ricerca di bug per gli sviluppatori, ma anche per eventuali attaccanti. E' meglio un applicativo che puoi sapere che sia vulnerabile o un sistema in cui non puoi sapere, a priori, prima di metterlo su, se è vulnerabile o no? Questo ragionamento non tiene conto, IMHO, dell'ecosistema opensource. Il codice opensource è molto riutilizzato da applicazione ad applicazione e sopratutto, più persone modificano le stesse parti di codice = più persone leggono il codice già al momento dello sviluppo. Non è un caso che i più diffusi RCS (svn, hg, git) si siano diffusi attraverso i canali opensource. Quindi si, il codice è disponibile agli attacker, ma prima che questo codice esca in una release di un software almeno quattro occhi lo hanno letto. > Quanto alla velocità di patching questa si misura dal momento in cui la > falla viene portata all'attenzione degli sviluppatori, ma non si può sapere > se tale bug fosse o meno noto ad altri attaccanti prima di tale momento. > Due casi emblematici sono stati il bug di ssl su Debian, lì bello > disponibile per 2 anni e passato inosservato e la backdoor di Dansie > Shopping Cart, anch'essa passata inosservata per parecchio tempo. E' indicativo il fatto che dopo la scoperta del bug ssl in Debian, la patch è arrivata in meno di 24 ore. Per i "cursori mannari" credo si siano passate svariate volte le 24 ore. Ritornando al nostro discorso, riguardo alla ipotizzata "variabilità genetica"... > Magari qualche cracker le conosceva già e le sfruttava... chi lo sa? > Credo che questo sistema sia valido per qualsiasi sistema informatico, dato che la legge zero è "l'unico sistema sicuro è un sistema spento" > | Su Windows invece, non ho mai visto un utente che non abbia i privilegi > | di amministratore > > Conosco pastrocconi su Windows e ne conosco anche su Linux, così come > esistono distribuzioni Linux che ti inducono a lavorare come root. > La componente umana e l'educazione sono certamente un fattore primario, ma > non è IMHO da tenere in considerazione in questo discorso relativo alla > vulnerabilità dei sistemi nei confronti di determinate categorie di > malware. Se si vuole parlare di sistema informatico (non sistema operativo) le componenti principali sono hardware, software (compreso il sistema operativo) e sysadmin. Il sysadmin è parte integrante del sistema e ne influenza la sicurezza. In questo contesto, IMHO realista, non esiste un sistema operativo più sicuro, a priori, di un altro. Se il sysadmin, alla scoperta di una falla, non applica la patch rilasciata da chi ha sviluppato il software, non si deve lamentare se gli sparisce il file che contiene il numero della sua carta di credito :) Cercando di trarre delle conclusioni: La tua tesi era che i virus si sistemi linux non si diffondo grazie alla "variabilità genetica" Ho cercando di dimostrare che la "variabilità genetica" esiste anche su sistemi non basati su linux e che questa dipende dal sysadmin visto che installa o meno software sul sistema operativo. Ho cercato di far vedere che alcuni sistemi operativi ed ecosistemi software hanno adottato delle politiche per la ricerca dei bug probabilmente più efficaci di altre, ma che "non esiste un software marchiato sicuro 100%". Infine ho cercato di far vedere come la propagazione del malware sia strettamente collegato alle azioni dei sysadmin/utenti. Concludo dicendo che... Se nel 2000 migliaia di utenti non avessero cliccato su una email con oggetto: "I love you", non ci sarebbero stati $5.5 bilioni di danni. -- Vincenzo Ampolo http://goshawknest.wordpress.com http://vincenzo-ampolo.net
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
