Groups | Search | Server Info | Login | Register


Groups > comp.security.misc > #1544

Re: Finding backdoors

From Richard Kettlewell <invalid@invalid.invalid>
Newsgroups comp.security.misc
Subject Re: Finding backdoors
Date 2024-09-28 10:09 +0100
Organization terraraq NNTP server
Message-ID <wwvbk08uoui.fsf@LkoBDZeT.terraraq.uk> (permalink)
References <vd3uf2$7ng3$1@dont-email.me>

Show all headers | View raw


<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’.

-- 
https://www.greenend.org.uk/rjk/

Back to comp.security.misc | Previous | NextPrevious 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