Come verificare se un codice sorgente è sicuro prima di compilarlo?

Mancanza di lettura e comprensione di ogni riga di codice e di come tutto ciò si combina perfettamente non è possibile. Il meglio che puoi fare per scaricarlo come pacchetto da una fonte attendibile che controlla i pacchetti in anticipo, per minimizzare il rischio per l'utente.

Tuttavia ci sono volte in cui vengono violati anche i sistemi operativi completi (come Mint Linux all'inizio di quest'anno ) quindi non puoi essere sicuro che quello che stai ricevendo è sicuro.

Come molte delle cose che ho trovato quando ho pensato alla sicurezza, molte di esse si riducono al bilanciamento di fiducia e buon senso.

No. Non è possibile verificare il codice.

L'analogo matematico a questa domanda è chiamato il problema "Verifica del programma". La verifica del programma è nota per essere impossibile da decidere. Ciò significa che non esiste alcun algoritmo in grado di verificare la correttezza del codice del tuo computer. Strettamente correlato, il problema di interruzione non è decidibile, ovvero non esiste alcun algoritmo in grado di dirti se il tuo codice smetterà mai di funzionare . Tutto ciò è stato dimostrato negli anni 1950-1960 e chiunque abbia conseguito una laurea in informatica dovrebbe essere istruito su questi risultati. È matematicamente impossibile verificare il codice.

Anche leggendo il codice, non è possibile verificarlo. In alcuni casi, codici molto brevi o algoritmi possono essere testati corretti utilizzando la logica matematica. Le prove funzionano solo per gli algoritmi core, come gli algoritmi di ordinamento e gli algoritmi di attraversamento grafico. Per qualsiasi code-base di grandi dimensioni, come un sistema operativo, non c'è modo di dimostrare la correttezza.

Alcune analisi statica e alcuni metodi formali esistono strumenti e tutti questi strumenti tentano di eseguire alcune forme limitate di verifica. Questi strumenti cercano di dimostrare ciò che può essere facilmente dimostrato sul codice. L'analisi statica cerca di definire le proprietà dimostrabili del comportamento dinamico del codice quando viene eseguito. Alcuni sistemi usano asserzioni mentre altri usano invarianti di loop. Tuttavia, in tutti i casi, l'analisi statica non può eseguire la verifica completa del programma.

Se decidi di eseguire un codice ti stai fidando implicitamente degli autori del codice. Ti stai fidando del loro intento di scrivere codice che funzioni e rispetti le politiche di sicurezza tipiche, come l'autorizzazione all'accesso, le autorizzazioni, ecc. Strumenti come mdsum possono aiutarti a decidere se hai scaricato la versione del codice che gli autori hanno reso disponibili, ma non può aiutarti a verificare il design del codice.

Sì, se uno scarica ciecamente e compila il codice sorgente, quel codice potrebbe contenere un exploit che, se eseguito, potrebbe danneggiare il proprio sistema. Inoltre, potrebbe non essere necessario eseguire esplicitamente il binario risultante. Nel suo classico del 1984 Riflessioni sulla fiducia fidata , Ken Thompson ha dimostrato come si potrebbe procedere alla creazione del codice C che, una volta compilato, ha sfruttato il compilatore e ha fatto il backdoor del sistema su cui risiede il compilatore.

Ci sono alcuni modi per difenderci da questo. Nel 2006, Bruce Schneier ha scritto una ripartizione piuttosto buona di un articolo di David A. Wheeler sulla difesa contro l'esempio specifico di Thompson. La carta stessa è ancora saldata al momento, per quanto ne so.

La carta Wheeler è molto interessante, ma è focalizzata sulle viscere del design del compilatore, e questa domanda sembra più focalizzata sulle precauzioni per l'utente finale rispetto alla progettazione del compilatore o persino alla programmazione dei sistemi. Ci sono generalmente due modi in cui comprendiamo il rischio legato alla compilazione di una specifica porzione di codice:

1. Autenticare il codice come un vero codice di codice non programmato, scritto da qualcuno di cui abbiamo scelto di fidarci.
2. Esame approfondito del contenuto del codice stesso e comprensione completa di ciò che fa.

