È più sicuro compilare codice open source vs semplicemente eseguire il binario?

Il più delle volte, è solo appena più sicuro, ea volte è meno sicuro.

Under what conditions can I simply download the exe(cutable?)

I pacchetti firmati dalle principali distribuzioni sono costruiti sui server di generazione della distribuzione. A tale riguardo, è quasi certamente meglio usare il sistema di packaging.

Are there times when I should I compile the binary from source?

Generalmente, un repository di controllo di origine come git crea una cronologia non affidabile che può essere osservata al contrario dell'output binario che potrebbe essere modificato separatamente. A tale riguardo, il codice sorgente è più sicuro, ma solo se lo stai effettivamente rivedendo. È possibile che i binari dannosi vengano messi in atto o che il sistema dello sviluppatore di pacchetti sia compromesso con un compilatore malevolo, ma le istanze registrate del primo sono rari e il secondo quasi del tutto sconosciuto.

La compilazione può esporre anche a bug sconosciuti. Se si usano diverse opzioni del compilatore, si potrebbe introdurre un bug che non è visto nel file binario regolarmente distribuito. Ci sono un sacco di casi di difetti dipendenti dalla macchina o cambiamenti nel comportamento a causa di diversi flag del compilatore. A tale riguardo, la compilazione dalla fonte potrebbe essere meno sicura.

La risposta definitiva qui si riduce a quanto ritieni valga la pena in termini di tempo che sei disposto a spendere per verificare la fonte del codice binario o del codice sorgente.

Permettetemi innanzitutto di affermare che non conosco alcun caso in cui solo il file eseguibile precompilato di un progetto FOSS contiene codice dannoso. Quindi se stai cercando esempi concreti, questa risposta probabilmente non fa per te.

Il più grande vantaggio della compilazione del codice è la capacità di leggere il codice e determinare cosa fa effettivamente il codice. Questo è spesso considerato il principale vantaggio del codice FOSS. Vedi la legge di Linus.

Given enough eyeballs, all bugs are shallow

Realisticamente, però, un singolo sviluppatore o anche un piccolo team di sviluppatori non avrà il tempo e l'inclinazione per passare attraverso il codice sorgente per ogni singolo codice FOSS utilizzato in un progetto. Senza contare che per individuare effettivamente il codice dannoso, gli sviluppatori devono avere un background in sicurezza. Immagina di passare attraverso l'intera base di codice del kernel Linux prima di compilarlo ... Avrai bisogno di avere una certa fiducia negli sviluppatori FOSS e nel sito di hosting del progetto.

Personalmente, l'approccio che prenderò dipenderà dalla reputazione del progetto FOSS in questione. Se è qualcosa di enorme e affidabile come il kernel di Linux, userò solo i binari che forniscono e confido nei molti sviluppatori di individuare tempestivamente il codice dannoso e risolvere i problemi. Se il progetto non è molto affidabile, farei un tentativo di leggere il codice sorgente per vedere se ci sono suggerimenti di codice malevolo presenti prima di compilarlo da solo. Se ciò non è possibile, metterei in discussione l'uso di detto progetto FOSS e preferirei uno più affidabile o addirittura scrivere la funzionalità da solo.

Il codice sorgente è "più sicuro" nei seguenti modi:

• Piantare una backdoor discreta nel codice sorgente (al contrario del codice binario) è difficile, in proporzione al numero di persone che riesaminano il codice sorgente.
• Molto pochi virus infettano automaticamente il codice sorgente.

Il primo modo non è una garanzia strong. In primo luogo, dal momento che stai immaginando un autore ostile, allora devi considerare in che modo quell'autore potrebbe dare a te un codice sorgente specifico con una backdoor, distinta dal codice sorgente visto da tutti gli altri. Pertanto, l'insieme di persone che sono in grado di esaminare la fonte che stai per compilare può essere ridotto a una singola persona, cioè tu. In tal caso, se tu , personalmente, non sei disposto a eseguire una revisione completa del codice sorgente, compilare il codice sorgente non ti renderà più sicuro dell'uso di un binario, almeno contro un autore ostile che vuole piantare una backdoor.

