Ken Thompson Hack (1984)

Ken Thompson ha delineato un metodo per corrompere un binario del compilatore (e altri software compilati, come uno script di accesso su un sistema * nix) nel 1984. Ero curioso di sapere se la compilazione moderna ha risolto o meno questo difetto di sicurezza.

Breve descrizione:

Riscrivi il codice del compilatore per contenere 2 difetti:

• Quando si compila il proprio binario, il compilatore deve compilare questi difetti
• Durante la compilazione di un altro codice preselezionato (funzione di accesso) deve compilare una backdoor arbitraria

Pertanto, il compilatore funziona normalmente - quando compila uno script di accesso o simile, può creare una backdoor di sicurezza e quando compilerà versioni più recenti di se stesso in futuro, manterrà i difetti precedenti - e i difetti esisteranno solo nel compilatore binario quindi sono estremamente difficili da rilevare.

Domande:

Non sono riuscito a trovare risposte sul Web:

• In che modo ciò si collega alla compilazione just-in-time?
• Funzioni come il programma che gestiscono accessi su un sistema * nix vengono compilate quando vengono eseguite?
• È ancora una minaccia valida o ci sono stati sviluppi nella sicurezza della compilazione dal 1984 che impediscono che ciò costituisca un problema significativo?
• Questo riguarda tutte le lingue?

Perché voglio sapere?

Mi sono imbattuto in questo mentre facevo i compiti, e mi è sembrato interessante ma non ho le basi per capire in modo concreto se si tratta di un problema attuale o risolto.

Materiale di riferimento

• Panoramica
• Del codice

Questo hack deve essere compreso nel contesto. Fu pubblicato in un momento e in una cultura in cui Unix era in esecuzione su tutti i tipi di hardware diverso era il sistema dominante.

Ciò che rese l'attacco così spaventoso fu che il compilatore C era il software centrale per questi sistemi. Quasi tutto nel sistema è passato attraverso il compilatore quando è stato installato per la prima volta (le distribuzioni binarie erano rare a causa dell'hardware eterogeneo). Tutti hanno compilato roba per tutto il tempo. Le persone ispezionavano regolarmente il codice sorgente (spesso dovevano apportare modifiche per farlo compilare), quindi fare in modo che il compilatore iniettasse backdoor sembrava essere una specie di scenario di "crimine perfetto" in cui non si poteva essere scoperti.

Al giorno d'oggi, l'hardware è molto più compatibile e quindi i compilatori hanno un ruolo molto più piccolo nel funzionamento quotidiano di un sistema. Un compilatore compromesso non è più lo scenario più spaventoso: i rootkit e un BIOS compromesso sono ancora più difficili da rilevare e da eliminare.

Lo scopo di quel discorso non era quello di evidenziare una vulnerabilità che deve essere affrontata, o anche di proporre una vulnerabilità teorica di cui dobbiamo essere consapevoli.

Lo scopo era che, quando si parla di sicurezza, non vorremmo fidarci di nessuno, ma sfortunatamente è impossibile. Devi sempre fidarti di qualcuno (da qui il titolo: "Riflessioni sulla fiducia")

Anche se sei il tipo paranoico che crittografa il suo disco rigido desktop e rifiuta di eseguire qualsiasi software che non hai compilato tu stesso, devi comunque fidarti del tuo sistema operativo. E anche se compili tu stesso il sistema operativo, devi comunque fidarti del compilatore che hai usato. E anche se compili il tuo compilatore, devi comunque fidarti di quel compilatore! E questo non menziona nemmeno i produttori di hardware!

Semplicemente non puoi farcela con la fiducia di nessuno . Questo è il punto che stava cercando di superare.

No

L'attacco, come descritto in origine, non è mai stato una minaccia. Mentre un compilatore potrebbe teoricamente farlo, in realtà eseguire l'attacco richiederebbe di programmare il compilatore

• Riconosci quando il codice sorgente da compilare è di un compilatore e
• Scopri come modificare il codice sorgente arbitrario per inserire l'hack in esso.

Ciò implica capire come funziona il compilatore dal suo codice sorgente, in modo che possa modificarlo senza rotture.

Ad esempio, immagina che il formato di collegamento memorizzi le lunghezze dei dati o l'offset del codice macchina compilato da qualche parte nell'eseguibile. Il compilatore dovrebbe capire da sé quale di questi deve essere aggiornato e dove, quando si inserisce il payload dell'exploit. Le versioni successive del compilatore (versione innocua) possono modificare arbitrariamente questo formato, quindi il codice di exploit dovrebbe effettivamente comprendere questi concetti.

