[pfSense] not all backdoors are NSA backdoors

[Eugen Leitl]

----- Forwarded message from Jim Thompson <jim@netgate.com> -----

Date: Sun, 13 Oct 2013 12:03:24 -0500
From: Jim Thompson <jim@netgate.com>
To: List@lists.pfsense.org
Subject: [pfSense] not all backdoors are NSA backdoors
Message-Id: <8A9B7EB1-2D12-49EE-8FE9-70D2FF25BB0A@netgate.com>
X-Mailer: Apple Mail (2.1812)
Reply-To: pfSense support and discussion <list@lists.pfsense.org>


It occurs to me that being more ‘conversational’ with the community might be a good thing.   Describing what is happening with pfSense, and why, and engaging the pfsense community in the process could be a good thing.   My first attempt is included herein.

But first, on the tail of the recent thread that erupted here, consider this backdoor that someone (?) recently (?) discovered (?) in the firmware for certain D-link routers:  http://www.devttys0.com/2013/10/reverse-engineering-a-d-link-backdoor/

If you read the article, the user agent string that bypasses authentication (according to the post) can be read backwards as 
"Edit by 04882 Joel Backdoor”.  One possible Joel is Joel Liu, Senior Director-Chief Technology Office Alpha Networks:
http://www.joesdata.com/executive/Joel_Liu_421313008.html

Alpha Networks being a spin-off of D-Link.  http://www.alphanetworks.com/_english/06_about/01_detail.php?appid=143&pid=12

They have a GPL compliance office:  http://www.alphanetworks.com/_english/10_gpl/gpl.php, but you can bet they won’t ship you >that< source code.

[Normally, if one is going to hide secret strings inside the binary, one also obfuscates them.  An example: 
http://www.codeproject.com/Articles/502283/Strings-Obfuscation-System]

...

In some respects, the recent thread was about fear of asymmetric information, that those inside ESF have information and access that the community does not.

In contract theory and economics, information asymmetry deals with the study of decisions in transactions where one party has more or better information than the other. In contrast to neo-classical economics which assumes perfect information, this is about "What We Don't Know". This creates an imbalance of power in transactions which can sometimes cause the transactions to go awry, in the worst case a kind of market failure.

Specific to the subject, the information asymmetry here is the community’s supposed inability to observe and/or verify ESF's actions.

To the best of our ability so far, pfSense is both observable and verifiable.  The source code is on github (https://github.com/pfsense/),
and the build process is quasi-documented.    Getting something like the ‘backdoor by Joel’ above into the codebase without detection
would be difficult if not impossible.   (There are more subversive means, which I touched on mid-thread, but they still fail in the presence of a public development process.)

Frankly, (between you and I), the pfSense build process could be better documented.  Truth be told: the build system for pfSense is archaic.  Nobody associated with it (at this point) likes it.  Simultaneously, everyone is afraid to replace it. “There be dragons…”

An action-item post 2.2 (and it’s move to FreeBSD 10) is to clean-up the build system, possibly making it more like that which builds FreeBSD, rather than the mess of shell (and PHP) scripts that exists now.

Having a cleaner build system could lead to better verification of the resultant bits.

Another issue is the proliferation of pfSense mirrors.   How do we (all) trust the bits on these mirrors, given that they’re run by parties entirely independent and remotely located from ESF?   One possible solution:  signed packages, and there was a bit of infrastructure put in-place just prior to the 2.1 release.  We’ve yet to accomplish the rest of this, but.. it’s coming.

As always, if you have ideas(*), bring them forward.

Jim

(*) that don’t involve re-incorporating as a non-US, non-profit company…

_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5