What can the OpenBSD IPsec backdoor allegations teach us?

Recent allegations that the FBI slipped some backdoors into OpenBSD encryption software raise an important question about government involvement in security.

As of 14 December 2010, Theo de Raadt disclosed some worrisome news to the openbsd-tech mailing list:

I have received a mail regarding the early development of the OpenBSD

IPSEC stack. It is alleged that some ex-developers (and the company

they worked for) accepted US government money to put backdoors into

our network stack, in particular the IPSEC stack. Around 2000-2001.

The implications of this are shocking. OpenBSD has been widely regarded as one of the most secure operating systems in the world for years, in large part because the stated raison d'être of the project is security. The approach the OpenBSD project takes revolves around a number of identifiable policies, some more official than others, including:

  1. extensive code review to eliminate the biggest source of security problems -- vulnerabilities in software implementations
  2. simplicity of design
  3. skepticism when people try to push security snake oil and theater
  4. distrust of closed source, which can be used to hide security issues, and greater trust for open source software open to verification
  5. secure configuration by default

Practicing this set of policies has proven largely effective over the years, and there is an air of benevolent fanaticism within the OpenBSD project over adherence to principles of good, transparent security. This is why the revelation OpenBSD project leader Theo de Raadt revealed to the openbsd-tech list is so troubling and surprising. Perhaps further revelations will provide enough detail about the specific problems -- assuming they actually exist -- for us to get a better picture of why they remained undiscovered for so long.

A quick, off the cuff assessment suggests these allegations of backdoors in OpenBSD IPsec code are quite possibly truthful. The form of the announcement lends it an air of plausibility, so for the time being we would be reasonable to treat the matter as a real vulnerability in OpenBSD security. Former NETSEC CTO Gregory Perry's email to Theo de Raadt says:

My NDA with the FBI has recently expired, and I wanted to make you

aware of the fact that the FBI implemented a number of backdoors and

side channel key leaking mechanisms into the OCF, for the express

purpose of monitoring the site to site VPN encryption system

implemented by EOUSA, the parent organization to the FBI. Jason

Wright and several other developers were responsible for those

backdoors, and you would be well advised to review any and all code

commits by Wright as well as the other developers he worked with

originating from NETSEC.

Some will surely use this to make arguments against OpenBSD as a secure OS. Others will surely construct spurious arguments against the security benefits of open source software. The fact of the matter, however, is that this bolsters the argument for the security benefits of open source software, rather than undercutting it -- because the security benefits of open source software are based in large part on transparency, and we now have the benefit of knowing about the problem where a closed source software vendor would more likely have hushed it up, and perhaps even been in on the thing from the beginning. Ultimately, however, this situation should be taken as a source of lessons we can learn about securing our software, regardless of any holy wars over the security benefits of open source models of software development.

  1. Do not trust government involvement in development of secure software. Whether the software is open source or closed, the governmental motivation remains the same: monitoring the activities and secrets of members of the public. Whether you believe their intentions are good (protecting us from terrorists) or corrupt (cracking down on peaceful dissidents), the result is that government is strongly motivated to violate individual privacy -- which means compromising security technologies.
  2. Prefer simple systems over complex systems. The more complex the system, the easier it is to hide problems in plain sight, whether those problems are hidden there by accident or by malicious intent. If these problems exist, the relative complexity of IPsec implementations in general surely contributed to the continuing obscurity of the backdoor code in the system.
  3. Actively seek peer review. While opening the source is necessary to maximizing the long term security of your software, it is not sufficient on its own to doing so. Look for opportunities to entice people to review the system for potential problems, test it extensively, and contribute to a greater understanding of the potential problem areas. The greater your reputation for security and transparency, the more assiduously you should seek peer review. Ironically, it is possible that OpenBSD's reputation for security has actually encouraged relative indolence amongst those who might otherwise have tried to find security issues in its associated software.
  4. Use the simplest solution that will do what you need. This is the kind of policy that results in OpenBSD default installs having as much of its capabilities turned off as possible. It is also the kind of policy that prompts people to ensure that any GUI software is deactivated or entirely absent from server systems. What many people do not take into consideration along these lines is that sometimes they should just use simpler software. If all you need is an SSH proxy to protect your TechRepublic logins while using your laptop in a coffee shop, use an SSH proxy, and not an IPsec VPN.
  5. While there are definite security benefits to open source software development, the Unix operating system architecture, and the OpenBSD project's approach to ensuring software security, taking any of this as a practical guarantee is foolish. Software security is no place for blind faith, and there is no "most secure" OS for all purposes.

It would be a bad idea to leap to the conclusion that this means OpenBSD cannot be trusted more than many other OSes for a lot of deployments. It is still the first choice for building a firewall, for many security experts, using OpenBSD's PF. It is certainly a good idea to stop using the default IPsec stack in OpenBSD systems for the moment, though.

At least one positive outcome of this event is likely: in the future, OpenBSD attention to security reviews of source code will probably be even more rigorous than before.

On a more personal note, Perry's email to Theo de Raadt implicates a technology writer in the conspiratorial FBI activities he alleges:

This is also why several inside FBI folks have been recently

advocating the use of OpenBSD for VPN and firewalling implementations

in virtualized environments, for example Scott Lowe is a well

respected author in virtualization circles who also happens top be on

the FBI payroll, and who has also recently published several tutorials

for the use of OpenBSD VMs in enterprise VMware vSphere deployments.

The specific "Scott Lowe" to which he refers is uncertain. There are at least two such individuals -- both of whom deny such claims -- who might write about virtualization, among other topics. I have met TechRepublic's own Scott Lowe, and am inclined to believe he has not engaged in the activities Perry alleges, though of course I do not know him well enough to vouch for him personally. The fact that his writing focuses on Microsoft technologies, and to my knowledge, he has never written in favor of OpenBSD as the platform for VPN infrastructure, certainly suggests that he should not be regarded as part of the problem in this case.