Il secondo caso - una verifica approfondita del codice - è un compito enorme, lungo e che richiede molte risorse. Non succede quasi mai per basi di codice di dimensioni non banali, perché è semplicemente troppo costoso. Molto più spesso, stiamo osservando il primo caso: fidarsi del programmatore e convalidare che il codice non è stato manomesso tra il codificatore e il consumatore.

Nel 2015, ho fatto un articolo per LinuxJournal su come il codice normalmente arriva dallo sviluppatore all'utente Linux. Chain of Custody è stato ripubblicato dal mio datore di lavoro al di fuori del paywall di LinuxJournal. È strongmente focalizzato sul percorso che passa attraverso la gestione dei pacchetti, ma se leggi attentamente, ti renderai conto che le parti applicabili a un codice di compilazione del manutentore del pacchetto ottenuto da qualche parte su Internet sono applicabili anche a un utente finale.

Naturalmente, alla fine, come altri hanno sottolineato, questi controlli di integrità ne fanno uno solo se l'infrastruttura degli sviluppatori non è stata compromessa, se lo sviluppatore stava codificando bene e così via.

Penso che quello che stai chiedendo sia "analisi statica" (al contrario di "analisi dinamica" che analizza il codice in esecuzione).

Il gruppo di sicurezza Web OWASP ha una pagina che parla di analisi di sicurezza del codice sorgente statico in termini generali. Se cerchi semplicemente google per "analisi di sicurezza del codice sorgente statico", troverai molti prodotti disponibili (alcuni payware, alcuni gratuiti).

La parte della risposta che non ti piacerà è: tipicamente questi analizzatori cercano vulnerabilità sotto forma di buffer overflow, use-after-free e cose del genere. È quasi impossibile per un programma decidere cosa si intende per "comportamento malevolo", ad esempio il programma può leggere tutti i file e caricarli su un server. Questo è perfetto se il programma è uno strumento di sincronizzazione cloud come Dropbox, ma meno bene se si tratta di un solitario. In conclusione: non c'è alcun sostituto per la lettura del codice sorgente da soli.

Personalmente, guardo alla reputazione del sito da cui ho preso il codice sorgente. Se è su github o simili, chi sono i principali contributori? Se li google, sembrano legittimi? Il codice stesso è stato scaricato da HTTPS o SSH, giusto? Potrei cercare alcune recensioni di questo software per assicurarmi che nessun blogger abbia sollevato bandiere rosse su di esso, ecc. (Nota finale: i rischi di cose come questa sono molto più bassi se si installa il software come pacchetto attraverso il pacchetto della distro manager, quindi preferisci sempre questo se possibile.)

Come altri hanno già detto, la verifica effettiva del fatto che il codice non ha comportamenti malevoli è quasi impossibile. Ci sono manciati di casi speciali, in cui il codice è stato scritto per essere verificabile, come il kernel di SeL4 , ma il il caso generale è facilmente dimostrato irrisolvibile.

In situazioni pratiche ci sono dei passi da fare per ridurre la probabilità di un problema:

• Scarica da una fonte attendibile. Se è possibile, attenersi ai prodotti che forniscono una firma è possibile controllare (e, naturalmente, ottenere quella firma da una fonte attendibile). Ciò non verifica che il codice sia sicuro, ma verifica che quando pensi di avere "gcc 4.4.2", che hai effettivamente ricevuto il codice che tutti chiamano "gcc 4.4.2" Questo è utile per il prossimo passo.
• Controlla alcuni dei principali siti di sicurezza per vedere se ci sono problemi noti con il prodotto indicato. Ad esempio, puoi cercare nel database nazionale sulle vulnerabilità del governo degli Stati Uniti per vedere se ci sono problemi noti con quel particolare prodotto con nome. Sentiti libero di usare anche altri database se non ti fidi del governo USA con la tua sicurezza.
• Scarica il meno possibile. Questo può essere ovvio, ma vale la pena menzionare
• Non essere dipendenti per avere il codice sorgente affidabile. Qualsiasi buona sicurezza dovrebbe essere la sicurezza in profondità. Ovvio, dovresti assicurarti che il tuo codice sorgente sia affidabile come puoi, ma non dimenticare di avere strumenti di rete che monitorano comportamenti dannosi che potrebbero essere sfuggiti alla prima schermata.