Groups | Search | Server Info | Login | Register

Groups > comp.security.misc > #1548

Re: Finding backdoors

Show all headers | View raw

Richard L. Hamilton <rlhamil@smart.net> wrote:
> 
> It's worse than that even. See
> 
> Reflections on Trusting trust
> 
> https://dl.acm.org/doi/pdf/10.1145/358198.358210
> 
> by Ken Thompson, the co-creator of Unix along with DMR.
> 
> It describes adding some code to the C compiler that will insert into
> login.c a magic password for root power, and into a re-compile of the
> compiler, the code needed to propagate itself and that login.c backdoor.
> 
> At that point, the source code can be put back to not have either bit of
> code in it, but the compiler will continue to insert it into future
> versions of itself, preserving the login backdoor. (at least until the
> compiler or login.c source code changes to such an extent that it can't
> recognize where to insert the extra code)
> 
> Since you need a compiler binary to get started building/rebuilding a
> toolchain, even if the source code is ALL clean, you can't trust the end
> result.
> 
> 
> That was published in 1983, and hints that some of the idea may have
> existed even earlier. These days such a thing could be smarter and survive
> longer.
> 
> If you had two different compilers of independent origin, and full source
> for both, and some way of comparing that the resulting binaries were, not
> identical bit-for-bit, but functionally identical, then you might be ok.
> And of course you can spot non-obfuscated strings in a binary, but if they
> are obfuscated cleverly, it will take a lot of reverse engineering to spot
> them.
> 
> Decompiling, good luck with that. Disassembling, yes; but decompiling would
> depend on knowing the exact idioms of the exact version of the compiler and
> relevant options (optimization, etc) used. Not a bat's chance in hell of
> getting that to work consistently.
> 
> Beat the crap out of it in an isolated, throwaway VM, not to mention
> running valgrind, purify, and anything else like that you can? Still no
> guarantee you get it all. For all I know, proving something complex enough
> is secure might be like a general solution to the halting
> problem...impossible.
> 
> If you do everything yourself on an isolated network, and don't import
> anyone else's code (open source or not), then maybe. But there's always the
> insider threat...
> 
> As long as tinfoil hats are not involved (but Faraday cages around your
> computer room might make sense), there's no such thing as too much
> paranoia. :-)
> 
> That said, a computer buried in concrete so it can't run is secure. But
> it's not useful. You have to decide what level of risk reduction is worth
> the eventually increasing cost for diminishing returns.
> 

A fascinating article, entirely new to me. 

Have any examples of such a trojan been found, or even suspected?
After forty years, one might expect to see it "in the wild" or at
least see plausible consequences if it's viable in practice.

Thank you!

bob prohaska

Back to comp.security.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Finding backdoors <bp@www.zefox.net> - 2024-09-26 15:26 +0000
  Re: Finding backdoors Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-09-26 20:15 +0200
    Re: Finding backdoors William Unruh <unruh@invalid.ca> - 2024-09-26 19:57 +0000
      Re: Finding backdoors Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-09-27 17:31 +0200
        Re: Finding backdoors William Unruh <unruh@invalid.ca> - 2024-09-27 16:26 +0000
          Re: Finding backdoors Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-09-27 20:11 +0200
  Re: Finding backdoors Richard Kettlewell <invalid@invalid.invalid> - 2024-09-28 10:09 +0100
    Re: Finding backdoors <bp@www.zefox.net> - 2024-10-01 04:01 +0000
      Re: Finding backdoors Richard Kettlewell <invalid@invalid.invalid> - 2024-10-01 16:44 +0100
      Re: Finding backdoors rlhamil@smart.net (Richard L. Hamilton) - 2024-10-18 21:04 +0000
        Re: Finding backdoors <bp@www.zefox.net> - 2024-10-18 23:37 +0000
          Re: Finding backdoors rlhamil@smart.net (Richard L. Hamilton) - 2024-10-19 02:20 +0000

csiph-web