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, he did not. He gave a talk where he explained how this could be done.
My question is why did he need both of of these "hacks".
He didn't. The whole point of the talk is that as long as you have control of any point in the chain where code is in some way interpreted or transformed, you can introduce backdoors this way.
You can inspect the source code of /bin/login to find the backdoor. So, Thompson moves the backdoor one step further into the compiler. But then you can inspect the code of the compiler to find the code which introduces the backdoor. So, Thompson moves it one step further into the compiler which compiles the compiler. You could inspect that compiler's source, but you know what happens then: Thompson moves the hack even further into the compiler which compiles the compiler which compiles the compiler.
Alternatively, the hack could also be placed in the linker. Or it could be placed in the instruction decoder inside the CPU (it could detect the binary instructions that make up /bin/login and execute different code instead). Or, the OS's binary loader could detect /bin/login and swap its code out.
The hack could also be distributed across several places.
Also Has the ‘Ken Thompson Hack’ (KTH) been eradicated, or have there been more recent cases of it?
Again, the point of the talk is that as long as someone else has control over just one piece of the puzzle, then a hack like this cannot be detected and cannot be prevented.
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)?
The impact is that you must inspect and control every single piece of the puzzle of the entire system if you want to be secure. Unless you design, implement, and create your own CPU, your own firmware, your own bootloader, your own peripheral devices (and their CPUs and firmwares), your own OS, your own drivers, your own protocols, your own libraries, your own assembler, your own compiler, your own linker, your own frameworks, your own applications, you cannot ever be safe.
