Updates on the OpenBSD IPsec Gossip

2010-12-15 15:22:57 by jdixon

As expected, news of a possible ten-year-old collusion to introduce backdoors in the OpenBSD IPsec stack have spread like wildfire. ArsTechnica, The Register, CNET, Forbes are among a long list of mainstream news outlets to chime in on these allegations.

Dag-Erling Smørgrav adds one point to my original commentary; that is, the action of introducing backdoor code into OpenBSD by the FBI would not fall under a "recently expired NDA", as Greg Perry claims. I think Dag is probably correct here. Even if Greg's claims are eventually proven true, something like this would more likely fall under a TOP SECRET (or even as high as TS/SCI) classification, which is typically declassified after a 25-year period. Releasing this information prematurely would land Greg in a steaming lake of hot water.

At least two of the named parties have already stepped forward to refute Greg's story. Scott Lowe posted to the openbsd-tech mailing list, stating that he does not, nor has he ever, had any affiliation or employment with the FBI or the OpenBSD project. Jason Wright followed up a short while later, demanding an apology from Greg Perry and detailing which parts of the code base he worked on during the affected period.

" I will point out that Greg did not even work at NETSEC while the OCF development was going on. Before January of 2000 Greg had left NETSEC. The timeline for my involvement with IPSec can be clearly demonstrated by looking at the revision history of:
	src/sys/dev/pci/hifn7751.c (Dec 15, 1999)
	src/sys/crypto/cryptosoft.c (March 2000)
The real work on OCF did not begin in earnest until February 2000."

I'm personally relieved to see the accused parties step up and assert their innocence. Unfortunately, the story won't end here. The mere possibility of impropriety by these developers or the FBI means the OpenBSD project will have to work long and hard to regain its tarnished reputation. A thorough code audit is the only sure-fire way (and even then, is not guaranteed) to clear these charges.

If you'd like to help with the audit, please consider matching Dag-Erling Smørgrav's triple bounty, or better yet, donating directly to the OpenBSD project.

Deconstructing the OpenBSD IPsec Rumors

2010-12-14 21:58:01 by jdixon

Theo de Raadt posted an email to the openbsd-tech mailing list Tuesday evening which contained details of alleged backdoors added to the OpenBSD IPsec code by government contractors some ten years ago. Subsequent posts from Bob Beck and Damien Miller add further commentary, but neither confirm nor deny the allegations. Damien goes so far as to propose a number of possible avenues as the most likely places to begin a new audit.

One of the purported conspirators is Jason Wright, a cryptology expert at the Idaho National Laboratory, who committed a significant amount of crypto and sparc64 code to the OpenBSD project. Although I haven't seen Jason in years, I consider "Wookie" a good friend and hope these accusations are false. If Damien's hypothesis is correct, it seems highly unlikely that Jason (or any US developers) introduced backdoors directly into the crypto code. A more likely scenario would be the malicious reuse of mbufs in the network stack.

As Brian T. Merritt suggests, it seems even more likely that Linux would be similarly "exploited". Lest we forget that while these claims against OpenBSD revolve around FBI involvement, Linux has had significant portions of its security code infiltrated by the NSA. Between these two code bases you're talking about an enormous portion of the networking infrastructure that powers the Internet.

As a former OpenBSD committer, this saddens me. Not just because of the possibility that this might be true, but that regardless of whether or not this could be true, it means that developer and community resources will be swallowed into the rumor vacuum for untold weeks and possibly months. This results in less innovation, fewer bugfixes, and worst of all, a growing distrust among everyone involved.

This story has all the characteristics of being newsworthy for a long while. It has already made major headlines across Twitter, Slashdot, Reddit and OSNews. Most articles and tweets imply that the claims are fact, without any investigation of the source claim or the actual code in question. I hope that all parties involved are cleared of any wrongdoing. Either way, the cat is out of the proverbial bag. These claims will undermine a significant portion of goodwill and trust among all Free Software / Open Source projects. In the end, nobody wins.

Where Obfuscurity Meets Negligence

2009-10-21 19:24:42 by jdixon

There are people out there who would argue that Security through Obscurity is better than no security at all. They advocate port knocking or running applications on "random" ports. Certainly, I'm not one to go around broadcasting my attack vectors to random visitors (oops!), but that doesn't mean it's a rational means of protection (honest, I'll pull out this time).

Read the rest of this story...

The Doctrine of Security

2009-08-21 23:22:36 by jdixon

Recently I had the opportunity to do an interview for a story on SMB security issues. The conversation reminded me just how easy it is, as a security professional, to paint everything in black and white. Hackers are good or evil. Software is secure or vulnerable. Vendors are responsible or stupid. But this really isn't how businesses operate.

The primary focus of most businesses is to engage in commerce. Often we overlook this basic fact when a company neglects to patch their systems and becomes a target. We argue that if the owner was serious about protecting his money, customers or data he would be more proactive. But do we have all the facts to make this judgment?

Every decision in business carries risks and rewards. Responsible patching seems like a no-brainer. Perhaps the company webserver is used for basic order submissions. No personal or private data is stored locally. Is it really harming anyone if the website gets defaced for a week until the owner's nephew stops by to reinstall it again? Certainly you could argue that the defacement reflects poorly on the business, but again we need to consider the risk vs reward scenario. If it costs less to leave a defaced server running than to call an after-hours professional, is that really a poor decision?

Don't get me wrong, this scenario would drive me nuts. And that's exactly why I'm a geek and not an accountant. On occasion we need to take our blinders off and consider the alternatives. Security is a process, not a moral standard.