Toward healthy paranoia

Some of the recent leaks have made it clear that the NSA has worked actively to insert weaknesses into both cryptographic standards and products sold by vendors. There is, for example, some evidence that the NSA has inserted weaknesses into some random-number generation standards, to the point that the US National Institute of Standards and Technology has felt the need to reopen the public comment period for the 800-90A/B/C random number standards, in which there is little confidence at this point. While no compromised commercial products have yet been named, it seems increasingly clear that such products must exist.

It is tempting to believe that the inherent protections that come with free software — open development processes and code review — can protect us from this kind of attack. And to an extent, that must be true. But it behooves us to remember just how extensively free software is used in almost every setting from deeply embedded systems to network routers to supercomputers. How can such a software system not be a target for those bent on increasing the surveillance state? Given the resources available to those who would compromise our systems, how good are our defenses?

In that context, this warning from Poul-Henning Kamp is worth reading:

Given the potential payoff from the insertion of a vulnerability into a widely used free software project, it seems inevitable that attempts have been made to do just that. And, it should be noted, the NSA is far from the only agency that would have an interest in compromising free software. There is no shortage of well-funded intelligence agencies worldwide, many of which operate with even less oversight than the NSA does. Even if the NSA has never caused the submission of a suspect patch to a free software project, some other agency almost certainly has.

Some concerns about this kind of compromise have already been expressed; see the various discussions (example) about the use of Intel's RDRAND instruction to add entropy to the kernel's pool of random data, for example (see also Linus responding to those concerns in typical Linus style). This lengthy Google+ discussion on random-number generation is worth reading; along with a lot of details on how that process works, it covers other concerns — like whether the NSA has forced companies like Red Hat to put backdoors into their Linux distributions. As people think through the implications of all that has been going on, expect a lot more questions to be raised about the security of our software.

Predicting an increased level of concern about security is easy; figuring out how to respond is rather harder. Perhaps the best advice comes from The Hitchhiker's Guide to the Galaxy: don't panic. Beyond anything else, we need to resist any temptation to engage in witch hunts. While it is entirely possible that somebody — perhaps even a trusted community figure — has deliberately inserted a vulnerability into a free software project, the simple truth remains that most bugs are simply bugs. If developers start to come under suspicion for having made a mistake, we could find ourselves driving some of our best contributors out of the community, leaving us weaker than before.

That said, we do need to start looking at our code more closely. We have a huge attack surface — everything from the kernel to libraries to network service daemons to applications like web browsers — and, with no external assistance at all, we succeed in adding far too many security bugs across that entire surface. There is clearly a market for the location and exploitation of those bugs, and there is quite a bit of evidence that governments are major buyers in that market. It is time that we got better at reviewing our code and reduced the supply of raw materials to the market for exploitable vulnerabilities.

Much of our existing code base needs to be looked at again, and quite a bit of it is past due for replacement. The OpenSSL code is an obvious target, for example; it is also widely held to be incomprehensible and unmaintainable, making auditing it for security problems that much harder. There are projects out there that are intended to replace OpenSSL (see Selene, for example), but the job is not trivial. Projects like this could really use more attention, more contributors, and more auditors.

Another challenge is the proliferation of systems running old software. Enterprise Linux distributions are at least supported with security updates, but old, undisclosed vulnerabilities can persist there for a long time. Old handsets (for values of "old" that are often less than one year) that no longer receive updates are nearly impossible to fix. Far worse, though, are the millions of old Linux-based routers. Those devices tend to be deployed and forgotten about; there is usually no mechanism for distributing updates even if the owners are aware of the need to apply them. Even projects like OpenWRT tend to ignore the security update problem. Given that spy agencies are understandably interested in attacking routers, we should really be paying more attention to the security of this kind of system.

While many in the community have long believed that a great deal of surveillance was going on, the current revelations have still proved to be shocking, and they have severely undermined trust in our communications systems. Future disclosures, including, one might predict, disclosures of activities by agencies that are in no way allied with the US, will make the problem even worse. The degree of corporate collaboration in this activity is not yet understood, but even now there is, unsurprisingly, a great deal of suspicion that closed security-relevant products may have been compromised. There is not a lot of reason to trust what vendors are saying (or not saying) about their products at this point.

This setting provides a great opportunity for free software to further establish itself as a secure alternative. The maker of a closed product can never effectively respond to suspicions about that product's integrity; free software, at least, can be inspected for vulnerabilities. But to take advantage of this opening, and, incidentally, help to make the world a more free place, we need to ensure that we have our own act together. And that may well require that we find a way to become a bit more paranoid while not wrecking the openness that makes our communities work.

Note: you can avoid this step in the future by logging into your LWN account.