7 ms·

> 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 thos

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

antsar 8y ago
If I read it correctly, they used the binary compiler which existed on the machine to compile a new copy of the compiler (from clean source). This existing binary compiler was "poisoned" (modified) such that it would not only poison the psychiatrist's program, but also poison any attempts to compile a new copy of the compiler. So when they recompiled the compiler, the new copy was already poisoned (because they used the old, poisoned compiler to do it).
ChristianBundy 8y ago
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.
- stefs 8y ago
  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.
  - emilfihlman 8y ago
    It doesn't even stop at hardware exactly (mcu/cpu), it only stops when you assemble the mcu/cpu yourself.
    - antsar 8y ago
      What if one of your transistors has a tiny logic board inside?
      - TheArcane 8y ago
        Logic boards can't be smaller than a modern transistor. Logic boards contain transistors.
        antsar 8y ago
        "modern transistors" are available in differently-sized packages. I assumed someone building their own CPU would be using larger transistors than those normally used inside a production CPU. You sure one of these[0] couldn't contain a tiny processor inside? [0] https://images-na.ssl-images-amazon.com/images/I/41bBdtuYF0L._SX342_.jpg https://images-na.ssl-images-amazon.com/images/I/41bBdtuYF0L...
      - emilfihlman 8y ago
        In theory yeah that's possible. But given that you'd have to cram quite a lot of logic inside to analyse and influence all custom systems when all you are given is a single line that's just a single line in a huge system.
- waterhouse 8y ago
  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).
kazinator 8y ago
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.)
- mark-r 8y ago
  Binary patching the kernel wouldn't be hard if you had root access to change the files. It's an old trick - jump from the legit code to new code you appended, then jump back when done.
  - kazinator 8y ago
    (You're right of course; what PC and Mac viruses have ever depended on kernel/bootloader source code?)
btschaegg 8y ago
That is one hell of a quine.

antsar 8y ago

If I read it correctly, they used the binary compiler which existed on the machine to compile a new copy of the compiler (from clean source). This existing binary compiler was "poisoned" (modified) such that it would not only poison the psychiatrist's program, but also poison any attempts to compile a new copy of the compiler. So when they recompiled the compiler, the new copy was already poisoned (because they used the old, poisoned compiler to do it).

ChristianBundy 8y ago

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.

stefs 8y ago
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.
- emilfihlman 8y ago
  It doesn't even stop at hardware exactly (mcu/cpu), it only stops when you assemble the mcu/cpu yourself.
  - antsar 8y ago
    What if one of your transistors has a tiny logic board inside?
    - TheArcane 8y ago
      Logic boards can't be smaller than a modern transistor. Logic boards contain transistors.
      - antsar 8y ago
        "modern transistors" are available in differently-sized packages. I assumed someone building their own CPU would be using larger transistors than those normally used inside a production CPU. You sure one of these[0] couldn't contain a tiny processor inside? [0] https://images-na.ssl-images-amazon.com/images/I/41bBdtuYF0L._SX342_.jpg https://images-na.ssl-images-amazon.com/images/I/41bBdtuYF0L...
    - emilfihlman 8y ago
      In theory yeah that's possible. But given that you'd have to cram quite a lot of logic inside to analyse and influence all custom systems when all you are given is a single line that's just a single line in a huge system.
waterhouse 8y ago
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).

kazinator 8y ago

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

mark-r 8y ago
Binary patching the kernel wouldn't be hard if you had root access to change the files. It's an old trick - jump from the legit code to new code you appended, then jump back when done.
- kazinator 8y ago
  (You're right of course; what PC and Mac viruses have ever depended on kernel/bootloader source code?)

btschaegg 8y ago

That is one hell of a quine.