4 ms·

There is something nightmarish about this kind of exploit, and that is maybe why we've been collectively in denial for such a long time. How many supply-chain

There is something nightmarish about this kind of exploit, and that is maybe why we've been collectively in denial for such a long time. How many supply-chain generated backdoors in the wild today?

kibwen 3y ago
Supply-chain backdoors are one thing, but the saving grace about the backdoors injected by trusting-trust attacks like in the OP is that they're quite fragile. If the shape of the expected target program changes sufficiently, then the backdoor will fail to propagate. And propagating the backdoor into programs that have yet to be written requires an effectively omnisicient adversary. As long as you have multiple implementations of a toolchain, you can repeatedly use them to compile each other in every possible configuration (and then use the outputs of those compilation steps as inputs to the same process, repeatedly) and then compare that the outputs are bit-for-bit identical until you reach a point where you're assured that either none of the compilers are backdoored or all of them would have to be. So yes, they're scary, but there are countermeasures.
- deleted 3y ago
  [deleted]
legobmw99 3y ago
One of my favorite short stories plays on the natural horror of this realization: https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/
- stuartd 3y ago
  Thank you! I was immediately reminded of that story when I read the article, but would never have been able to find it!
Veserv 3y ago
I mean, this class of attack is defeated as a matter of course in high reliability applications like aerospace. You just check the compiler output precisely corresponds to the compiler input. You need to do that anyways to prevent miscompilation errors in general (this class of attack is just intentional miscompilation), so it hardly counts as a nightmarish problem, just a annoying one.
- azornathogron 3y ago
  How is this normally done? Manual review of machine code?
  - Veserv 3y ago
    I do not work on verification directly, so I do not know the details. I believe at a high level you generally have a automated first pass which generates a source<->machine trace. You then have multiple independent reviews validating the correctness and exhaustiveness of the trace. Generally in these environments you build with optimizations off unless needed to ease this validation process as, obviously, you must validate the released/deployed version.
- kwhitefoot 3y ago
  > You just check the compiler output precisely corresponds to the compiler input. just is doing a lot of work there.
  - Veserv 3y ago
    What do you want me to say? That is the work that you must do and that is routinely done. It is annoying, but it is not hard or special. Hardly a nightmarish problem if it gets solved routinely at scale across a entire industry.

There is something nightmarish about this kind of exploit, and that is maybe why we've been collectively in denial for such a long time. How many supply-chain generated backdoors in the wild today?

kibwen 3y ago

Supply-chain backdoors are one thing, but the saving grace about the backdoors injected by trusting-trust attacks like in the OP is that they're quite fragile. If the shape of the expected target program changes sufficiently, then the backdoor will fail to propagate. And propagating the backdoor into programs that have yet to be written requires an effectively omnisicient adversary. As long as you have multiple implementations of a toolchain, you can repeatedly use them to compile each other in every possible configuration (and then use the outputs of those compilation steps as inputs to the same process, repeatedly) and then compare that the outputs are bit-for-bit identical until you reach a point where you're assured that either none of the compilers are backdoored or all of them would have to be. So yes, they're scary, but there are countermeasures.

deleted 3y ago
[deleted]

legobmw99 3y ago

One of my favorite short stories plays on the natural horror of this realization: https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/

stuartd 3y ago
Thank you! I was immediately reminded of that story when I read the article, but would never have been able to find it!

Veserv 3y ago

I mean, this class of attack is defeated as a matter of course in high reliability applications like aerospace. You just check the compiler output precisely corresponds to the compiler input. You need to do that anyways to prevent miscompilation errors in general (this class of attack is just intentional miscompilation), so it hardly counts as a nightmarish problem, just a annoying one.

azornathogron 3y ago
How is this normally done? Manual review of machine code?
- Veserv 3y ago
  I do not work on verification directly, so I do not know the details. I believe at a high level you generally have a automated first pass which generates a source<->machine trace. You then have multiple independent reviews validating the correctness and exhaustiveness of the trace. Generally in these environments you build with optimizations off unless needed to ease this validation process as, obviously, you must validate the released/deployed version.
kwhitefoot 3y ago
> You just check the compiler output precisely corresponds to the compiler input. just is doing a lot of work there.
- Veserv 3y ago
  What do you want me to say? That is the work that you must do and that is routinely done. It is annoying, but it is not hard or special. Hardly a nightmarish problem if it gets solved routinely at scale across a entire industry.