5 ms·

Ken Thompson's hack is purely theoretical, especially in the modern computing landscape where the diversification of software supply chains would make such hack

Ken Thompson's hack is purely theoretical, especially in the modern computing landscape where the diversification of software supply chains would make such hack much 1. less effective and 2. easier to detect. If we're talking about kernel security, there are other lower hanging exploits, many of which are enabled by outdated language design decisions and unsafe memory models. As compiler technologies evolve, it becomes not only a necessary evil but rather a better course of action to trust compilers rather than humans tiptoeing around security risks masquerading as language idiosyncrasies.

yjftsjthsd-h 5y ago
> Ken Thompson's hack is purely theoretical Erm. I was always under the impression that he had actually done it, and that his presentation was a historical anecdote. Is that not the case?
- neysofu 5y ago
  Yes, he did, but that just shows that it's possible to inject self-replicating code in a compiler. It doesn't actually tell us how resistant such code is to compiler source changes, audits, binary analysis, etc. which are all required for a successful exploit.
  - boogies 5y ago
    But the University of Minnesota experiments prove at least some malicious code is capable of passing at least standard Linux code review, right?
    - IshKebab 5y ago
      That's a completely separate issue. The trusting trust bug requires you to convince people to use your compiler binaries. The thing you're talking about just requires a patch to pass code review. It's more work - you have to figure out a sneaky bug and write a legit looking patch - but anyone can do it. You don't have to be in a position of power already (e.g. being the Debian GCC packager) so overall it is much easier.
    - gmfawcett 5y ago
      There's a world of difference between that and Thompson's attack. You don't exploit the kernel code: you exploit the compiler code, such that every program it compiles (a) is compromised, and (b) is incapable of detecting the exploit in programs compiled by the same compiler.
    - lupire 5y ago
      Parent didnt say anything about patch code review.
    - lonjil 5y ago
      No, no malicious code passed. All malicious code was rejected before making it into the kernel.
    - josefx 5y ago
      I think they only got past a single reviewer and counted that as success, none of their harm code made it into the kernel proper. However the University also committed thousands of automated "fixes" for linter warnings that weren't part of the study and the kernel maintainers ended up reverting all of them due to the Universities overblown claims.
- steveklabnik 5y ago
  On a technical level, the hack has been demonstrated to work, but actually hacking someone via the technique has not, in my understanding.
  - truffdog 5y ago
    Does https://en.m.wikipedia.org/wiki/XcodeGhost https://en.m.wikipedia.org/wiki/XcodeGhost count? It's not targeting compiler developers, so it can't worm forever, but it is a malicious compiler that weaponizes its output.
  - dreamcompiler 5y ago
    As far as we know. Thompson's hack relies on the Halting Problem, and the space for deviousness within the Halting Problem is infinitely large.
  - marcan_42 5y ago
    It's obvious that the hack would work on a technical level, that's fundamental to the whole idea. The question is how complex the logistics of doing it in the real world would be; how you insert the tampered code, how you avoid anyone noticing, etc. For example, I run Gentoo Linux, and haven't reinstalled my OS since 2004 or so. That means that, modulo a few binary packages, I have a direct source lineage to the state of Linux in 2004. If you want to pull off that attack against my system (and you didn't already back in 2004), you'd have to tamper with source archives. That would both imply changes that are easy to analyze (more than binary patches), and it would involve changing the archive hashes in the Portage tree. That tree is in Git, which means that it would create an immutable public record of what happened (Git is the original blockchain, remember), modulo forced pushes which people would, again, notice all over the place. In practice, if you want to persistently backdoor a new system (supply chain attack), it's usually easier to do that in hardware or firmware than trying to do a RoTT attack on the distro and its compiler. In fact, it's users of binary distributions (or proprietary OSes) that should be more worried, as it is much easier to do a binary-based RoTT attack that self-updates to handle new versions consistently when all your users run the exact same binaries. Source code users should be more worried about compromise upstream than local persistence. And those attacks are a review / auditing issue, unrelated to RoTT. In the end, if you are worried about being personally targeted, it's easy enough to make that impractical by re-bootstrapping your computing from an unpredictable source (e.g. walk into a random shop and buy a PC, walk into a net cafe and download your favorite distro and check the hashes there). And if you are worried about large-scale attacks, RoTT style ones aren't practical without someone somewhere noticing; you should be worried about traditional compromise instead.
TheDesolate0 5y ago
rurban 5y ago
In this case practical attacks are very likely, due to insecurities added with C11 and the stoneage review model of Linux development. C11 added insecure Unicode identifiers, and you won't find them in reviewing them manually via email. You need a special linter to detect such Unicode attacks. Or a proper development environment. Compiler development usually evolves into more bugs, not less. Just now they caught up with the hundreds of bugs they added with gcc-9. Not talking about const, restrict, and strict aliasing, and the still not existing -Oboring for the kernel. Would you dare to use -O3 and -flto and -fstrict-aliasing in the kernel?
- marcan_42 5y ago
  Linux has a checkpatch.pl. If it doesn't already test for Unicode identifiers, it would be trivial to add that. This is a non-issue. You don't ban a new version of a language just because it allows some undesirable things; it's trivial to ban those things specifically, either with scripting or specific compiler option overrides. Heck, Linux already uses GCC plug-ins to implement some fancier security stuff; it is silly to think they can't handle forbidding Unicode identifiers.

