Problemi di fiducia relativi all'open source

Se è possibile ricompilare il codice sorgente e avere il proprio binario, allora forse non sarà possibile ottenere lo stesso binario identico a quello distribuito; ma perché dovrebbe importare? A quel punto, hai il tuo binario, che corrisponde necessariamente al codice sorgente (supponendo che il tuo compilatore non sia malevolo): puoi semplicemente abbandonare il pacchetto binario e usare il tuo binario.

In altre parole, le situazioni in cui è possibile verificare l'output della compilation sono situazioni in cui è possibile compilare te stesso, rendendo la verifica un punto controverso.

Ci sono framework di distribuzione dei pacchetti là fuori, che si basano sulla distribuzione del codice sorgente e sulla compilazione locale invece dei pacchetti binari; per esempio. pkgsrc (il sistema nativo per NetBSD) o MacPorts (per macchine MacOS X). Tuttavia, non lo fanno per fiducia o sicurezza, ma perché la distribuzione di pacchetti binari coinvolge sistemi di compilazione da qualche parte, e questi non sono gratuiti; inoltre, un punto di pkgsrc è quello di fornire una facile gestione delle opzioni di compilazione locali.

Il famoso saggio Thompson mette in evidenza l'idea che persino creare la tua compilation non è abbastanza. Portato all'estremo, dovresti scrivere il tuo codice personale, ma anche il tuo compilatore, ed eseguirlo sull'hardware che hai progettato e inciso tu stesso: non ti puoi fidare della macchina se non hai iniziato con un secchio di sabbia (per silicon , il componente principale dei semiconduttori). Ovviamente, questo è non pratico . Pertanto, abbiamo bisogno della seconda cosa migliore, e quella seconda migliore è un cambio di paradigma : sostituire la fiducia con la violenza .

Quello che facciamo è che i pacchetti binari sono firmati . Il programma di installazione del pacchetto verifica la firma prima di installarla e rifiuta i pacchetti che non provengono da "fonti attendibili". Lo stesso concetto si applica alle applet Java , a cui possono essere concesse autorizzazioni aggiuntive (e, in effetti, il permesso di fare qualunque cosa vuoi con il tuo computer) a condizione che siano firmati. Si noti che questa è davvero una firma, non solo un'autenticazione; non è sufficiente (né effettivamente necessario) che il pacchetto sia stato scaricato da un "repository attendibile" tramite HTTPS. Tale download ti darebbe una certa garanzia che il pacchetto proviene da chi credi e non è stato modificato durante il trasporto. Ma tu vuoi di più: vuoi una prova . Si desidera una firma perché SE il pacchetto risulta essere pieno di malware, POI è possibile utilizzare la firma per dimostrare che il fornitore del pacchetto era complice, almeno "per negligenza". Dalle firme arriva responsabilità e la responsabilità funziona su fear . Paura del contenzioso da parte dei clienti abusati. Paura di ritorsioni da parte delle forze dell'ordine. In definitiva, paura della violenza.

Non è così semplice.

Con l'enorme numero di piattaforme su cui il programma potrebbe essere stato costruito, può essere estremamente difficile replicare l'ambiente di generazione originale. Per questo motivo, potresti utilizzare un compilatore diverso, con impostazioni diverse, utilizzando diverse versioni di librerie. Queste lievi variazioni nell'ambiente possono sicuramente influenzare il file binario compilato. Naturalmente, se l'autore è disposto a specificare con precisione il proprio ambiente di costruzione, o se si è fortunati (le lingue diverse possono influenzare questo), potrebbe essere possibile ricostruire lo stesso binario.

Per una situazione recente in cui questo era un problema, vedere TrueCrypt, un programma di crittografia a disco intero open-source-ish ⁰ . Quando il sito TrueCrypt è stato bruscamente sostituito con un annuncio che dichiarava la fine inaspettata del progetto TrueCrypt, le persone erano ovviamente interessate a controllare il codice. Tuttavia, diverse persone che costruivano TrueCrypt avevano spesso binari che differivano in modo selvaggio dalla build ufficiale, a causa delle variazioni nell'ambiente di costruzione. Una persona apparentemente gestita (dopo un duro lavoro nel ricreare qualcosa di molto vicino all'ambiente originale ) per replicare la build TrueCrypt da zero con solo piccole variazioni nell'output compilato. ¹ Naturalmente, non è possibile verificarlo da soli, a meno che tu non voglia provare la stessa cosa.

