Groups | Search | Server Info | Login | Register
Groups > comp.security.misc > #1544
| 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> |
<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 | Next — Previous in thread | Next in thread | Find similar
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