Ho appena finito di leggere ” Fortify: open source insicuro per le imprese “. In questo articolo si leggono cose come questa :
“Il numero di buchi, sostiene Fortify, è rimasto quasi lo stesso, o persino aumentato, nelle tre versioni successive di sei dei pacchetti esaminati. Ci va giù pesante West: “Non ci sono numeri di telefono. A chi chiedi informazioni? È spesso persino difficile capire chi sia questa gente”.”
Francamente, non mi va proprio a genio che si tratti il mondo Open Source in questo modo, per cui riporto qui di seguito alcune mie personalissime considerazioni sul tema “sicurezza di Windows e sicurezza di Linux”.
Un errore ogni 50 righe di codice
Chiariamo subito un punto: il software contiene abitualmente un sacco di errori. Quando dico “un sacco” intendo proprio tanti . A seconda delle fonti delle statistiche, si può andare da un minimo di un errore per 50 righe di codice ad un errore ogni 10 righe di codice. Se tenete presente che un “aggeggio” come Windows Vista è composto da circa 50.000.000 (cinquanta milioni) di righe di codice, potete capire quanti errori noti e meno noti si possano annidare al suo interno. Un “programmino” come quelli che si sviluppano su ordinazione per molti clienti è composto abitualmente da migliaia (a volte decine di migliaia o centinaia di migliaia) di righe di codice e contiene, come minimo, centinaia di errori.
Se volete farvi una cultura sulla stabilità del codice, date un’occhiata a questo spassoso “talk” di Andrew Tanenbaum, presentato nel 2007 alla Linux Conference di Sidney: Design of a Microkernel OS .
La cosa più grave è che solo una parte di questi errori è nota. Secondo alcune statistiche, tra il 10 ed il 20% degli errori viene effettivamente scoperto senza una analisi approfondita del codice. In altri termini, anche un normale programma applicativo, sviluppato su ordinazione, contiene abitualmente centinaia o migliaia di errori e solo qualche decina o qualche centinaio di questi errori è noto agli utenti ed agli amministratori. Gli altri errori restano annidati nel codice in attesa che qualcuno li scopra e li sfrutti come punti deboli per un attacco. O, più, semplicemente, aspettano che qualcuno solleciti nel modo “giusto” il software per fare dei danni.
Sicurezza e Qualità
Questo però è più un problema di Qualità del software che di Sicurezza . Infatti, solo una esigua percentuale degli errori di programmazione può essere sfruttata per un attacco.
Ad esempio, per molti anni una delle vie preferite per attaccare un servizio (come un web server come Apache o MS IIS) è stata quella di sfruttare un buffer overflow legato alla acquisizione di qualche stringa di testo proveniente dal mondo esterno. Si inviava al servizio una “richiesta” contenente una lunghissima sequenza di “pattume” in fondo alla quale c’era del codice da eseguire. Il servizio caricava tutta questa “stringa” in RAM e, quando arrivava a sovrascrivere qualcosa di importante, andava in crash e ripartiva. In alcuni casi, il programma lasciava una parte del pattume in RAM e, al momento del riavvio, il sistema si ritrovava ad eseguire il codice inserito appositamente dall’hacker.
Di attacchi come questo ne potete trovare a decine su packetstormsecurity.org e presso altri siti di “full disclosure” o di security. Ne trovate alcuni analizzati e descritti nel dettaglio nella Reading Room di SANS .
Questa tecnica, tuttavia, funziona solo se c’è un mancato controllo del limite superiore di un array. Non funziona se il codice contiene uno qualunque tra altre decine di possibili tipi di errori. Da qualche anno a questa parte, tutto il codice dei servizi viene scritto in Python, PHP, Ruby od in altri linguaggi che fanno automaticamente i controlli del caso e che quindi non sono soggetti a questo tipo di errore. Di conseguenza, non a tutti gli errori del codice corrisponde una vulnerabilità.
Non solo: non a tutti gli errori contenuti nel codice corrisponde un “bug” visibile dall’utente. Molti errori del codice non producono effetti visibili e/o non vengono mai “attivati” dal comportamento normale dell’utente. In altri termini, molti errori sono visibili solo in condizioni di test deliberatamente eccezionali.
Quindi parlare di “scarsa sicurezza”, in presenza di una quantità “elevata” di errori del codice o di bug visibili, è quantomeno fuorviante.
Anche limitandosi alle vere vulnerabilità, tuttavia, le cose stanno in modo piuttosto diverso da quello che potrebbe sembrare leggendo le dichiarazioni di Fortify.
La Sicurezza Closed Source
Per alcuni anni, il mio gruppetto ed io abbiamo lavorato su Windows (NT, 2000 ed XP). Come quasi tutti i consulenti abbiamo fornito hardware, software, manodopera specializzata, servizi di manutenzione, di installazione, di aggiornamento del software e via dicendo. Tra le nostre attività, c’è stata per un periodo anche la gestione della sicurezza: test di penetrazione, gestione degli aggiornamenti, installazione e manutenzione di firewall e di altre “network appliance” e via dicendo. Ad un certo punto, abbiamo deciso che non avremmo più accettato di seguire il tema “sicurezza” per i clienti che usavano Windows (e solo per quelli che usavano Windows).
Perché?
Perché “non ci si arrivava in fondo”. Noi facevamo il giro ad installare i service pack ed a configurare correttamente il software e, dopo due minuti, la situazione era già cambiata a causa degli aggiornamenti di Microsoft e dei suoi partner (che a volte modificano anche alcuni aspetti della configurazione) e, soprattutto, a causa del comportamento irresponsabile degli utenti e dei loro capi.
Abbiamo visto di tutto: password scambiate come figurine, firewall disattivati con stizza per accedere al sito porno del momento, giochini di ogni sorta installati senza riflettere (spesso usando l’utenza “administrator” anche quando sarebbe bastata una utenza normale), antivirus lasciati scadere per disinteresse etc. Una delle cose più scioccanti è stato scoprire che molti impiegati e molti dei loro manager lasciavano il laptop aziendale – incustodito, privo di antivirus e connesso ad Internet! – nelle mani dei loro figli di 9 o 12 anni durante il week-end! “Tanto è dell’azienda… non c’è sopra niente di importante…” Ad aggravare la situazione, ci si sono messi anche Microsoft ed altri produttori di software. Per ragioni a noi incomprensibili, infatti, alcuni programmi utente girano solo con i privilegi da amministratore , mandando a carte 48 ogni possibile concetto di sicurezza.
Come potete capire, per garantire la impenetrabilità di una rete o anche di una singola macchina, in queste condizioni, ci vuol un sistema nato per essere sicuro. Se chiunque, sia esso un utente od un partner che opera via Internet, può mettere le mani alla configurazione del sistema, garantirne la sicurezza diventa praticamente impossibile. Se poi dovete far affidamento su un antivirus che spesso non c’è… la frittata è completa. Da questo punto di vista, Linux è già molto meglio di Windows, soprattutto dei vecchi Windows NT e 2000, ma, in realtà, sarebbe necessario un sistema basato su messaggi e su apposite access list, come MS Singularity .
Per chiarezza: gli utenti irresponsabili ci sono in qualunque ambiente ma una cosa è tentare di porre un limite alle loro azioni ed un’altra cosa è assecondarli o fregarsene. Unix (e quindi Linux) tenta seriamente di arginare i comportamenti irresponsabili, soprattutto attraverso l’uso di “default” orientati alla sicurezza. Inoltre, fornisce agli amministratori di sistema gli strumenti necessari per imporre e mantenere uno stato di sicurezza. Questo non è sempre vero nel mondo Windows.
Il Servizio Clienti Closed Source
Nelle condizioni che ho appena descritto, francamente, non serve a nulla avere un numero di telefono da chiamare. Il tecnico dall’altra parte può solo ripetere cose che, per professione, sei già tenuto a sapere.
In realtà, non serve a niente avere un numero da chiamare nemmeno per mettere una pezza ai bug ed ai buchi di vulnerabilità. Quasi sempre, il tecnico si limita a dirti che il problema è già noto, che ci stanno lavorando, e che nell’attesa devi disattivare il servizio o devi disattivare qualche specifica funzionalità. Come nel caso precedente, fino a questo punto ci si arriva anche da soli. Basta consultare il database degli errori noti, leggere qualche articolo in Rete e/o fare uso di un minimo di buon senso e di competenza professionale.
La Sicurezza Open Source
Quando abbiamo “abbandonato” la gestione della sicurezza di reti e macchine basate su Windows, abbiamo però continuato a fornire lo stesso servizio su reti e macchine che usano Unix (Linux, BSD e persino Mac OS X).
Perché?
Né Linux, né BSD, né Mac OS X sono intrinsecamente più sicuri di Windows, almeno non di Windows NT, 2000, XP e Vista. Tutti questi sistemi, nelle mani di un utente esperto e responsabile possono essere resi “sicuri” (nella misura necessaria per le loro attività quotidiana). L’unica vera differenza è che su Windows bisogna acquistare, installare e mantenere aggiornato un antivirus. In nessuno degli altri casi questo è necessario.
La differenza vera la fanno la più rigida compartimentazione delle utenze, la resistenza intrinseca al malware ed una gestione più responsabile dei default durante l’installazione.
Su Unix la differenza tra l’utenza “root” (amministratore) e le utenze normali è chiara, inequivocabile e non può essere facilmente ignorata. Molte distro, di default, non permettono l’accesso grafico (Gnome o KDE) a root e molte distro non permettono l’accesso remoto (via internet) a root. Inoltre una utenza “normale” non può essere facilmente dotata delle capacità specifiche di root. Insomma: l’utente non ha modo di equivocare o di pasticciare con le utenze: root è root e gli altri sono un’altra cosa.
Questo impedisce agli utenti di fare cose assurde come prendere l’utenza “creatura”, destinata al figlio di 4 anni, e di attribuirgli i privilegi di amministrazione per non dover premere il tasto “OK, lo so.” ogni volta che Windows si lamenta di qualcosa.
La resistenza al malware è più una conseguenza dell’uso di software non-Microsoft che di altre caratteristiche. Come ha fatto notare anche l’US CERT, il solo fatto di non utilizzare MS Internet Explorer rende molto meno vulnerabile l’intero sistema all’attacco da parte di virus, worm, trojan ed altri malware (vedi: http://www.kb.cert.org/vuls/id/713878 ). Questo vale anche per MS Outlook (ora MS Mail), per MS Word, Access, PowerPoint e via dicendo. La maggiore sensibilità al malware del software Microsoft è soprattutto la conseguenza della maggiore vulnerabilità degli interpreti di linguaggio usati per l’automazione dei compiti e per lo sviluppo di personalizzazioni. L’interprete Visual Basic (VBA) presente in MS Office ed in quasi tutti gli altri programmi MS è notoriamente il primo responsabile di molte infezioni, seguito a ruota dall’interprete JavaScript di MS Internet Explorer e dal vecchio interprete delle Macro di Word ed Excel.
Anche altri programmi, non Microsoft, come OpenOffice, Firefox e Thunderbird, contengono degli interpreti di questo tipo ma nessuno di essi si è mai rivelato vulnerabile come quelli di Microsoft (e non per mancanza di interesse da parte dei virus writer). Curiosamente, Microsoft ha persino risposto in maniera stizzita alle critiche che le sono giunte in passato dalla comunità degli esperti di sicurezza riguardo a questi linguaggi. Ad esempio, la richiesta di disattivare certe funzionalità pericolose (come il preview dei messaggi di posta in formato HTML di Outlook) è stata liquidata come infondata.
Gli interessi degli utenti o quelli dei partner?
In questo si coglie una delle differenze più importanti tra il mondo Open Source ed il mondo Closed Source (soprattutto Microsoft): la capacità di ascoltare gli utenti.
Francamente, è difficile credere che certe decisioni di Microsoft, come la già citata questione delle preview dei messaggi HTML, siano dettate da motivazioni razionali. Molti osservatori, tra cui il sottoscritto, vedono in queste scelte la volontà di favorire Microsoft stessa ed i suoi partner commerciali anche a discapito della sicurezza e della autonomia dell’utente (del proprietario del PC). Alcune di queste funzionalità, infatti, servono soprattutto ai partner di Microsoft per fare i loro comodi sulla macchina dell’utente. Questo è, ad esempio, il caso delle preview HTML: sono certamente più utili agli operatori di Internet che inviano materiale pubblicitario che all’utente che, a causa della preview, si “becca” un virus come Nimda (vedi anche US CERT su Nimda ).
Default
Più in generale, questo disinteresse di Microsoft per la sicurezza e per l’autonomia operativa dell’utente si abbatte sugli utenti sotto forma di assurdi default al momento dell’installazione.
Ad esempio: Windows dispone di utenze separate (administrator/altri) almeno da Windows NT (1998) ma solo di recente (Windows XP e Windows Vista) è diventato obbligatorio creare una utenza “admin” ed una utenza “user” al momento dell’installazione. La creazione di due utenze separate è una pratica normale sui sistemi Unix dal 1970.
Questo vale anche per le impostazioni di molti strumenti che dovrebbero garantire la sicurezza del sistema, tra cui le impostazioni dei già citati interpreti di linguaggio integrati nei programmi Microsoft. Addirittura, per comprensibili (ma discutibili) ragioni commerciali, ha fatto in modo che sia sostanzialmente impossibile rimuovere MS Internet Explorer da Windows (visto che è proprio Explorer che genera e gestisce l’interfaccia grafica di Windows). Questo vuol dire che non ci si può liberare in nessun modo del programma che, da solo, viene considerato responsabile della trasmissione del 30 – 60% del malware (a seconda delle fonti).
Insomma: se installate ad un cliente una normale distro Linux Ubuntu , e seguite la procedura standard , ottenete automaticamente un sistema sicuro ( ragionevolmente sicuro, per essere esatti).
Se installate Windows (specialmente XP, 2000 ed NT) ottenete un sistema non sicuro o, per essere più gentili, non altrettanto sicuro di Ubuntu. In particolare, ottenete un sistema vulnerabile a molto malware. Come minimo, dovete installare un antivirus per ottenere un sistema equivalente a Linux. Inoltre, è necessario l’intervento di una persona competente per sistemare molti “default” e per trasformare questa installazione in un sistema sicuro come quello garantito di default da Ubuntu.
La cosa più inquietante è che per rendere Windows sicuro quanto Linux è necessario, come prima cosa, disinstallare molto software Microsoft che è notoriamente vulnerabile e sostituirlo con software tipico dell’ambiente Linux. Ad esempio, è necessario sostituire MS Office con OpenOffice o ThinkFree e MS Outlook con Thunderbird.
A questo punto, francamente, viene da chiedersi per quale motivo non si dovrebbe usare direttamente Linux.
Il Servizio Clienti Open Source
A questo punto è chiaro che il Servizio Clienti del mondo Open Source diventa molto meno indispensabile di quanto si potrebbe credere. I bug per i quali è realmente necessario l’intervento dei produttori sono piuttosto rari (uno all’anno, o anche meno, per ogni singolo programma) e vengono prontamente risolti, spesso grazie all’intervento tempestivo di un utente che dispone anche delle necessarie capacità tecniche.
Teoricamente, infatti, è possibile cercare e correggere gli errori all’interno dei sorgenti, senza aspettare l’intervento di altre persone. Si noti che questo è possibile solo con il Software Open Source . Se rilevate un problema con MS Internet Information Service, potete solo segnalarlo a Microsoft ed aspettare. Se rilevate un problema su Apache, e avete le capacità tecnica per farlo, potete cercare la fonte del problema nel codice e correggerlo. Tuttavia, non è quasi mai necessario sfruttare questa possibilità.
In quasi dieci anni di attività su Linux, infatti, non ci siamo mai trovati alle prese con un bug o con una vulnerabilità critica che non sia stato risolto nel giro di alcuni giorni al massimo . Quasi sempre, siamo venuti a conoscenza del problema solo perché ci è stata segnalata la necessità di installare la patch da parte degli stessi produttori.
Intendiamoci: problemi di sicurezza ne abbiamo avuti anche noi, su Linux e su BSD. Non viviamo in paradiso. Tuttavia, non abbiamo ancora sperimentato situazioni veramente critiche come quelle prodotte da Code Red , Nimda ed altri virus. Come noto, il flagello dei virus (e di quasi tutto il malware esistente), colpisce solo Windows e solo il software che gira su di esso. Non è una differenza da poco.
Anche la triste realtà delle backdoor, dei rootkit e delle botnet resta una caratteristica del mondo Windows e solo del mondo Windows. Né Linux, né BSD né Mac OS X sono mai stati coinvolti in questo gioco. Il solo fatto che immense botnet come Storm , Kraken e Srizbi possano esistere, e che coinvolgano solo macchine Windows, dovrebbe far riflettere.
Due pesi e due misure
L’analisi del codice Open Source che ipotizza Fortify è semplicemente priva di giustificazioni. Come abbiamo detto, solo una esigua percentuale degli errori di programmazione si traduce veramente in vulnerabilità. Rovistare in mezzo a centinaia di migliaia di righe di codice in cerca di queste vulnerabilità è un’impresa che costerebbe milioni di euro. Se le righe di codice sono milioni, è semplicemente impossibile fare un’analisi di questo tipo. In ogni caso, non ne varrebbe la pena: servirebbe solo a garantire una sicurezza che è possibile garantire con altri mezzi (firewall, sistemi di rilevamento delle intrusioni e antivirus).
Ma, soprattutto, perché mai una azienda dovrebbe sottoporre il codice Open Source che utilizza (Apache, Tomcat, Jboss o simili), e solo quello , ad una code review così estesa, approfondita, costosa e impegnativa? Il codice Closed Source è comunque molto meno sicuro e, soprattutto, non potrebbe mai essere sottoposto ad una analisi di questo tipo . Se si è disposti ad accettare i rischi di MS IIS, il cui codice non può essere ispezionato o riparato, perché mai ci si dovrebbe fare dei problemi per Apache o Jboss, dei quali si dispone invece dei sorgenti?
Una code review come quella ipotizzata da Fortify ha senso solo in alcune, rarissime applicazioni e, comunque, è possibile solo su software Open Source. Invocarla in questo contesto serve solo a rendere evidente quanto sia faziosa l’analisi di Fortify.
Conclusioni
Fortify può dire quello che vuole ma resta il fatto che avventure come quella di Nimda e di Code Red sono effettivamente costate molto alle aziende che usavano Windows. Non sono rischi teorici come quelli di cui si accusa il mondo Open Source. Lo sostiene addirittura il Gartner Group:
“Far sì che i Web server IIS (Internet Information Server) esposti ad Internet IIS siano sicuri, comporta per le aziende un costo di manutenzione molto alto”, si legge in un’analisi pubblicata dal Gartner pochi giorni dopo la rapida diffusione di Nimda. “Le aziende che stanno usando il server Web Microsoft IIS devono aggiornare ogni server IIS con ogni patch di sicurezza rilasciata da Microsoft su base quasi settimanale. Tuttavia Nimda (ed in minor misura Code Red) ha nuovamente dimostrato l’alto rischio insito nell’utilizzo di IIS ed il grande sforzo necessario per stare al passo con le frequenti patch di sicurezza di Microsoft.”
Nell’analisi del Gartner, firmata da John Pescatore, si arriva addirittura a consigliare alle aziende colpite da entrambi i worm, Code Red e Nimda, di “prendere immediatamente in considerazione alternative a IIS (…) come iPlanet e Apache. Sebbene questi server Web abbiano richiesto alcune patch di sicurezza, essi offrono maggiore affidamento di IIS e non sono sotto l’attacco attivo di un vasto numero di creatori di virus e worm”. (Da Nimda non molla. IIS sotto processo )
Se la storia deve insegnarci qualcosa, allora la storia ci insegna a fidarci del software Open Source ed a diffidare di quello Closed Source. Non è una questione di opinioni ma il semplice risultato della conta dei cadaveri sul campo di battaglia: per ogni Apache “schiantato” ci sono 100, o forse 1000, MS IIS.
Ti potrebbe interessare
23 lug 2008