that would be a pretty evil way to enforce payment, aka a DRM that turns racist if you don't pay up.
Ask HN: Please help me recall a certain programmer horror story
11–20 of 44 posts
Re: Ask HN: Please help me recall a certain programmer horror story
#12Earlier quoted context omitted.
> Because the compiler was poisoned with other source code that we didn't have. And that source code, that now existed only in the executable compiler, put those changes back into the compiler source before it compiled it. I don't quite understand this part. How would this work?
You need a compiler to compile anything, including a compiler, so if your compiler was tampered with then anything you compile can be tampered with as well. The only solution is be to download a binary compiler from someone you trust.
yes, but ken thompsons evil compiler theory states, that a trusted compiler is technically impossible (in the paranoid world of theoretical security where all compiler binaries are possibly tainted already) except if you write your own bootstrap compiler chain in machine code. still, all other running software (OS/drivers/the intel management engine) might be able to modify the binary in memory on the fly. the rabbit hole goes down to the hardware level.
Re: Ask HN: Please help me recall a certain programmer horror story
#13I mentioned this "malicious version of compiler" on my web page about my approach for countering the trusting trust attack. See: https://www.dwheeler.com/trusting-trust/
Re: Ask HN: Please help me recall a certain programmer horror story
#14that would be a pretty evil way to enforce payment, aka a DRM that turns racist if you don't pay up.
It's an equally effective way to end a career (perhaps before it's even begun, as this is a graduate student's work we're talking of). Regardless, it's a stunningly bold lack of judgement. But then, bad decisions often make for interesting stories.
Re: Ask HN: Please help me recall a certain programmer horror story
#15https://www.quora.com/What-is-a-coders-worst-nightmare/answe...
> Because the compiler was poisoned with other source code that we didn't have. And that source code, that now existed only in the executable compiler, put those changes back into the compiler source before it compiled it. I don't quite understand this part. How would this work?
They got clean source for the compiler from the AT&T person. However, they neglected to get a clean binary for the compiler.
They compiled the clean source using the existing, malicious compiler installation. That compiler had a counter-measure against being recompiled from clean sources; it recognized that situation and perpetrated itself.
(A clean compiler binary might not help; suppose the trick involves other binaries, like the C library. They didn't have the kernel source so it was fairly reasonable to regard the kernel as clean.)
Re: Ask HN: Please help me recall a certain programmer horror story
#16This story strikes me as likely to be exaggerated or invented. It is exactly the scenario described in Ken Thomson's Reflections on Trusting Trust. But unlike Thomson, who was developing the compiper, there is no reason a random grad student would have access to recompile the compiler. And if the student gained root access to replace system binaries, why would they bother making the compiler reinfect itself on recompilation?
Re: Ask HN: Please help me recall a certain programmer horror story
#17https://www.quora.com/What-is-a-coders-worst-nightmare/answe...
Jesus, that is intense. I wonder if the guy was personally out to get the Doc, or if he was just a smart kid with too much time and not enough superego?
He did make it super easy to find this by having the compiler modify source code. If you run "cc file.c" and file.c is overwritten, you should know that it's the "cc" doing it.
It would have been more evil to do it the original way, as described in Thompson's paper: recognize the program sources and emit altered object code only; no mucking with the source.
Re: Ask HN: Please help me recall a certain programmer horror story
#18I didn't recognize the story from your description but after the first paragraph its unmistakable.
A good, fun read. Thank you!
Re: Ask HN: Please help me recall a certain programmer horror story
#19https://www.quora.com/What-is-a-coders-worst-nightmare/answe...
Thank you, that's it!
Re: Ask HN: Please help me recall a certain programmer horror story
#20Earlier quoted context omitted.
> Because the compiler was poisoned with other source code that we didn't have. And that source code, that now existed only in the executable compiler, put those changes back into the compiler source before it compiled it. I don't quite understand this part. How would this work?
You need a compiler to compile anything, including a compiler, so if your compiler was tampered with then anything you compile can be tampered with as well. The only solution is be to download a binary compiler from someone you trust.
I think another solution would be to insert and compile the source of a different compiler, hopefully a rare one like TCC, or even a C interpreter of some sort. The evil compiler can't be programmed to recognize all conceivable C compilers; there must be a small finite list it understands. (This was probably a difficult option back then.)
Depending on how advanced the evil compiler is... Plan A would be to use it to compile TCC, then TCC to compile the original compiler. If the evil compiler inserts into every binary the generic command sequence "search for files that look like the original compiler and evil-ify them", then Plan B is to use evil to compile TCC, then use the resulting slightly-evil-TCC to compile TCC, then use the resulting clean TCC to compile the original.
If someone has also modified the kernel such that anytime someone uses the syscall "chmod" to mark a file as executable, it'll add evil instructions to that file... Well, perhaps you could recompile the kernel, but it'd be easy for evil instructions to cover that too... finding a new independent kernel source that runs on your machine is probably pretty hard... it'd also kind of interfere with downloading good binaries onto the machine, if the process was "download to a file, then chmod", though if it was "chmod, then write to the file", the evil kernel would have to be clever enough to make it instead append to after the evil instructions; you also could attach a disk and mount it and run executables already on it, and that would be pretty complicated for the evil code to transparently handle (of course, it could just refuse to run such things, but there are lots of things it could refuse to do).