he hacked /bin/login to introduce a backdoor.
he did this by hacking the compiler to introduce the backdoor into a binary whenever it detected that it was compiling the login source code.
he also hacked the compiler to introduce the backdoor-producing code into the compiler whenever it detected it was compiling that.
No, non l'ha fatto. Ha tenuto un discorso in cui ha spiegato come questo potrebbe essere fatto.
My question is why did he need both of of these "hacks".
Non l'ha fatto. Il punto centrale del discorso è che finché controlli il punto qualsiasi nella catena in cui il codice è in qualche modo interpretato o trasformato, puoi introdurre le backdoor in questo modo.
Puoi controllare il codice sorgente di /bin/login per trovare la backdoor. Quindi, Thompson sposta la backdoor di un passo avanti nel compilatore. Ma allora puoi controllare il codice del compilatore per trovare il codice che introduce la backdoor. Quindi, Thompson lo sposta di un passo avanti nel compilatore che compila il compilatore. Tu potresti ispezionare quella fonte del compilatore, ma sai cosa succede allora: Thompson sposta ulteriormente l'hack nel compilatore che compila il compilatore che compila il compilatore.
In alternativa, l'hack potrebbe anche essere inserito nel linker. Oppure potrebbe essere inserito nel decodificatore di istruzioni all'interno della CPU (potrebbe rilevare le istruzioni binarie che costituiscono /bin/login ed eseguire invece un codice diverso). Oppure, il caricatore binario del sistema operativo potrebbe rilevare /bin/login e scambiare il suo codice.
L'hack potrebbe anche essere distribuito in più posti.
Also Has the ‘Ken Thompson Hack’ (KTH) been eradicated, or have there been more recent cases of it?
Ancora una volta, il punto della discussione è che finché qualcun altro ha il controllo su un solo pezzo del puzzle, allora un hack come questo non può essere rilevato e non può essere prevenuto.
What impact does the KTH have if it turns out to be widespread (i.e., not the specific program that he used, but applying the hack to other programs)?
L'impatto è che devi controllare e controllare ogni singolo pezzo del puzzle dell'intero sistema se vuoi essere sicuro. A meno che non progettiate, implementate e create la vostra CPU, il vostro firmware, il vostro bootloader, i vostri dispositivi periferici (e le loro CPU e firmware), il vostro sistema operativo, i vostri driver, i vostri protocolli , le tue librerie, il tuo assemblatore, il tuo compilatore, il tuo linker, i tuoi quadri, le tue applicazioni, non puoi mai essere al sicuro.