Quantcast
Channel: KEIN PFUSCH, BITTE!
Viewing all articles
Browse latest Browse all 561

Oh, l'open source.

$
0
0
Ogni volta che si parla di spionaggio informatico arriva qualcuno che mi dice "ehi, ma se usi sistemi opensource sei al sicuro". Salta sempre fuori qualcuno che dice che "ma li' puoi vedere il codice", e che "comunque puoi cambiare distribuzione" e che siccome non ci sono di mezzo colossi come Microsoft o Apple, allora OSS e' buono e vi difende la privacy. Saro' molto sincero, sono semplici montagne di merda.



Il primo punto e' semplicemente che nessuno di voi e' mai andato a leggere una sola riga del codice sorgente . Non dico i milioni di righe che compongono il kernel di Linux, dico quelle di  una qualsiasi applicazione. Sono milioni e milioni di righe di codice per LibreOffice, e voi siete DAVVERO sicuri che non ci siano pezzi che spiano li' dentro?



Voglio dire, avete il codice del kernel, e in un pacchetto separato gli headers , e le libc e in un pacchetto separato il codice.



Vorrei capire innanzitutto chi vi darebbe la certezza che le librerie che usate siano il risultato della compilazione di quel codice.TEORICAMENTE potete saperlo. Ma nessuno di voi lo ha mai misurato personalmente.



Alcuni di voi diranno che si sono compilati completamente il sistema operativo. Il che e' bello, ma... avete dato un occhio al codice del compilatore? Se il vostro compilatore e' inquinato , potrebbe aggiungere il segmentino "manda a Obama" in qualsiasi punto.
Cosi', il punto e':

  • TEORICAMENTE l' Open Source vi permette di verificare che non ci siano backdoor nel codice. In pratica nessuno di voi ha mai letto il codice di una qualsiasi delle applicazioni che usa, da X windows alle glibc, dal Kernel al vostro browser. Partite tutti dall' idea che se ci fosse qualcosa QUALCUN ALTRO se ne sarebbe accorto.
  • TEORICAMENTE l'Open Source vi permette di ricompilarvi tutto dai sorgenti. La quantita' di updates disponibili quotidianamente , diciamo per un ubuntu, vi richiederebbe una build farm solo per per tenere aggiornato il sistema. Oppure tenervi un sistema obsoleto, con bachi noti, e magari buchi di sicurezza noti.
  • TEORICAMENTE gli strumenti e le librerie che usate per compilare arrivano coi sorgenti. IN realta', probabilmente nessuno di voi sa di preciso che diavolo faccia il suo compilatore e che accidenti di codice viene linkato. Basterebbe agire sul linker per piazzare la routine cc_to_Obama() ovunque.

Occorre quindi essere chiari. Se pensate di essere al sicuro perche' usate OSS, significa che avete una certezza ASSOLUTA che "qualcun altro" si accorgerebbe del malippo se qualcuno si mettesse ad infilare backdoors in qualche pezzo del vosto OSS. Ma voi sapete di preciso chi sia questo "qualcun altro"?



Il primo punto e' che la possibilita' TEORICA di una review non implica assolutamente che la review sia fatta.



Potrei chiedervi di descrivermi quale sia il processo di Quality Assurance del Kernel di Linux, e potrei chiedervi se esista qualche auditing complessivo. La realta' e' che se inserissi mezza backdoor in un driver ethernet e la seconda nel driver dell'hard disk, con ogni probabilita' andrei a toccare due aree di testing che non si parlano neppure. Anche se chi si occupa di I/O sui dischi controllasse tutto facendo una quantita' enorme di test sul codice, non si accorgerebbe della meta' della backdoor installata, perche' senza l'altra meta', che si trova sul driver , che so io, della ethernet, non fa proprio niente.



Il meccanismo di peer review del codice e' legato a doppia mandata a Torvalds, il quale oggi si occupa piu' che altro di software per scuba diving e sverna in California. Direi che si trova troppo bene negli USA per rischiare di scontentarli.



La morale della storia e' che basta infiltrare volonterosi sviluppatori che si occupino del kernel di Linux  nel team, e paf: ogni macchina Linux contiene la backdoor.