Di interesse su quella pagina è il fatto che il binario contiene un timestamp del tempo di compilazione. Questo da solo significa che compilare e confrontare gli hash non funzionerebbe mai.

^{0: TrueCrypt ha una strana licenza con alcuni problemi; non è sicuro se sarebbe davvero sicuro lanciare il progetto.}

^{1: In realtà, sembra che l'abbiano fatto prima della stranezza del sito TrueCrypt, ma da allora sono riusciti a replicare anche la versione 7.2.}

Se compilate il codice da soli, allora potrebbe ottenere lo stesso binario. O no. Fondamentalmente, le tue possibilità sono buone se il compilatore utilizza algoritmi di ottimizzazione deterministica (è il solito caso) e tu usi la stessa esatta versione del compilatore con le stesse opzioni della riga di comando (che di solito è molto più difficile da garantire).

La ri-compilazione deterministica è più semplice con il framework di programmazione in cui il formato "compilato" viene formalmente specificato e non ottimizzato. Sto parlando qui di bytecode Java o di assembly .NET. Quando si usano tali strumenti, essere in grado di ricompilare il codice sorgente e ottenere lo stesso binario è possibile , anche se difficile. Con C o C ++, dimenticalo.

I soliti metodi sono:

• Compilati.
• avere alcuni di terze parti attendibili fare la compilation. Quella terza parte otterrà una copia della fonte, eseguirà la compilazione dalle loro macchine e firmi (con crittografia o con carta) sia l'archivio sorgente che il file binario prodotto.
• Chiedere al provider del binario di firmare il file binario e fidarsi del fatto che il reverse engineering sarà abbastanza fattibile per dimostrare il gioco scorretto, se necessario (anche in questo caso, è molto meno plausibile quando si parla di codice bytecode Java rispetto al codice C compilato). / li>
• Non utilizzare software esterno; reimplementare tutto internamente (e sì, questo è un metodo solito , che non è lo stesso di raccomandato ).
• Vai avanti e affidati alla tua buona sorte (non certo un metodo consigliato, ma sicuramente il più economico a breve termine).

Si noti che la (ri) compilazione del codice richiede anche che la macchina su cui avviene la compilazione non sia sotto controllo ostile. Questo saggio molto classico è una lettura obbligata sull'argomento. L'idea alla base è che la tua fiducia deve ancora iniziare da qualche parte (solo nell'hardware stesso, il cui firmware è considerato privo di malware) quindi il meglio che puoi fare è mantenere una chiara pista di controllo . Questa traccia non garantisce l'inserimento in backdoor, ma può aiutare molto nell'assegnare la colpa e la responsabilità in caso di problemi.

Sì è possibile. Ma è molto difficile, poiché l'intero processo di compilazione non è stato progettato per questo obiettivo. È spesso chiamato "build deterministici", "build riproducibili", "build idempotent" ed è una sfida.

Bitcoin, Tor e Debian , stanno tentando di utilizzare build deterministiche e il processo tecnico è descritto qui .

Certo, il processo è imperfetto, fragile e molto difficile da correggere. Quando si considerano le build multipiattaforma, il problema è ancora più complesso.

Mi piace il determinismo.

Un compilatore o qualsiasi strumento software è davvero una subdola trasformazione matematica. Prende s (codice sorgente) lo inserisce in una funzione C () e produce un output binario.

b = C (s) ogni volta! altrimenti il determinismo fallisce e noi tutti impazziamo.

Quindi la teoria va, finché iniziamo con la stessa s, e la stessa C (), produrremo sempre la stessa b.

E questo è positivo perché possiamo eseguire un hash di b o H (b) e ottenere un valore relativamente breve che possiamo confrontare con H (b) di qualcun altro per assicurarci che sia binario quello che ci aspettiamo.

E poi cambia la situazione: s cambia in s ', C () cambia in C' (). Oh no!

Perché C (s) = b1 e C '(s) = b2 e C (s') = b3 e C '(s') = b4

e ovviamente non ci sono due di H (b1), H (b2), H (b3) o H (b4) con mai una corrispondenza.

E il problema è che mentre i componenti (catena di strumenti, ambiente, configurazione, sistema operativo, ecc.) necessari per produrre b binari diventano più numerosi e interdipendenti diventa sempre più difficile riprodurre lo stesso b.

Aspetta, e se non avessimo bisogno della stessa identica b?

Abbiamo quindi a che fare con b e b 'e la differenza tra loro.

