2

I understand Ken Thmpson hack involved like someone has mentioned on here

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.

My question is why did he need both of of these "hacks". Also Has the ‘Ken Thompson Hack’ (KTH) been eradicated, or have there been more recent cases of it?

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)?

0
5

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.

6
  • yes sorry should have said he introduced the idea – John hopkins Apr 9 '17 at 16:59
  • really appreciate the answer though great help friend – John hopkins Apr 9 '17 at 17:01
  • Note, however, that it's since been confirmed that this was actually implemented, so it wasn't restricted to being just an idea. And yes, it was eradicated, at least from the official Unix code base, long ago. Even after the talk, it hasn't become a popular attack vector though--largely, I'd guess because it's quite a lot of work to implement, and mostly fails as soon as the user has access to an independently developed compiler. – Jerry Coffin Apr 9 '17 at 18:07
  • interesting so there havent been any recent cases of it? – John hopkins Apr 9 '17 at 19:04
  • @Johnhopkins: Not to my knowledge, no. Having multiple open source compilers probably helps. – Jerry Coffin Apr 9 '17 at 20:31
0

he used both hacks so this way, the source code for the C compiler would never show that these trojans existed. (if you read the rest of the paragraph you would've figured the answer).

yes there are some cases but its not as scary as it used to be since our hardware and compilers are more compatible

i don't know the last one.

Not the answer you're looking for? Browse other questions tagged or ask your own question.