Anche la storia che vi ricompilate il kernel vale sino ad un certo punto. Non lo ricompilate nei vari cloud pubblici, non ricompilate quello del vostro ISP, spesso quello del vostro cellulare, o quello del vostro router. 




Siete ancora li': la routine cc_to_Obama() puo' nascondersi ovunque.



Esiste un modo per verificare? Potreste piazzare una di queste macchine in una rete, fare tapping su voi stessi a livello hardware,  e con un analizzatore di protocollo professionale andare a vedere gli zeri e gli uni che passano per il cavo. E allora vedreste che no, effettivamente sinora Ubuntu se ne sta buono e non scrive porcherie sospette sul cavo ethernet.



O forse non lo fa in chiaro.



Qual'e' il punto definitivo?




Tempo fa i cinesi si fecero il loro "Sistema Operativo Nazionale", che era una versione modificata di NetBSD 




. Misero decine di migliaia di cinesi a controllare il codice riga per riga, sino a quando furono sicuri che non faceva nulla che non volessero. Ci misero anni per produrre la prima versione. Oggi, lo stato cinese DEVE usare quella roba e solo quella.



La domanda e': qualche stato europeo, o l' unione stessa, intendono produrre una versione di Linux/*BSD che sia capace di essere, almeno per i dispositivi di rete certificati , IL sistema operativo UE?




Non ci vorrebbe molto, in termini di investimenti, nel produrre un OSS che sia liberamente scaricabile E OBBLIGATORIO per ogni apparato di rete/computer governativo, e nel mantenere un repository che sia in grado di fornire aggiornamenti.




Questo pero' vi pone nella condizione per la quale, se non vi fidate dello sviluppatore perche' potrebbe essere inquinato dal governo straniero, dovrete comunque fidarvi del VOSTRO governo. Il punto pero' deve essere chiaro: come utenti finali, NON avete ALCUNA possibilita' di combattere un ente con i mezzi di un governo.



Quando faccio questa affermazione, mi vengono sempre date le due risposte piu' stupide dell'universo : TOR e  "encryption".



Per quanto riguarda TOR, quello che fate quando vi collegate alla rete TOR e' di confidare nelle regole usuali di trasporto TCP , ignorando tecnologie come MPLS, ATM switching ed altro tipo di switching, e pensate di collegarvi nella rete TOR "pirata" solo perche' chiamate una rete TOR. In realta' quasi tutte le polizie del mondo hanno la LORO rete TOR, fanno deep packet inspection , vi girano sulla rete TOR della polizia usando MPLS (1) o altro, poi vi sniffano all'uscita della LORO rete tor (ottenendo sia la vostra identita' che il contenuto) , e vi infilano nuovamente nella rete TOR pubblica. Non potendo VOI risalire alla rotta dentro una rete TOR, non avete idea del percorso dei vostri pacchetti.



Non credo, onestamente, che TOR dia qualsiasi tipo di anonimato: qualsiasi corpo di polizia puo' costruirsi un sistema con un packet inspector, un peer MPLS, e una rete TOR. Costa poche centinaia di migliaia di euro. Credete di essere sicuri perche' VOI non sapreste come risalire al client, ma chi controlla il cavo puo'. 
 Se poi si comincia ad usare qualcosa di piu' flessibile di MPLS, tipo OpenFlow, lo switching di utenti TOR diventa banale, anche senza aggiungere label ai pacchetti.



Ancora una volta, contro chi possiede il trasporto avete poco da fare.



Andiamo alla cosiddetta encryption. Se parliamo di SSL su connessioni, tutto si basa sul fatto che voi crediate alla certification autority. In un mondo perfetto, dovreste fidarvi solo di quelle che conoscete. Nella realta', il vostro browser/client arriva con un insieme di certificati che vi vengono "suggeriti" da chi produce il browser/client.



Se chiedessi di alzare la mano a coloro che hanno svuotato la lista di CA e poi l'hanno riempita daccapo mano a mano che incontravano i warning del browser, (2) oppure soltanto chi ha passato in rassegna l'elenco delle certification authority, rimarreste con le mani in mano. IN realta' quindi il vostro browser si fida di un insieme di certificati (=di aziende certificatrici) che altri hanno scelto. Di conseguenza, se credete di essere sicuri perche' vi compare il lucchettino, sarete delusi: il fatto che vi compaia un lucchettino su Firefox significa che la Mozilla Foundation si ritiene soddisfatta della vostra sicurezza, ma se non avete installato VOI il certificato, potrebbe essere il certificato dell' FBI, e ancora il vostro browser non se ne accorgerebbe.



Anche con gli algoritmi di crittazione ho brutte notizie. Quasi tutti gli algoritmi che considerate sicuri , piu' o meno, da RSA, DSA, AES, sono industry standard non perche'"DEVS LO VULT", ma perche' una apposita commissione li ha voluti come tali, oppure perche' il governo USA non e' intervenuto per proibirne la diffusione, come fu fatto inizialmente per PGP, che ci e' arrivato solo grazie ad alcune rocambolesche vicende: esportare tecnologie di criptazione con chiavi piu' forti di 40 bit era reato sino a un decennio e rotti fa, in USA.



Sapete chi ha scelto AES come standard di crittazione? http://it.wikipedia.org/wiki/Advanced_Encryption_Standard . Lo ha scelto... NSA. State crittando con un codice scelto da chi vi spia. Si, certo, matematica e complessita' e blablabla, ma non cambia nulla: state crittando con un algoritmo scelto da chi vi spia.



RSA e DSA sono basati sulla "complessita' nel risolvere un problema". Ci siamo, sembra. No?



Anche senza andare sulla differenza tra aspettative e realta', alzino la mano quelli che sono capaci di aprire il codice di openSSL e giudicare la robustezza dell'implementazione. Oh, certo: se ci fossero flaws, "qualcuno se ne sarebbe accorto".



Non trovate abbastanza ingenua la vostra fiducia in "qualcuno"? Chi, di preciso? Mio cugino? Vostro cugino?



E siamo al punto: l'unico modo che avete per garantirvi la Privacy e' che il VOSTRO governo decida di implementare una VERA politica per la privacy informatica. Ovvero, di rilasciare su propria responsabilita' un INTERO stack di sistemi operativi + software + sistemi operativi di rete, ed imporli come standard sul territorio nazionale, ALMENO per le infrastrutture pubbliche e wholesale.




E dico "imporre" per una ragione: nel mondo OSS c'e' anche il problema delle distribuzioni. Se anche il kernel fosse sicuro e verificato, e tutto il codice fosse "pulito", voi non comprate il codice dallo sviluppatore: di mezzo c'e' la "distro". Cosi' magari il kernel si Linux e' sicuro in partenza, ma poi vi nasce un'azienda che lavora in perdita per i primi 5 anni - coi soldi di chissachi - e vi fa la distribuzione fichissima dalla grafica meravigliosa che spazza via i concottenti. Tah-dah: i binari vi arrivano gia' compilati, e si aggiornano cosi' spesso che un vero controllo della qualita' del software e' impensabile.



Cosi', ancora, siete ancora al punto di prima: dovete controllare "end to end" tutto il processo: il coding, la compilazione, la distribuzione.



E l'unico che puo' farlo e' un governo.



Cosi', non esiste un modello di sviluppo del software che vi metta al sicuro contro violazioni della legge e dei diritti. Tutto quello che esiste contro le violazioni dei diritti e' avere buone leggi, una polizia all'altezza e carceri molto dolorose.



Ovvero, se non vi fidate di un governo straniero, l'unico ente cui potete chiedere aiuto e' il VOSTRO governo.




Uriel



(1) In estrema sintesi, piazzano una label sui vostri pacchetti, come header opzionale, e poi switchano il pacchetto. "Switchano" significa che NON implica un hop, e quindi con i vostri traceroute&co non potete accorgervene, visto che il TTL non viene coinvolto.



(2) Non e' doloroso quanto sembra. IN realta' svuotando la lista si tratta solo di autorizzare manualmente OGNI certificato come eccezione.

Viewing all articles
Browse latest Browse all 561

Trending Articles