Ken Thompson Hack (1984)
Ken Thompson outlined a method for corrupting a compiler binary (and other compiled software, like a login script on a *nix system) in 1984. I was curious to know if modern compilation has addressed this security flaw or not.
Short description:
Re-write compiler code to contain 2 flaws:
- When compiling its own binary, the compiler must compile these flaws
- When compiling some other preselected code (login function) it must compile some arbitrary backdoor
Thus, the compiler works normally – when it compiles a login script or similar, it can create a security backdoor, and when it compiles newer versions of itself in the future, it retains the previous flaws – and the flaws will only exist in the compiler binary so are extremely difficult to detect.
Questions:
I could not find any answers to these on the web:
- How does this relate to just-in-time compilation?
- Are functions like the program handling logins on a *nix system compiled when they are
run? - Is this still a valid threat, or have there been developments in
the security of compilation since 1984 that prevent this from being a
significant issue? - Does this affect all languages?
Why do I want to know?
I came across this while doing some homework, and it seemed interesting but I lack the background to understand in a concrete way whether this is a current issue, or a solved issue.
Best Answer
This hack has to be understood in context. It was published at a time and in a culture where Unix running on all kinds of different hardware was the dominant system.
What made the attack so scary was that the C compiler was the central piece of software for these systems. Almost everything in the system went through the compiler when it was first installed (binary distributions were rare due to the heterogenous hardware). Everyone compiled stuff all the time. People regularly inspected source code (they often had to make adjustments to get it to compile at all), so having the compiler inject backdoors seemed to be a kind of "perfect crime" scenario where you could not be caught.
Nowadays, hardware is much more compatible and compilers therefore have a much smaller role in the day-to-day operation of a system. A compromised compiler is not the most scary scenario anymore - rootkits and a compromised BIOS are even harder to detect and get rid of.