L’open source aiuta il terrorismo, parola di Microsoft

L’Alexis de Tocqueville Institution ha recentemente pubblicato un’analisi che ha fatto molto rumore nella comunità informatica perché accusa apertamente il software open source di minacciare la sicurezza nazionale e di aiutare i terroristi. Il rapporto, intitolato Opening the Open Source Debate, era stato pubblicato gratuitamente in Rete, ma è stato prontamente trasformato in versione a pagamento quando ha iniziato a suscitare vasto interesse. Si vede che anche i più rinomati centri studi devono pensare alla pagnotta. Era meglio pensarci prima, visto che ormai il documento è sfuggito ed è facilmente reperibile gratis altrove, ma lasciamo stare.

Il ragionamento proposto è questo. Il software open source (ad esempio Linux e Apache, per citarne due esempi molto diffusi) rende pubblico il proprio codice sorgente. In altre parole, chiunque può esaminarne gli intimi dettagli di funzionamento alla ricerca di vulnerabilità. Il software “chiuso” (ad esempio quello Microsoft, ma non solo), invece, non rende pubblico il proprio codice sorgente e pertanto è più difficile da analizzare e colpire. Usare l’open source per i sistemi informatici vitali, insomma, è pericoloso: un po’ come pubblicare la pianta dettagliata del caveau di una banca.

Messaggeri e messaggi

Gran parte della polemica in Rete si è concentrata, purtroppo, sul messaggero anziché sul messaggio. L’ADTI, si è detto, prende soldi da Microsoft, che guarda caso ha molto interesse a promuovere il proprio modello commerciale basato sul software chiuso e considera da tempo l’open source come un pericolo per la propria esistenza.

Una constatazione validissima (e confermata a malincuore da Microsoft), che però non risponde alle domande di fondo proposte dall’ADTI. Pubblicare il codice sorgente rende più facile il lavoro dei pirati informatici e in particolare dei terroristi? È saggio usare software di cui è pubblico ogni minimo dettaglio operativo per gestire, che so, il traffico aereo o una centrale nucleare?

La reazione istintiva a domande di questo genere è nettamente a sfavore dell’open source: viene spontaneo pensare che la segretezza del codice sorgente ponga un ostacolo ulteriore ai tentativi dei terroristi e che quindi il software chiuso sia intrinsecamente più sicuro di quello aperto. È un concetto ben noto con l’espressione security through obscurity, “sicurezza ottenuta tramite la segretezza”.

Ma in tempi in cui si dibatte di come difendersi da chi lancia aerei di linea contro grattacieli non è proprio il caso di lasciarsi andare alle reazioni istintive. In realtà il principio della security through obscurity è teoricamente valido se il software è robusto: in tal caso, tenerne segreto il codice è indubbiamente uno strato di protezione supplementare.

Fragile paravento

Il problema è che nel mondo reale le cose non stanno così. Di solito la segretezza non è uno strato supplementare, ma uno strato vitale. In altre parole, invece di rimediare alle vulnerabilità del software rendendolo intrinsecamente robusto, si sceglie abitualmente la strada più facile del segreto. Non importa se c’è una falla: basta che non si sappia in giro.

Un esempio spettacolare di questo diffusissimo atteggiamento viene proprio da Microsoft. Secondo un articolo pubblicato da eWeek, Microsoft ha testimoniato di fronte a un tribunale federale USA che alcune parti del suo codice (in particolare il cosiddetto Message Queuing) sono così difettose che “non possono essere rivelate senza pericolo”. L’unica cosa che impedisce il collasso della sicurezza delle innumerevoli aziende che usano software Microsoft è la segretezza del codice.

E se questa segretezza venisse bucata? Come forse ricorderete, a ottobre del 2000 intrusi informatici riuscirono a penetrare nella rete aziendale Microsoft e, stando alle dichiarazioni iniziali del colosso di Bill Gates (poi parzialmente ritrattate), prendere visione del codice sorgente dei suoi prodotti. Che sia successo o meno poco importa: l’incidente dimostra che dipendere unicamente dalla segretezza è estremamente pericoloso. Poter contare sul segreto induce alla pigrizia e alla trascuratezza; sapere invece che il proprio lavoro verrà scrutinato da mille occhi è un massiccio incentivo a fare le cose per bene. Barare non è ammesso.

Cosa più importante, l’episodio mette in evidenza una grande vulnerabilità del software “chiuso”: la dipendenza dal produttore. Se un programma a sorgente chiuso ha una falla, legalmente soltanto il produttore può correggerla: se decide di non farlo, chi usa quel prodotto è costretto a tenerselo così com’è (o cambiare prodotto). Purtroppo la scelta di non riparare le falle è molto frequente, come testimoniato dalle diciotto vulnerabilità di Internet Explorer ancora da correggere, alcune risalenti addirittura a un anno fa. Molti altri produttori di software chiuso sono in condizioni analoghe.

