[SATLUG] NSA/IP stack in non-free wifi drivers?

Igor Gueths igor.gueths at rackspace.com
Wed Aug 14 09:44:44 CDT 2013

The scenarios you describe, while theoretically possible, imo are pretty 
unlikely at least for the foreseeable future; although, regardless it's 
good that these things are being discussed and considered as a matter of 
course. However, the reason they are unlikely is because in order for 
aforementioned backdoor to be successful in execution, external inbound 
access to a wirelessly-connected machine needs to be possible, which is 
disallowed in the majority of network configs by default. What could 
work in theory is a type of outbound reporting mechanism which could 
send any range of identifying data to some foreign endpoint via a 
standard or nonstandard network stack, although this would likely be 
fairly easily spotted if you were in fact suspicious of this, both by 
putting the wireless device into promiscuous mode, and capturing the 
traffic at your border router.

The same goes for the universal login password thing, although for this 
to work you'd need some persistent way to login to the machine remotely 
regardless of type of network connectivity, and or physical access to 
the machine; the latter would likely be easiest from an investigative 
standpoint. One thing I do find disconcerting though is the possibility 
of deliberately weakened random number generators being inserted into 
popular cryptography libraries; this has incidentally been done before 
at a cipher level. I don't recall the entirety of the details offhand, I 
do recall though that Bruce Schneier blogged about the details way back 
when, and iirc himself along with most of the commenters to that post 
advised against using aforementioned cipher/implementation.
On 8/13/2013 10:28 PM, Joe wrote:
> Hi All,
>       So, I may be cracking up here; but, I'm curious to see your responses
> to this.  I've been reading the Snowden stuff in the news. Apparently
> there's some renewed discussion out there about proprietary software
> containing handy back doors for the NSA to snoop on people.  A coworker
> suggested there would be a surge of linux adopters in the wake of those
> suggestions.  But, then I started to research the Linux code, and found:
> The Linux source code is around 15 million lines of code
> http://en.wikipedia.org/wiki/Linux_kernel#History
> Searching for "malicious code in Linux source"  yields a breach in 2011 and
> this from 2003
> https://freedom-to-tinker.com/blog/felten/linux-backdoor-attempt-thwarted/
> which included this malicious line
> if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>          retval = -EINVAL;
> notice the `=` used instead of an "==" .
> That error was caught.  And, i'm quite certain the Linux maintainers keep a
> close eye on the source code.  So, where else can you get nefarious code
> into the running Linux Kernel?  Ken Thompson suggested one could modify the
> source code of a compiler in such a way that the resulting modified
> compiler would insert a secret "universal" password into any code that
> called the linux logon library:  http://cm.bell-labs.com/who/ken/trust.html.
>   Some commentators on this issue suggest compiling the compiler code twice
> (each time by the newest compiler;  sort like recursion)  then doing a hash
> check, successfully proves safety.  I'm not sure i agree; seems like a
> simple if statement would prevent the re-insertion of the code in question.
>   A scary thought; but, still my feeling is that malicious code would
> ultimately get lost by attrition.  And, even it weren't, file encryption,
> firewalls, and network monitoring software would stop or expose the issue.
> Then tonight i went installing debian on an old dell.  I was prompted that
> a non-free firmware was required for my wireless device. ...  Come to think
> of 9 out 10 laptops require some non-free/closed source code for their
> wireless hardware.   Is it a coincidence that the most used network device
> on the most popular end user systems are only usable via closed source
> code?  Furthermore, the compiled size of the TCP/IP stack can be as little
> as 512kb; my firmware tonight was 14MB!  Is it possible that backdoors are
> hiding in plain sight, with 99% of end users willingly (and sometimes
> painstakingly) building that backdoor into their own kernels?  And, if,
> indeed, a nonstandard networking stack were used on top of the existing
> datalink layer, whether in series or parallel, would likely go unnoticed.
> So, what do you think?  Am I loosing it?

Igor Gueths, Rackspace Cloud Operations
Desk: +1-210-312-1952
Mobile: +1-508-685-1033

More information about the SATLUG mailing list