The attack, as originally described, was never a threat. While a compiler could theoretically do this, actually pulling off the attack would require programming the compiler to
- Recognize when the source code being compiled is of a compiler, and
- Figure out how to modify arbitrary source code to insert the hack into it.
This entails figuring out how the compiler works from its source code, in order that it can modify it without breakage.
For instance, imagine that the linking format stores the data lengths or offset of the compiled machine code somewhere in the executable. The compiler would have to figure out for itself which of these need to be updated, and where, when inserting the exploit payload. Subsequent versions of the compiler (innocuous version) can arbitrarily change this format, so the exploit code would effectively need to understand these concepts.
This is high-level self-directed programming, a hard AI problem (last I checked, the state of the art was generating code that is practically determined by its types). Look: few humans can even do this; you would have to learn the programming language and understand the code-base first.
Even if the AI problem is solved, people would notice if compiling their tiny compiler results in a binary with a huge AI library linked into it.
Analogous attack: bootstrapping trust
However, a generalization of the attack is relevant. The basic issue is that your chain of trust has to start somewhere, and in many domains its origin could subvert the entire chain in a hard-to-detect way.
An example that could easily be pulled off in real life
Your operating system, say Ubuntu Linux, ensures security (integrity) of updates by checking downloaded update packages against the repository's signing key (using public-key cryptography). But this only guarantees authenticity of the updates if you can prove that the signing key is owned by a legitimate source.
Where did you get the signing key? When you first downloaded the operating system distribution.
You have to trust that the source of your chain of trust, this signing key, isn't evil.
Anyone that can MITM the Internet connection between you and the Ubuntu download server—this could be your ISP, a government that controls Internet access (e.g. China), or Ubuntu's hosting provider—could have hijacked this process:
- Detect that you're downloading the Ubuntu CD image. This is simple: see that the request is going to any of the (publicly-listed) Ubuntu mirrors and asks for the filename of the ISO image.
- Serve the request from their own server, giving you a CD image containing the attacker's public key and repository location instead of Ubuntu's.
Thenceforth, you will get your updates securely from the attacker's server. Updates run as root, so the attacker has full control.
You can prevent the attack by making sure the original is authentic. But this requires that you validate the downloaded CD image using a hash (few people actually do this)—and the hash must itself be downloaded securely, e.g. over HTTPS. And if your attacker can add a certificate on your computer (common in a corporate environment) or controls a certificate authority (e.g. China), even HTTPS provides no protection.