[GLLUG] Am I over-reacting to this?

Mike Brodbelt mike at coruscant.org.uk
Wed Jan 15 23:47:42 UTC 2014


On 15/01/14 22:26, John Edwards wrote:
> On Wed, Jan 15, 2014 at 09:12:29PM +0000, James Courtier-Dutton wrote:
> <snip>
>> Also, Canonical have root access to all Ubuntu Linux installs. After
>> all, who compiles all the binaries, when you install Ubuntu Linux.
>
> Why pick on Canonical? The same holds true for any binary distributed
> operating system.

https://wiki.debian.org/ReproducibleBuilds

Not a silver bullet, but at least shows that the problem described is 
being taken seriously, and Debian (at least, and I believe other 
distros) are taking steps to provide provability in this arena.

> Even compiling from source does not give you 100% safety, because you
> then need to trust the C compiler (see Ken Thompson).

I'm not a huge fan of the C compiler being highlighted - Thompson's 
point AIUI wasn't just that you needed to trust the compiler, it was 
that any system is vulnerable to compromise from untrusted layers below it.

So yes, you need to trust the compiler, but also the microcode, the 
firmware, the CPU, and so on. In the light of the NSA disclosures, and 
articles like https://spritesmods.com/?art=hddhack, I believe the the C 
compiler is one of the less likely places for you to find an issue. The 
NSA and GCHQ are clearly targeting firmware/BIOS level malware that 
persists across full reinstalls, and have been busily doing this to 
network equipment.

> The key things are trust and reproducibility. Open source software can
> be easily recompiled and compared to those distributed in binary form.

Reproducibility is being worked on. Full stack trust is a *much* harder 
problem in today's ecosystem. It requires, at a minimum, a system with 
no firmware without both source and a method of verification that the 
installed binary images in flash come from that source. It's also far 
from inconceivable that the NSA would backdoor hardware by adding 
transistors or physical taps (like the modified ethernet transceivers 
that have been seen), so unless you can verify the design, and have 
confidence that the item you bought wasn't intercepted in transit and 
swapped for a compromised version, you still have a problem.

What open-source and free software can do is raise the bar on mass 
surveillance, by increasing transparency and inspectability. That would 
be a win in my book - I accept that a court ordered intercept may be 
required sometimes, I just object to the dragnet surveillance that's 
going on. Physical modifications to hardware aren't scalable in the way 
that router exploits are, as long as the manufacturers aren't colluding 
to undermine security. The economic consequences to them of being caught 
doing that are sufficiently severe that I would expect them to resist 
strongly. We're already seeing estimates of the economic damage the NSA 
has caused to Silicon Valley, and they're not small.

> Open source companies tend to have much less lock-on then others (eg
> Microsoft and Oracle) so if a backdoor is found then trust is quickly
> destroyed and they will lose most of their business.

I think commercial companies shipping proprietary code have just as much 
to lose here - they just have economic motivations rather than community 
respect.

> Bruce Schneier is currently cataloging the various backdoors used by
> the NSA on his blog at https://www.schneier.com/ and the most common
> thread is to use an exploits in a closed source OS and then use the
> closed source firmware to make it persistent.

I suspect that has more to do with the target population using mostly 
systems with a closed source OS. I'd love to believe that we're 
inherently more secure, but I'm unconvinced. I do believe that we're 
more secure than Windows, but that more due to years of bad architecture 
decisions and "bug for bug" compatibility, rather than inherent 
engineering superiority. Widespread code visibility is FOSS s/w does 
hopefully reduce the time zero-day exploits remain unpatched though.

Mike





More information about the GLLUG mailing list