Tutto ciò che serve per trovare la differenza tra un binario di riferimento b e il binario generato b 'e guardare a cosa significa la differenza. Se la fonte per b e b 'è s, significa che stiamo trattando con C () e C'. E quindi possiamo correlare la differenza tra C () e C '() alla differenza tra b e b'. Quindi, anche se non riusciamo a riprodurre esattamente b, possiamo ottenere una certa confidenza con b 'inclinando la differenza che deriva dall'uso di C' () invece di C ().

Anche con le stesse sorgenti, lo stesso sistema operativo, le stesse librerie, lo stesso compilatore e lo stesso caricatore, due file binari non corrispondono poiché includono informazioni sulla data di compilazione e operazione di caricamento.

Sullo stesso identico sistema e ambiente di sviluppo, se si crea il doppio dello stesso binario sarà diverso e quindi qualsiasi hash sarà diverso:

$ md5 nmap
MD5 (nmap) = 8ef4b7c1cb2c96ce68d9e08224419b4f
$ # make clean, make install
$ md5 nmap
MD5 (nmap) = 94467bc53973550f919293f891f245f9

D'altra parte, se le tabelle dei simboli non sono state rimosse, allora queste tabelle dei simboli corrisponderanno e sarà una buona approssimazione per diagnosticare che un binario è realmente costruito da una determinata fonte:

$ nm -a nmap >/tmp/nmap.nm.1
$ # make clean, make install
$ nm -a nmap >/tmp/nmap.nm.2
$ diff /tmp/nmap.nm.[12]
$

Questo è valido solo per me per verificare che un binario provenga realmente da una determinata versione della mia struttura ad albero. Se sospetto una fonte esterna di tempra con tutto, anche queste tabelle di simboli potrebbero essere "organizzate".

Generalmente, se non sei sicuro di fidarti della compilation di qualcun altro, faresti lo sforzo di crearne una tua, o trovare qualcuno che la ottenga da chi ti fidi.

Ma sei sicuro di poter credere che il tuo compilatore non sia stato infettato?

Sono le tartarughe fino in fondo. Ad un certo punto finirai sempre per dover effettuare una chiamata di giudizio e / o fare affidamento su antivirus, firewall e altri sistemi di sicurezza.

AFTERTHOUGHT - Questo è uno dei motivi per cui esistono società che distribuiscono versioni prodotte di codice open-source. Controllano il loro codice base, promettono che le loro build sono pulite e (se lo acquisti) forniscono un supporto continuo. Ricorda, anche il manfresto GNU di Stallman ha detto che "il software dovrebbe essere gratuito, il supporto dovrebbe costare".

Mantenere affidabili i download è una forma di supporto. potresti ottenere un buon supporto da una comunità libera ... ma potresti ottenere un supporto migliore se ti butti un po 'di dollari. Scegli il tuo punto di scambio preferito.

Sono disposto a utilizzare alcune build Linux casuali per hackerare su una macchina secondaria. Preferirei qualcosa come Fedora per la macchina personale su cui effettivamente mi baso. E se scommettevo su un'azienda, andrei con la versione completa del prodotto acquistato, Red Hat Enterprise o simile. (Approvazione non implicita, Fedora e RHEL sono solo buone illustrazioni di come un'azienda si rivolge a due punti diversi su quello spettro.)

Una delle cose fondamentali di cui ti fidi in un binario è il luogo da cui l'hai ottenuta. Se sourceforge o download.com o chi dice che è privo di virus e questo è abbastanza buono per te, prova. Ci stai prendendo in parola.

Se non vuoi fidarti di un binario, l'unica altra vera risposta è compilare dal codice sorgente. O per qualcosa come il bytecode java che puoi eseguire, o un jar, o fino a un binario.

Se si compila il proprio binario, sì si potrebbe finire con qualcosa che è lo stesso del binario standard (nel senso che TUTTO è lo STESSO, un po 'per corrispondenza) Grande! ti è capitato di eseguire lo stesso hardware, compilare per gli stessi processori, nessuno aveva accidentalmente lasciato un'interruzione di riga in più nella tua copia del codice .... sia che corrisponda o meno, a quel punto ti stai fidando del codice che appena avuto (l'abilità almeno) da leggere. Se non conosci il C ++ e non ti fidi delle altre persone che hanno esaminato il codice, allora è difficile. Impara C ++ e controlla te stesso.

Tutto questo si riduce a voi non è possibile verificare un file binario a meno che tutto corrisponda ESATTAMENTE. Puoi comunque verificare il codice open source per qualcosa. Sia che tu prenda il tempo o se ti fidi delle analisi che presumibilmente una persona là fuori ha presumibilmente fatto è una tua scelta.