Questa è una programmazione auto-diretta di alto livello, un grave problema di intelligenza artificiale (ultimo controllo, lo stato dell'arte stava generando un codice che è praticamente determinato dai suoi tipi). Guarda: pochi umani possono persino farlo; dovresti imparare il linguaggio di programmazione e capire prima la base di codice.

Anche se il problema dell'IA è risolto, le persone noterebbero se la compilazione del loro piccolo compilatore si traduce in un binario con un'enorme libreria AI collegata.

Analogo attacco: bootstrap di fiducia

Tuttavia, una generalizzazione dell'attacco è rilevante. Il problema di base è che la tua catena di fiducia deve iniziare da qualche parte, e in molti settori la sua origine potrebbe sovvertire l'intera catena in un modo difficile da rilevare.

Un esempio che potrebbe essere facilmente realizzato nella vita reale

Il tuo sistema operativo, ad esempio Ubuntu Linux, garantisce la sicurezza (integrità) degli aggiornamenti controllando i pacchetti di aggiornamento scaricati rispetto alla chiave di firma del repository (utilizzando la crittografia a chiave pubblica). Ciò garantisce l' autenticità degli aggiornamenti solo se è possibile dimostrare che la chiave di firma è di proprietà di una fonte legittima.

Dove hai preso la chiave di firma? La prima volta che hai scaricato la distribuzione del sistema operativo.

Devi fidarti che la fonte della tua catena di fiducia, questa chiave di firma, non è il male.

Chiunque può MITM la connessione Internet tra te e il server di download di Ubuntu — questo potrebbe essere il tuo ISP, un governo che controlla l'accesso a Internet (ad esempio la Cina) o il provider di hosting di Ubuntu — avrebbe potuto dirottare questo processo:

• Rileva che stai scaricando l'immagine del CD di Ubuntu. Questo è semplice: vedi che la richiesta sta andando a uno qualsiasi dei mirror Ubuntu (elencati pubblicamente) e chiede il nome del file dell'immagine ISO.
• Servire la richiesta dal proprio server, dandoti un'immagine del CD contenente la chiave pubblica e la posizione del repository dell'aggressore invece di quella di Ubuntu.

Da quel momento in poi, riceverai gli aggiornamenti in modo sicuro dal server dell'attaccante. Gli aggiornamenti vengono eseguiti come root, quindi l'attaccante ha il pieno controllo.

Puoi prevenire l'attacco assicurandoti che l'originale sia autentico. Tuttavia, ciò richiede la convalida dell'immagine del CD scaricato utilizzando un hash ( poche persone lo fanno effettivamente ) e l'hash deve essere scaricato in modo sicuro, ad esempio tramite HTTPS. E se il tuo aggressore può aggiungere un certificato sul tuo computer (comune in un ambiente aziendale) o controlla un'autorità di certificazione (ad esempio la Cina), anche HTTPS non fornisce alcuna protezione.

Innanzitutto, il mio commento preferito di questo hack si chiama Strange Loops .

Questo particolare hack potrebbe certamente (*) essere fatto oggi in uno dei maggiori progetti di sistemi operativi open source, in particolare Linux, * BSD e simili. Mi aspetto che funzioni quasi in modo identico. Ad esempio, scarichi una copia di FreeBSD che ha un compilatore sfruttato per modificare openssh. Da quel momento in poi, ogni volta che aggiornerai openssh o il compilatore per sorgente, continuerai il problema. Supponendo che l'attaccante abbia sfruttato il sistema utilizzato per impacchettare FreeBSD in primo luogo (probabilmente, poiché l'immagine stessa è corrotta o l'attaccante è in realtà il pacchettizzatore), quindi ogni volta che il sistema ricostruisce i binari di FreeBSD, il problema verrà respinto. Ci sono molti modi per fallire questo attacco, ma non sono sostanzialmente diversi da come l'attacco di Ken avrebbe potuto fallire (**). Il mondo non è cambiato molto.

Naturalmente, attacchi simili potrebbero essere iniettati altrettanto facilmente (o più facilmente) dai loro proprietari in sistemi come Java, iOS SDK, Windows o qualsiasi altro sistema. Alcuni tipi di difetti di sicurezza possono persino essere ingegnerizzati nell'hardware (in particolare indebolendo la generazione di numeri casuali).

(*) Ma per "certamente" intendo "in principio". Dovresti aspettarti che questo tipo di buca esista in un particolare sistema? No. Lo considererei abbastanza improbabile per vari motivi pratici. Con il passare del tempo, quando il codice cambia e cambia, aumenta la probabilità che questo tipo di hack provochi strani bug. E ciò aumenta la probabilità che venga scoperto. Backdoor meno ingegnose richiederebbero cospirazioni da mantenere. Naturalmente sappiamo per certo che backdoor di "intercettazione legale" sono stati installati in vari sistemi di telecomunicazione e di rete, quindi in molti casi questo tipo di hack elaborato non è necessario. L'hacking è installato apertamente.

Quindi sempre, la difesa in profondità.

(**) Supponendo che l'attacco di Ken sia mai esistito. Ha appena discusso di come si potrebbe fare. Non ha detto di averlo effettivamente fatto per quanto ne so.

Questo riguarda tutte le lingue?

Questo attacco riguarda principalmente le lingue che sono self-hosting. Ecco le lingue in cui il compilatore è scritto nella lingua stessa. C, Squeak Smalltalk e l'interprete PyPy Python ne risentirebbero. Perl, JavaScript e l'interprete Python di CPython no.

In che modo ciò si collega alla compilazione just-in-time?

Non molto. È la natura self-hosting del compilatore che consente di nascondere l'hacking. Non conosco compilatori JIT self-hosting. (Forse LLVM?)

Funzioni come il programma che gestiscono accessi su un sistema * nix vengono compilate quando vengono eseguite?

Non solitamente. Ma la domanda non è quando viene compilata, ma da quale compilatore . Se il programma di accesso è compilato da un compilatore contaminato, verrà contaminato. Se è compilato da un compilatore pulito, sarà pulito.

È ancora una minaccia valida o ci sono stati sviluppi nella sicurezza della compilazione dal 1984 che impediscono che ciò costituisca un problema significativo?

Questa è ancora una minaccia teorica, ma non è molto probabile.

Una cosa che potresti fare per mitigarlo è usare più compilatori. Ad esempio, un compilatore LLVM che è, a sua volta, compilato da GCC non passerà attraverso una backdoor. Allo stesso modo, un GCC compilato da LLVM non passerà attraverso una porta sul retro. Quindi, se sei preoccupato per questo tipo di attacco, allora potresti compilare il tuo compilatore con un'altra razza di compilatore. Ciò significa che l'hacker malvagio (presso il tuo fornitore del sistema operativo?) Dovrà contaminare entrambi i compilatori per riconoscersi; Un problema molto più difficile.

C'è una possibilità teorica che ciò accada. Esiste, tuttavia, un modo per verificare se un compilatore specifico (con codice sorgente disponibile) è stato compromesso, attraverso la doppia compilazione di David A. Wheeler .

Fondamentalmente, utilizzare sia il compilatore sospetto sia un altro compilatore sviluppato in modo indipendente per compilare l'origine del compilatore sospetto. Questo vi dà SC _SC e SC _T . Ora compila l'origine sospetta usando entrambi questi binari. Se i binari risultanti sono identici (ad eccezione di una varietà di cose che possono variare in modo legittimo, come timestamp assortiti), il compilatore sospetto non stava effettivamente abusando della fiducia.

Come attacco specifico, è una minaccia tanto quanto lo è mai stata, il che non è affatto una minaccia.

In che modo ciò si collega alla compilazione just-in-time?

Non sono sicuro di cosa tu voglia dire. Un JITter è immune a questo? No. È più vulnerabile? Non proprio. Come sviluppatore, la TUA app è più vulnerabile semplicemente perché non è possibile confermare che non è stata eseguita. Nota che la tua app non ancora sviluppata è sostanzialmente immune da questa e da tutte le varianti pratiche, devi solo preoccuparti di un compilatore più recente del tuo codice.

Funzioni come il programma che gestiscono accessi su un sistema * nix vengono compilate quando vengono eseguite?

Questo non è molto rilevante.

È ancora una minaccia valida o ci sono stati sviluppi nella sicurezza della compilazione dal 1984 che impediscono che ciò costituisca un problema significativo?

Non esiste una vera sicurezza di compilazione e non può esserlo. Era proprio questo il punto del suo discorso, che ad un certo punto devi fidarti di qualcuno.

Questo riguarda tutte le lingue?

Sì. Fondamentalmente, in un momento o nell'altro, le tue istruzioni devono essere trasformate in qualcosa che il computer esige e che la traduzione può essere eseguita in modo errato.

David Wheeler ha un buon articolo: http://www.dwheeler.com/trusting-trust/

Io sono più preoccupato per gli attacchi hardware. Penso che abbiamo bisogno di una toolchain di progettazione totalmente VLSI con codice sorgente FLOSS, che possiamo modificare e compilare noi stessi, che ci consenta di costruire un microprocessore senza backdoor inserito dagli strumenti. Gli strumenti dovrebbero anche farci capire lo scopo di qualsiasi transistor sul chip. Quindi potremmo aprire un campione dei chip finiti e ispezionarli con un microscopio, assicurandoci che avessero gli stessi circuiti che gli strumenti dicevano che avrebbero dovuto.

I sistemi in cui gli utenti finali hanno accesso al codice sorgente sono quelli per cui dovresti nascondere questo tipo di attacco. Quelli sarebbero sistemi open source nel mondo di oggi. Il problema è che sebbene vi sia una dipendenza da un singolo compilatore per tutti i sistemi Linux, l'attacco dovrebbe arrivare sui server di build per tutte le principali distribuzioni Linux. Dato che quelli non scaricano direttamente i file binari del compilatore per ogni versione del compilatore, la fonte dell'attacco avrebbe dovuto trovarsi sui loro server di compilazione in almeno una versione precedente del compilatore. Quella o la prima versione del compilatore che avevano scaricato come binario avrebbe dovuto essere compromessa.

Se uno ha il codice sorgente per un compilatore / sistema di compilazione il cui output non dovrebbe dipendere da qualcosa di diverso dal contenuto dei file sorgente forniti, e se uno ha molti altri compilatori e sa che non contengono tutti lo stesso hack del compilatore, si può assicurarsi che si ottenga un eseguibile che non dipende da nient'altro che dal codice sorgente.

Supponiamo che uno abbia il codice sorgente per un pacchetto compilatore / linker (diciamo Groucho Suite) scritto in modo tale che il suo output non dipenderà da comportamenti non specificati, né da qualcosa di diverso dal contenuto dei file sorgente di input, e che uno compili / collega quel codice su una varietà di compilatori / pacchetti linker prodotti in modo indipendente (ad esempio Harpo Suite, Chico suite e Zeppo Suite), producendo un diverso set di exeuctables per ciascuno (chiamali G-Harpo, G-Chico e G-Zeppo). Non sarebbe inaspettato che questi file eseguibili contengano sequenze diverse di istruzioni, ma dovrebbero essere funzionalmente identici. Provare che sono funzionalmente identici in tutti i casi, tuttavia, sarebbe probabilmente un problema irrisolvibile.

Fortunatamente, tale prova non sarà necessaria se si utilizzano gli eseguibili risultanti per un solo scopo: compilare nuovamente la suite Groucho. Se si compila la suite Groucho usando G-Harpo (che produce GG-Harpo), G-Chico (GG-Chico) e G-Zeppo (GG-Zeppo), tutti e tre i file risultanti, GG-Harpo, GG-Chico e GG-Zeppo, dovrebbero essere identici byte per byte. Se i file corrispondono, ciò implicherebbe che qualsiasi "virus del compilatore" esistente in ognuno di essi deve esistere in modo identico in tutti loro (poiché tutti e tre i file sono identici byte per byte, non è possibile che i loro comportamenti possano differire in alcun modo modo).

A seconda dell'età e della discendenza degli altri compilatori, potrebbe essere possibile garantire che un tale virus non possa plausibilmente esistere in essi. Ad esempio, se si utilizza un Macintosh antico per alimentare un compilatore che è stato scritto da zero nel 2007 attraverso una versione di MPW scritta negli anni '80, i compilatori degli anni '80 non saprebbero dove inserire un virus nel compilatore del 2007. Oggi potrebbe essere possibile per un compilatore fare abbastanza elaborate analisi del codice per capirlo, ma il livello di calcolo richiesto per tale analisi supererebbe di gran lunga il livello di calcolo richiesto per compilare semplicemente il codice, e non sarebbe potuto passare inosservato. in un mercato in cui la velocità di compilazione era un importante punto di forza.

Suppongo che se si lavora con strumenti di compilazione in cui i byte in un file eseguibile da produrre non dovrebbero dipendere in alcun modo da qualcosa di diverso dal contenuto dei file di origine inviati, è possibile ottenere un'immunità ragionevolmente buona da un Thompson in stile virus. Sfortunatamente, per qualche ragione, il non determinismo nella compilazione sembra essere considerato normale in alcuni ambienti. Riconosco che su un sistema multi-CPU può essere possibile che un compilatore funzioni più velocemente se è permesso che alcuni aspetti della generazione del codice variano a seconda di quale dei due thread termina prima un lavoro.

D'altra parte, non sono sicuro di vedere alcun motivo per cui compilatori / linker non dovrebbero fornire una modalità "output canonico" in cui l'output dipende solo dai file di origine e da una "data di compilazione" che può essere sovrascritta dall'utente . Anche se la compilazione del codice in tale modalità richiedesse il doppio della normale compilazione, suggerirei che ci sarebbe un valore considerevole nel poter ricreare qualsiasi "build di rilascio", byte per byte, interamente dai materiali di origine, anche se ciò significava che le build di rilascio richiederebbero più tempo delle "build normali".