The attack was successfully performed in the wild by the virus "Win32/Induc.A"
The virus looks for a Delphi installation, modifies the SysConst.pas file, which is the source code of a part of the standard library and compiles it. After that, every program compiled by that Delphi installation will contain the virus.
The virus does nothing else, it is therefore harmless if you don't have Delphi installed.
It resulted in many software vendors releasing infected executables without realizing it, sometimes claiming false positives. After all, the executable was not tampered with, the compiler was.
In 2015, a malicious copy of Xcode, XcodeGhost, also performed a similar attack and infected iOS apps from a dozen of software companies in China. Globally, 4000 apps were found to be affected. It was not a true Thompson Trojan, as it doesn't infect development tools themselves, but it did show toolchain poisoning can indeed cause substantial damages.
That's not quite the Karger–Thompson attack; it's just a garden-variety library backdoor, being inserted by a garden-variety virus. Garden-variety viruses are self-replicating, and so is the Karger–Thompson attack, but they don't have much else in common.
The key thing about the Karger–Thompson attack — the thing that makes it so scary — is that all your source code can be absolutely clean, you can recompile the compiler from clean source code, and you're still compromised.
But if you recompiled the Delphi compiler from an infected installation...
It's not that scary if you actually bother doing binary analysis. Especially now with things like Godbolt.
What made it as horrifying as it was at the time was the closed nature of compilers, and the increasing unfamiliarity with what actual machine code looked like, and the non-existence of tooling to help recerse actual runtime behavior.
Popping in a hidden 'hunter2' login handler is still going to require hiding/deriving/comparing against that state/hash/input on that machine. That extra cruft is going to stick out.
Whether anyone can be bothered to dig into it is another question. Theoretically speaking though, all computation is human reading or writing, just implemented with circuits.
Well, something like seL4 with its proof of binary correctness could maybe solve the problem, unless the attacker manages to backdoor Coq too.
But I think the situation now, relative to then, is precisely the opposite of what you state. The C compiler Thompson backdoored was distributed as source code under a fairly liberal (but non-transferable) license; its compiled form was only a few tens of thousands of instructions, including all the libraries it was linked with; the people it was distributed to were very familiar with the machine code; and single-stepping through machine code was a common way to debug problems. An old boss of mine had his first system administrator job about that time; his first task as a sysadmin, as I recall it, was to port a program written in assembly language to the operating system they were using.
By comparison, today, many people use compilers they don't even have source code for; GCC and clang are tens of millions of instructions; many programmers even in C, C++, and other such low-level languages don't know assembly; most programmers work in high-level languages like Python, Java, or JS, and those have even less familiarity with assembly; and there are some eight orders of magnitude more useless computation being carried out in which such a backdoor could hide.
Indeed. I'm one of the few who actually does dive into binary/asm on occasion, or at least try to decompile/reverse binaries for the lulz.
These days you probably could sneak something in with a good chance of getting away with it for a while with the complexity explosion and volume of code to go through. That doesn't mean it isn't unrecoverable from though, even if every compiler is infected.
Maybe. We're talking about a hypothetical power struggle, one aspect of which is that one group subverts the computing resource of another group. Even if at some point the second group realizes this has happened (potentially difficult when not only their decompilation tools but also their intragroup communications are subject to interception and alteration by the first group) there's no guarantee that they will ever regain control of those resources. The first group may be able to leverage their control enough to severely impact the second group's prospects in every aspect of the struggle.
More generally, when groups of people are engaged in a power struggle, there's no guarantee that things will return to the status quo ante.
Definitely did not touch on the linking toolchain in the CS101 I did. I ended up having to figure that out the hard way through Linux From Scratch builds and cobbling together weird symbol resolution environments based on wanting to do things in my own idiosyncratic way.
Ghidra helps a lot these days. ldd and the other linker/binutils do the rest.
The virus looks for a Delphi installation, modifies the SysConst.pas file, which is the source code of a part of the standard library and compiles it. After that, every program compiled by that Delphi installation will contain the virus.
The virus does nothing else, it is therefore harmless if you don't have Delphi installed.
It resulted in many software vendors releasing infected executables without realizing it, sometimes claiming false positives. After all, the executable was not tampered with, the compiler was.