Groups | Search | Server Info | Login | Register

Groups > comp.security.misc > #1545

Re: Finding backdoors

Show all headers | View raw

Richard Kettlewell <invalid@invalid.invalid> wrote:
> <bp@www.zefox.net> writes:
>> I'm looking for links to techniques for finding backdoors in software
>> and hardware.  It's a matter of personal curiosity inspired by the
>> exploding pager incident lately in the news and a call for banning
>> certain software developers.  An obvious question is whether use of
>> open-source software is a meaningful help.
> 
> In principle, yes.
> 
> * CVE-2024-3094 (the xz/SSH backdoor) could in principle have been
>   detected by source code review, although in fact the hint that led to
>   its discovery was runtime behavior. The open source model didn’t help
>   here; in fact it hurt - an under-resource open source project became
>   an attacker vector for a well-managed one.
> 
> * CVE-2015-7755 (a hardcoded adminstrative password in closed-source
>   router firmware) was ultimately identified by internal code
>   review[1]. In [2], there’s some discussion of how to find it by
>   analysing the binary. It’s hard to say whether it would have been
>   found earlier had the router firmware been open source; it surely
>   depends on the level of attention focused on the project.
> 
> * CVE-2015-7756 (a compromised RNG in the same firmware) was also
>   identified by internal code review[1]. I think there’s some chance
>   that this would have been fixed earlier in an open source, the use of
>   Dual EC DRBG would have been considered a red flag by anyone who had
>   been paying attention since 2006[3]. Whether the broken X9.31 PRNG
>   would have been detected or replaced at the same time is hard to say
>   though.
> 
> * If the alleged IPSec backdoor[4] ever made it into the OpenBSD tree
>   then it was never found. That would be an open source failure, but the
>   code was reviewed pretty thoroughly; it’s at least as likely, probably
>   more so, that it never existed or never got integrated into OpenBSD.
> 
> [1] https://supportportal.juniper.net/s/article/2015-12-Out-of-Cycle-Security-Bulletin-ScreenOS-Multiple-Security-issues-with-ScreenOS-CVE-2015-7755-CVE-2015-7756?language=en_US
> 
> [2] https://www.rapid7.com/blog/post/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor/
> 
> [3] http://rump2007.cr.yp.to/15-shumow.pdf
> 
> [4] https://en.wikipedia.org/wiki/OpenBSD#Alleged_backdoor
> 
>> Fuzzing seems an obvious choice, but slow.
> 
> Fuzzing can find can find certain classes of defects but isn’t likely to
> detect a cryptographically protected backdoor.
> 
> * Fuzzing would not have found CVE-2024-3094. There is no way a fuzzer
>   could have synthesized a valid Ed448 signature without the attacker’s
>   private key.
> 
> * It’s at least conceivable that CVE-2015-7755 might have been found by
>   an adaptive fuzzer of some kind.
> 
> * Fuzzing would not have found CVE-2015-7756. Superficially everything
>   worked as it should; but VPN traffic could be decrypted by someone
>   with the attacker’s private key (‘e’ in the language of [5]).
> 
> [5] https://eprint.iacr.org/2016/376.pdf
> 
>> It's understood that a deterministic solution is impossible, but it
>> would be interesting to know what approaches are practical and how
>> effective they are.
> 
> I think the most popular approach is object code analysis, probably
> build on a lot of experience of typical backdoor strategies. Search
> terms would be ‘reversing’ and ‘decompiling’.
> 

Hmm, that's a bit surprising. So it's easier to find suspicious code
by examining the compiled object files, rather than the source? 

If I'm following correctly, the only practical assurance of security
in a hardware+software situation is to home-source both. Nothing bought
 can be trusted?

If true, the proposition has substantial consequences.

Thanks for writing!

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