In secondo luogo, backdoor e altre vulnerabilità sono bug. È stato ampiamente dimostrato che nessuna quantità di revisione del codice può rilevare tutti i bug, anche quelli molto gravi, anche per bug che sono errori onesti. Se non riusciamo a scoprire in modo affidabile i bug che sono il risultato di mera sfortuna e disattenzione, come possiamo sperare di riconoscere bug creati intenzionalmente da un attaccante apparentemente intelligente che è intento a eludere il rilevamento?

Un riferimento classico da leggere è la conferenza del premio Turing di Ken Thompson . Per una storia più recente, guarda tutto il dramma sulla presunta backdoor nell'implementazione di OpenBSD IPSec , che si è rivelato (ufficialmente) un vero disastro. Mentre in quest'ultimo caso sembra che non ci sono backdoor reali (non ho verificato me stesso), evidenzia il fatto che piantare backdoor in un PRNG sottilmente viziato sembra altamente possibile, anche come codice sorgente che è in bella vista di molte persone.

Alla fine, è una questione di rischio . Dal punto di vista dell'attaccante, mettere la backdoor nel codice sorgente è rischioso: se il suddetto codice sorgente è ampiamente disponibile, il rischio di essere scoperti è più alto; mentre una backdoor nel codice binario è per lo più sicura - di nuovo, per l'attaccante. Affidarsi che il codice sorgente sia più sicuro per te significa fare affidamento sulla razionalità dell'hacker , cioè usare il codice sorgente perché ritieni che l'attaccante non sia abbastanza pazzo da correre il rischio di mettere la backdoor nel codice sorgente visibile.

La protezione contro i virus probabilmente ha un valore pratico più alto, nel caso dei binari almeno per Windows. Usando il codice sorgente, sei immune dalla maggior parte dei virus che potrebbero essere eseguiti sulla macchina dell'autore del software (ma, ovviamente, non contro il virus sulla tua macchina), ma questi sono già presenti.

In primo luogo, come altri hanno affermato, l'open source non significa che coloro che guardano il codice sono abbastanza abili da rilevare i problemi che menzioni. Inoltre, il codice può essere fatto per apparire benigno quando in realtà fa qualcosa dietro le quinte: vedi il Concorso di codice C subdolo per un esempio:

a competition that challenges coders to solve a simple data processing problem by writing innocent-looking C code that is as readable, clear, and seemingly trustworthy as possible, yet covertly implements a malicious function.

In secondo luogo, anche se il codice non ha necessariamente bit maliziosi espliciti, potrebbe essere vulnerabile agli attacchi che possono compromettere il sistema. Heartbleed potrebbe essere l'esempio più ovvio qui.

Quindi, supponendo che tu abbia fiducia negli autori e nella comunità, e che non ci siano problemi sottili come le vulnerabilità nel genreration di numeri casuali , il problema ora è: quando posso fidarmi del binario e quando è più consigliabile compilare dal sorgente?

Per rispondere a questa domanda ti suggerisco di consultare build riproducibili . Sono implementati in debian e altri compreso per . Se il programma FOSS che ti interessa fornisce build riproducibili e un sistema automatizzato per distribuire i checksum, le probabilità che un binario venga compromesso sono scarse. In particolare, guarda come Il progetto Qubes lo fa quando si tratta di firmare.

Infine, non dimenticare che il problema potrebbe non essere nel codice sorgente dell'applicazione in uno scenario in cui il tuo compilatore è compromesso . In questo caso stai meglio con i binari (fidati).

Sei più sicuro con la soluzione più utilizzata. Se non ci sono checksum, non viene pesato in alcun modo. Anche questo dipende dal tempo e dalla cultura.