The Ken Thompson Hack • Hacker News Board

Re: The Ken Thompson Hack

#41

Post by dwheeler » Sun, Mar 31, 2024, 1:51 AM UTC

legobmw99 wrote: post #29

dwheeler wrote: post #22

For more, including information about the "Diverse Double-Compiling" (DDC) countermeasure, see my page: https://dwheeler.com/trusting-trust/

Question from reading the abstract: how does one acquire this “second (trusted) compiler” when you are genuinely suspicious you are facing an adversary using an attack like this one?

The second compiler can be subverted, as long as it's not subverted the same way.

In particular, it could be one you wrote yourself. It doesn't need to support everything, just enough to compile the compiler under test.

It could also be a compiler from a different group/organization.

You could use many compilers and test with all them.

Re: The Ken Thompson Hack

#42

Post by 1letterunixname » Sun, Mar 31, 2024, 7:11 AM UTC

Open source hardware including silicon, board designs, and firmware coupled with deep supply chain surveillance are needed to mitigate this threat. There is no other way other than destructive and NDT of samples with verification. Also, an entire board of chips needs to be superficially verifiable over JTAG or some bus. There's nowhere to hide if a chip can be Xray matched to its design and to its RTL model.

Re: The Ken Thompson Hack

#43

Post by philipswood » Sun, Mar 31, 2024, 9:00 AM UTC

ludocode wrote: post #27

necheffa wrote: post #25

Earlier quoted context omitted.

So bootstrap in freestanding does make this kind of attack much more difficult to pull off, but with contemporary hardware, it does not fully prevent the attack. What if the trojan is in microcode? No amount of bootstrap in freestanding can protect you here.

It is true that there are many layers of code below the OS level. UEFI for example is probably hundreds of thousands of lines of compiled code. Modern processors have Intel IME and equivalent with their own secret firmware. Almost all modern peripherals will have microcontrollers with their own compiled code. These are all genuine attack vectors but they are not really solvable from the software side. At least for On…

Boot from obfuscated VM running on a FPGA softcore?

Maybe on two completely different ones and verify for differences.

Re: The Ken Thompson Hack

#44

Post by fsflover » Sun, Mar 31, 2024, 10:01 AM UTC

ellis0n wrote: post #37

fsflover wrote: post #36

Earlier quoted context omitted.

Not all data on your PC are equally dangerous. The key is to keep Trusted Computing Base as small as possible. See: Qubes OS.

QubesOS is amazing! I've been working on QubesOS for several years. When it was just starting out, it was a fairly simple solution, but now it's a big software, and it has just as many problems as any Linux distribution. Complexity is the only parameter by which you can determine the amount of malware. For 0 bytes of useful code, there will be 0 backdoors. I also developed ACPU OS for this reason 12 years ago, but la…

> but now it's a big software, and it has just as many problems as any Linux distribution

Could you elaborate? The TCB did not increase since almost the beginning of Qubes. Moreover, the hardware-assisted virtualization by default improved the security a lot. Also, Qubes is not a Linux distribution: https://www.qubes-os.org/faq/#is-qubes-just-another-linux-di...

Re: The Ken Thompson Hack

#45

Post by betimsl » Mon, Apr 01, 2024, 2:03 PM UTC

I think UNIX will be secure; next generation of AI will be able to scan directly the image of a compiled kernel and will be able to detect -- if not all -- harmful things.

Re: The Ken Thompson Hack

#46

Post by civodul » Mon, Apr 01, 2024, 7:46 PM UTC

anthk wrote: post #35

GNU Mes tries to avoid this by bootstrapping everything .

Yes, and it's not an academic exercise: it's being used in Guix (together with related projects such as stage0, M2-Planet, and Gash) to build everything from source starting from a 357-byte program:

https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

This gives the level of auditability and transparency that we desperately need.

However, the same problem of "yogurt software" manifests at higher levels of the stack, typically with compilers and build systems, some of which still cannot be built from source (GHC and Bazel come to mind).