Security quotes of the week [LWN.net]

We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.

Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.

The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor. And while the government may argue that its use would be limited to this case, there is no way to guarantee such control.

— Apple CEO Tim Cook

And that is why source code to your infrastructure is so important. This bug just obsoleted a pile of low end crapware router and firewall boxes holding homes, businesses and government together.

— Alan Cox on the Glibc DNS lookup remote code execution vulnerability

In other words, VPNs and proxies -- which can be so crucial for persons living under oppressive governments -- are seriously bad news for those governments trying to control their freedom loving citizen slaves.

Government officials will of course argue that they're only doing what's best for the little people -- protecting them from crime, terrorism, contaminating ideas, naked breasts, and so forth.

This is why -- peering into my flickering Crystal Ball of Technology Policy -- I predict that the current relatively low level battles against VPNs, proxies, and similar censorship evasion technologies in some parts of the world will bloom into all out global war in the relatively near future with both traditionally dictatorial governments and a range of supposedly democratically-oriented governments jumping on the bandwagon -- mostly using terrorism fears as their operative excuse.

— Lauren Weinstein

to post comments

Security quotes of the week

Posted Feb 18, 2016 5:20 UTC (Thu) by dw (subscriber, #12017) [Link] (3 responses)

Apple's public resistance of the court order is the first case in our industry's history where I think anyone has successfully rallied the technical community into mass support of a feature that requires DRM. The situation wouldn't have existed if the authorities could simply reflash the firmware.

Security quotes of the week

Posted Feb 18, 2016 12:40 UTC (Thu) by robbe (guest, #16131) [Link]

If your suspect helps you unwittingly, by continuing to use her phone after you flash it (commonly called „evil maid attack“), you have a point.

But AFAIK this is not what the police wants. They could have that today by obtaining Apple’s help via a court order.

No, they want to be able to get at the plaintext even if a suspect does *not* help (because he’s dead, in prison, too smart, …). Re-flashing after the fact does not help you there. A general backdoor would.

Security quotes of the week

Posted Feb 18, 2016 15:13 UTC (Thu) by jhhaller (guest, #56103) [Link]

Of course, the other item about abandonware routers which can't be updated to fix a bug is the exact opposite issue. You can't solve one issue without making the other issue impossible. It would be better if the owner of the device was allowed to change the accepted certificate (erasing the previous encryption key), but that then leaves the key management to the device owner, most of which cannot remember passwords, let alone a 2048 bit key.

Security quotes of the week

Posted Feb 18, 2016 17:10 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> Apple's public resistance of the court order is the first case in our industry's history where I think anyone has successfully rallied the technical community into mass support of a feature that requires DRM. The situation wouldn't have existed if the authorities could simply reflash the firmware.

If they could reflash the firmware without wiping the device, you mean. It is not necessary to lock down the device to only run manufacturer-approved firmware so long as unlocking or replacing the bootloader to run other firmware prevents access to the original decryption key. The device would still be fully usable, just without the original private data protected by the key. A new key could be generated to protect the user's data while running the new firmware. A "factory reset" is not an unreasonable requirement when replacing the core OS and/or bootloader.

It is also not necessary to support remote attestation with pre-loaded hardware keys outside the user's control, which was the aspect of "trusted computing" that drew the most ire from the technical community. Without remote attestation the system cannot be used to implement effective DRM, as the TPM function can simply be emulated in software, granting the user full access to the keys.

Could Apple really build a backdoor?

Posted Feb 18, 2016 10:28 UTC (Thu) by pr1268 (guest, #24648) [Link] (4 responses)

After reading (and re-reading) our editor Jake's article from October, "Apple and the US DOJ", and especially jcm's comment (the first one on that page), I'm sincerely curious as to whether Apple could actually add on a back door to the iPhone in question.

Assuming jcm is accurate (and I've no reason not to believe him [her?]), then Apple has a way out of this mess on technical constraints. Of course, drumming up public support online like this will probably work just as well, seeing how paranoid the USA is after all the Snowden stuff, etc.

Perhaps the FBI could force the phone's owner to cough up the password, but I doubt it—the owner[s] would probably give bogus passwords until the phone bricked itself. Never mind the Fifth Amendment protection against self-incrimination.

Oh, wait—the owners were killed in the ensuing shootout. Scratch that idea.

Could Apple really build a backdoor?

Posted Feb 18, 2016 10:53 UTC (Thu) by xav (guest, #18536) [Link] (3 responses)

My thought: how could a new firmware recover a lost encryption key ? If that's the case, the backdoor is already somewhere in the phone.

Could Apple really build a backdoor?

Posted Feb 18, 2016 11:05 UTC (Thu) by neilbrown (subscriber, #359) [Link] (2 responses)

> My thought: how could a new firmware recover a lost encryption key ?

I don't think that is the idea.

The proposal is for replacement firmware to allow multiple failed unlock attempts without wiping the phone on the Nth failure (as it currently does).
I think they also want the firmware to support unlock attempts over USB or wifi or something.

The new firmware is supposed to make it less impractical to brute-force the encryption key.

Could Apple really build a backdoor?

Posted Feb 18, 2016 11:59 UTC (Thu) by pr1268 (guest, #24648) [Link]

Thanks to the xav and Neil for the above responses. However, Stack Exchange has an interesting discussion going on with regards to Apple's capability to provide the FBI with what it wants.

Could Apple really build a backdoor?

Posted Feb 18, 2016 12:32 UTC (Thu) by xav (guest, #18536) [Link]

Ah OK, I get it. And if the encryption key is derived from a simple 5 digits sequence, of course it gets trivial to bruteforce.

Security quotes of the week

Posted Feb 18, 2016 10:39 UTC (Thu) by jezuch (subscriber, #52988) [Link]

> This bug just obsoleted a pile of low end crapware router and firewall boxes holding homes, businesses and government together.

Well, good luck replacing them all now!

Security quotes of the week

Posted Feb 18, 2016 14:56 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> And that is why source code to your infrastructure is so important. This bug just obsoleted a pile of low end crapware router and firewall boxes holding homes, businesses and government together.

This bug just demonstrated the pragmatic utility of copyleft licensing in general, and the GPLv3's eeeevil anti-tivoization clauses in particular.

If you have the source code and the technical means to utilize it, it is at least possible for you to fix this problem.

If you don't have the source code and the technical means to utilize it, you are at the complete mercy of your vendor, which usually means you're SOL.

Security quotes of the week

Posted Feb 18, 2016 15:13 UTC (Thu) by viro (subscriber, #7872) [Link]

Whereas if it's hardwired into the PROM and can't be modified at all, everything is peachy and such situation should be encouraged. Got it...

Security quotes of the week

Posted Feb 18, 2016 18:06 UTC (Thu) by mitr (subscriber, #31599) [Link] (1 responses)

> If you have the source code and the technical means to utilize it, it is at least possible for you to fix this problem.

Possible, yes; how about commercially reasonable? Let’s run through a few scenarios:

In all cases, assume a “low-end crapware box“, for which the complete HW design and full source code has been published (in reality it would probably be partial, untested, unbuildable, not matching actual firmware, etc.):

Consumer device, rare:

The user needs to hire a consultant.

Just downloading the sources and setting the toolchain up to reproduce the current firmware by the consultant would probably be more expensive than buying a new $appliance for full price; actually backporting the fix would be several times more expensive still.

The availability of the source code makes little difference.

Consumer device, common:

That’s better, there may be a business performing third-party service, amortizing the cost of developing the fixed firmware over millions of boxes. Or there may even be a Free Software volunteer group providing a fixed firmware for free.

But what about installing the firmware? The box probably does have a working and tested update mechanism (unnecessary expense). So we are talking about opening up hardware not designed to be opened (the enclosure is cheaper and more reliable when there are no screws and moving parts), attaching a connector which is not USB, or something like that. Again, consultant territory, cheaper to buy a new $appliance.

The availability of the source code makes little difference.

Small business:

See Consumer device above.

Enterprise with a support contract with a competent vendor.

(A low-end, crapware box, with a support contract?!)

You have a support contract, you shouldn’t need the source code to fix things yourself. And the support contract probably only directly applies to the device when shipped with original firmware. (You perhaps may be allowed to modify it if you reproduce issues with the original firmware; but that is an additional cost to be paid, and compounded, for the lifetime of the device).

So it's more reasonable to take advantage of the support contract. Source code makes a little difference—except that it protects your future if the vendor disappears or becomes incompetent.

Enterprise, out-of-support, or incompetent support vendor

Yes, you can probably afford a consultant to use the source code, and you will benefit from it if you run into issues. Yay!

Just because we like, enjoy, or at least are willing to, tinker with firmware, does not mean that most users of “low-end crapware boxes” are able or willing to. Even if we provide a fixed firmware, most will not take advantage of that.

“Low end crapware boxes” will in practice overwhelmingly not be fixed. GPL giving users “technical means” does not really change that.

Security quotes of the week

Posted Feb 18, 2016 19:37 UTC (Thu) by pizza (subscriber, #46) [Link]

> “Low end crapware boxes” will in practice overwhelmingly not be fixed. GPL giving users “technical means” does not really change that.

The principle of user empowerment is the entire point of the GPL. It's to ensure that users have that option/right to control their own fate should they choose.

What you're saying is that since most people lack the skills to take advantage of their freedoms, we shouldn't bother ensuring those freedoms are maintained.

A freedom that's not enforced may as well not exist, and the violations will only get more flagrant if not checked.

Security quotes of the week

Posted Feb 18, 2016 22:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Ok. So suppose that your grandmother has a full source code of her router. What is she going to do with it?

Security quotes of the week

Posted Feb 18, 2016 23:15 UTC (Thu) by pizza (subscriber, #46) [Link] (8 responses)

Actually, that's pretty simple -- my grandmother will call me regardless.

And since I'm supporting her anyway, I'll make sure she uses equipment of my choosing, which means something that has source code available and consequently can run the likes of DD-WRT. Ya know, putting my money where my mouth is.

*shrug*

Security quotes of the week

Posted Feb 19, 2016 3:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> Actually, that's pretty simple -- my grandmother will call me regardless.
And you're going to exercise your right to read and fix the source code, probably spending a couple of days on setting up the build environment and then uploading the code through JTAG?

Yeah, sure.

Security quotes of the week

Posted Feb 19, 2016 3:58 UTC (Fri) by pizza (subscriber, #46) [Link]

When my grandmother calls me up and asks me to help get her connected to the internet, I'm going to exercise my right as an educated "consumer" and chose a device whose manufacturer provides proper source code. Or more likely, give her an old one that I already have lying around which is supported by the likes of DD-WRT.

As for the rest of your facetious remark, the answer is yes, I can, have, and will continue to exercise my right to obtain, read, and occasionally fix source code. Because *someone* has to actually put their money where their mouth is.

I don't begrudge someone who releases their stuff under a more permissive license; that's their prerogative. But the vast majority of my "open source" software contributions were made under the terms of the GPL (v2 and v3), and that means that the source code must be made appropriately available when binaries are distributed. Period.

That is a ludicrously easy requirement to comply with, and when the best excuse repeat violators come up with basically amounts to gross (and onging) incompetence, it stretches credulity to consider that incompetence anything other than willful, and I find it mind-boggling they are not only given the benefit of the doubt, but defended outright.

Security quotes of the week

Posted Feb 22, 2016 2:46 UTC (Mon) by malor (guest, #2973) [Link] (5 responses)

>And you're going to exercise your right to read and fix the source code, probably spending a couple of days on setting up the build environment and then uploading the code through JTAG?

With the advent of the Internet, the fact that the source code is available means that just *one person* needs to learn to do this, who can tell everyone else how, perhaps even providing images.

This is how OpenWRT and the like prosper. Just a few people really know how to build a new firmware for these routers, but that's all it takes.

It means that communities can form around hardware that manufacturers aren't interested in anymore, and keep it alive. For instance, I'm still using my Galaxy Nexus via Cyanogenmod, even though Google dropped it years and years ago.

Grandma isn't going to mess with the JTAG, but she can find people who will.

Security quotes of the week

Posted Feb 22, 2016 2:58 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> With the advent of the Internet, the fact that the source code is available means that just *one person* needs to learn to do this, who can tell everyone else how, perhaps even providing images.
But in most cases nobody bothers. There are way more cheap crapware vendors than motivated developers with lots of spare time and patience to deal with cheap crapware.

If you insist that you buy only the hardware supported by OpenWRT then you defeat your own argument. In a hypothetical universe without GPL you'd likely still be able to buy hardware with OpenFreeBSD-Wrt (oh, lookie, it actually exists: https://www.pfsense.org/ ). GPL does pretty much nothing to achieve this.

Security quotes of the week

Posted Feb 22, 2016 3:26 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

The only reason that OpenWRT exists is because Linksys were forced to release the source for GPLed components of the WRT54G. The reason most OpenWRT-compatible hardware is supported is because the vendors are willing to provide source. In a universe where Linksys had chosen FreeBSD instead, there's no guarantee that OpenWRT would exist at all.

Security quotes of the week

Posted Feb 22, 2016 3:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Has Linksys released the source code for pfSense and Moonwall firewalls?

Linksys was the first company to create a modern crapware router. So OpenWRT and DD-WRT got a headstart from it, but claiming that it's the _only_ reason for their existence is disingenuous. A router distribution is not a rocket science and eventually something would have been developed.

Moreover, OpenWRT was not even the first router distribution with user-friendly web UI. Smoothwall existed long before OpenWRT, though it had not been yet adapted for small hardware at that time.

Security quotes of the week

Posted Feb 22, 2016 3:43 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

> Linksys was the first company to create a modern crapware router. So OpenWRT and DD-WRT got a headstart from it, but claiming that it's the _only_ reason for their existence is disingenuous. A router distribution is not a rocket science and eventually something would have been developed.

Eventually something would have been developed, and it would probably have been based around significantly higher-end hardware that wasn't available in high-street stores. OpenWRT meant that there was a better than 50% chance that whatever random router you'd bought was supported by free software and would provide you with more functionality than the vendor OS. Given the effort that was involved in getting several manufacturers to release their source, it's pretty implausible that the same would be true if the ecosystem had been BSD based.

Security quotes of the week

Posted Feb 22, 2016 5:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, my stats for OpenWRT on my routers is decidedly different. I rarely could install it without at least some problems.

Meanwhile, BSD driver drives did drive developers to release source code: http://undeadly.org/cgi?action=article&sid=2006093023... (links to Kerneltrap expired, unfortunately).

Security quotes of the week

Posted Feb 22, 2016 10:39 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

Governments don't need to worry about proxies, browser people will obsolete them without prompting (evil MITM! all of them! don't bother users with approving proxies, just kill them! ad-coated cdns are the future!)

Security quotes of the week

Posted Mar 10, 2016 13:53 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

Yes, why do browser makers hate proxies with such a white-hot furious passion? Do they make it particularly harder to write browsers?

If it were just Google, then "ad-coated CDNs are the new proxies" would probably be sufficient explanation on its own, but Mozilla people seem even *more* strongly opposed for some reason.

Maybe ISPs are giving them a cut of the charge for every MB needlessly downloaded using Firefox :P

Security quotes of the week

Posted Mar 10, 2016 15:09 UTC (Thu) by raven667 (guest, #5198) [Link]

> Yes, why do browser makers hate proxies with such a white-hot furious passion? Do they make it particularly harder to write browsers?

That's probably true, proxies provide a new way for HTTP to fail when playing the telephone game between the request and the proxy and the response and the proxy, where data is munged or doesn't pass through properly, considering that many proxies are designed around the concept of the web as a document storage and retrieval system (why they have caching layers) when that matches poorly with how HTTP is used today, as an application code delivery and RPC mechanism. Doing AJAX through a proxy probably isn't much fun.