In un prodotto open source, invece, chiunque può esaminare il codice sorgente, correggerlo e pubblicare la correzione senza impedimenti legali. Di conseguenza, le vulnerabilità nel software open source vengono risolte più rapidamente. Ad esempio, la falla del browser Mozilla (e dell’interfaccia grafica X) che consentiva di mandare in crash una macchina Linux usando semplicemente un font molto grande è stata annunciata il 9 giugno 2002 ed è già stata risolta. Nei rari casi in cui la comunità di Internet tarda a risolvere il problema, nulla vieta a un’azienda di affidare l’incarico a una società di consulenza, pagata con il denaro risparmiato in licenze software. Con il software chiuso questo sarebbe un comportamento illegale.

Il segreto di Pulcinella

Un’altra falla logica nel ragionamento sull’ipotetica superiorità del software chiuso è l’assunto che il software chiuso sia, appunto, chiuso: ossia che soltanto una ristretta élite di persone fidate abbia accesso al codice sorgente.

In realtà è inevitabile e abbastanza intuitivo che l’accesso debba essere consentito a un gran numero di sviluppatori interni ed esterni all’azienda e che questo numero aumenti al crescere della complessità del progetto. Almeno uno di questi, prima o poi, sarà sbadato o vorrà fare un dispetto all’azienda o si venderà alla concorrenza (o a una potenza straniera). Succede con i segreti militari, figuriamoci se non succede con il software.

La dimostrazione del fatto che i programmatori aziendali non sono (e non possono) essere sorvegliati abbastanza da garantire la sicurezza del software chiuso è data dagli easter egg: le sorprese nascoste nei programmi, come la “Sala delle anime tormentate” e il simulatore di volo in Excel, il videogioco nascosto in StarOffice 5.2, e mille altri nel software di ogni marca. O questieaster egg sono stati inseriti con il consenso delle aziende, e in tal caso non sono una gran prova di serietà (dato che appesantiscono il computer dell’utente), oppure sono stati introdotti dai programmatori di nascosto, e in tal caso dimostrano gravi inadempienze nel reparto di controllo qualità dell’azienda.

Sia come sia, è chiaro che nel software chiuso è possibile infilare qualsiasi cosa senza che l’utente possa saperlo, e non solo è possibile, ma avviene regolarmente. Nel software open source no (e se non sapete o volete esaminare personalmente il codice sorgente, potete sempre farlo fare a un consulente esterno).

A volte avviene anche involontariamente. Per esempio, Microsoft ha recentemente distribuito in Corea delle copie di Visual Studio.Net infettate dal virus Nimda. In sé l’episodio non è stato grave, ma ha dimostrato ancora una volta che l’utente è costretto a fidarsi a scatola chiusa del contenuto del software chiuso, nel bene e nel male.

A differenza del software open source, inoltre, la stragrande maggioranza del software chiuso (non soltanto quello Microsoft) non viene distribuita adottando semplici procedure di verifica dell’integrità basate sulchecksum. L’utente del software chiuso non ha modo di sapere se quello che ha scaricato o ricevuto su CD è stato danneggiato o contaminato in qualche maniera; l’utente open source sì. In queste condizioni, dichiarare che l’approccio open source è più pericoloso di quello chiuso è una sconcezza ingiustificabile (o per meglio dire, giustificabile soltanto da una mancia molto lauta).

Il codice sorgente non serve

Ma l’errore più grave implicito nella domanda dell’ADTI è il presupposto che senza il codice sorgente i terroristi non possano commettere attacchi informatici. Il successo dei vari virus Melissa, Kournikova, Happy99, Magistr e dell’inossidabile Klez, tutti mirati a colpire software chiuso, dimostra inequivocabilmente il contrario. Le diciotto vulnerabilità già citate in Internet Explorer, e tutte quelle già risolte, sono state scoperte senza avere accesso al codice sorgente.

Se davvero avere accesso al codice sorgente facilita il compito dei terroristi informatici, allora dovremmo aspettarci un’ondata di attacchi mirata ai prodotti open source, che per definizione sarebbero più facili da esaminare e attaccare. Invece gli attacchi colpiscono principalmente il software chiuso.

Non è una questione di diffusione: stando ai dati di maggio 2002 di Netcraft.com, Apache, un server Web open source, è usato dal 67,3% dei siti attivi di tutta Internet. La soluzione chiusa di Microsoft (Internet Information Server) è adottata dal 27,4% dei siti. Se fossi un cyberterrorista, vorrei produrre il massimo danno possibile e quindi mi concentrerei sul bersaglio più grosso. Eppure questo non succede: infatti da aprile 2000 a oggi, il 58,3% dei siti attaccati con successo, secondo Alldas.org, usa software Microsoft.

In altre parole, nonostante tre quarti dei siti Internet usino software il cui codice sorgente è disponibile ai terroristi, gli attacchi informatici hanno successo prevalentemente con quel quarto di siti che usano software a codice sorgente segreto. Imbarazzante. Per tornare all’analogia bancaria, si direbbe proprio che avere la piantina del caveau non serva a molto se il caveau è costruito bene.

Sorgente aperto, mente aperta

A ragion veduta, insomma, l’open source non è questa grande minaccia per la sicurezza dell’intero mondo occidentale tratteggiata dal sedicente centro studi. Purtroppo l’idea che la trasparenza del codice conduce a una maggiore sicurezza non è intuitiva, per cui gli oppositori dell’open source hanno gioco facile nel suscitare terrori ingiustificati. Spero che questa breve controanalisi vi fornisca qualche dato razionale su cui riflettere e far riflettere.