yjftsjthsd-h 5y ago

> Ken Thompson's hack is purely theoretical Erm. I was always under the impression that he had actually done it, and that his presentation was a historical anecdote. Is that not the case?

neysofu 5y ago
Yes, he did, but that just shows that it's possible to inject self-replicating code in a compiler. It doesn't actually tell us how resistant such code is to compiler source changes, audits, binary analysis, etc. which are all required for a successful exploit.
- boogies 5y ago
  But the University of Minnesota experiments prove at least some malicious code is capable of passing at least standard Linux code review, right?
  - IshKebab 5y ago
    That's a completely separate issue. The trusting trust bug requires you to convince people to use your compiler binaries. The thing you're talking about just requires a patch to pass code review. It's more work - you have to figure out a sneaky bug and write a legit looking patch - but anyone can do it. You don't have to be in a position of power already (e.g. being the Debian GCC packager) so overall it is much easier.
  - gmfawcett 5y ago
    There's a world of difference between that and Thompson's attack. You don't exploit the kernel code: you exploit the compiler code, such that every program it compiles (a) is compromised, and (b) is incapable of detecting the exploit in programs compiled by the same compiler.
  - lupire 5y ago
    Parent didnt say anything about patch code review.
  - lonjil 5y ago
    No, no malicious code passed. All malicious code was rejected before making it into the kernel.
  - josefx 5y ago
    I think they only got past a single reviewer and counted that as success, none of their harm code made it into the kernel proper. However the University also committed thousands of automated "fixes" for linter warnings that weren't part of the study and the kernel maintainers ended up reverting all of them due to the Universities overblown claims.
steveklabnik 5y ago
On a technical level, the hack has been demonstrated to work, but actually hacking someone via the technique has not, in my understanding.
- truffdog 5y ago
  Does https://en.m.wikipedia.org/wiki/XcodeGhost https://en.m.wikipedia.org/wiki/XcodeGhost count? It's not targeting compiler developers, so it can't worm forever, but it is a malicious compiler that weaponizes its output.
- dreamcompiler 5y ago
  As far as we know. Thompson's hack relies on the Halting Problem, and the space for deviousness within the Halting Problem is infinitely large.
- marcan_42 5y ago
  It's obvious that the hack would work on a technical level, that's fundamental to the whole idea. The question is how complex the logistics of doing it in the real world would be; how you insert the tampered code, how you avoid anyone noticing, etc. For example, I run Gentoo Linux, and haven't reinstalled my OS since 2004 or so. That means that, modulo a few binary packages, I have a direct source lineage to the state of Linux in 2004. If you want to pull off that attack against my system (and you didn't already back in 2004), you'd have to tamper with source archives. That would both imply changes that are easy to analyze (more than binary patches), and it would involve changing the archive hashes in the Portage tree. That tree is in Git, which means that it would create an immutable public record of what happened (Git is the original blockchain, remember), modulo forced pushes which people would, again, notice all over the place. In practice, if you want to persistently backdoor a new system (supply chain attack), it's usually easier to do that in hardware or firmware than trying to do a RoTT attack on the distro and its compiler. In fact, it's users of binary distributions (or proprietary OSes) that should be more worried, as it is much easier to do a binary-based RoTT attack that self-updates to handle new versions consistently when all your users run the exact same binaries. Source code users should be more worried about compromise upstream than local persistence. And those attacks are a review / auditing issue, unrelated to RoTT. In the end, if you are worried about being personally targeted, it's easy enough to make that impractical by re-bootstrapping your computing from an unpredictable source (e.g. walk into a random shop and buy a PC, walk into a net cafe and download your favorite distro and check the hashes there). And if you are worried about large-scale attacks, RoTT style ones aren't practical without someone somewhere noticing; you should be worried about traditional compromise instead.

TheDesolate0 5y ago

rurban 5y ago

In this case practical attacks are very likely, due to insecurities added with C11 and the stoneage review model of Linux development. C11 added insecure Unicode identifiers, and you won't find them in reviewing them manually via email. You need a special linter to detect such Unicode attacks. Or a proper development environment. Compiler development usually evolves into more bugs, not less. Just now they caught up with the hundreds of bugs they added with gcc-9. Not talking about const, restrict, and strict aliasing, and the still not existing -Oboring for the kernel. Would you dare to use -O3 and -flto and -fstrict-aliasing in the kernel?

marcan_42 5y ago
Linux has a checkpatch.pl. If it doesn't already test for Unicode identifiers, it would be trivial to add that. This is a non-issue. You don't ban a new version of a language just because it allows some undesirable things; it's trivial to ban those things specifically, either with scripting or specific compiler option overrides. Heck, Linux already uses GCC plug-ins to implement some fancier security stuff; it is silly to think they can't handle forbidding Unicode identifiers.