OpenBSD: audits give no indication of back doors

So far, the analyses of OpenBSD's crypto and IPSec code have not provided any indication that the system contains back doors for listening to encrypted VPN connections. The OpenBSD developers started the code audit to investigate allegations made by Gregory Perry, the former CTO of crypto company NetSec. In an email to OpenBSD founder Theo de Raadt, Perry had accused developer Jason Wright and others of having built back doors into the IPSec stack. De Raadt made the email public and presented Perry's allegations for discussion.

In another email, de Raadt now writes that, while he believes that NetSec was indeed contracted to write back doors for the FBI which were distributed as "donated" code, he doesn't think such code made it into OpenBSD. De Raadt's email also attempts to clarify the roles played by the accused developers, Jason Wright and Angelos Keromytis. Both developers did apparently work for NetSec, but de Raadt states that he does not know if they were aware that the company was working for the FBI.

However, the revision control system allows auditors to verify which developers were involved in developing which code segments. According to de Raadt, Wright was mainly involved in programming drivers and didn't have anything to do with the OpenBSD Crypto Framework (OCF). However, he did apparently work on parts of the IPSec stack. In an email, Jason Wright himself has denied the accusations that he built back doors into the OpenBSD code. However, de Raadt has criticized that Wright hasn't clarified the nature of his work at NetSec.

The focus of the investigation now appears to be shifting from Wright to Angelos Keromytis who, according to de Raadt, was the architect and primary developer of OpenBSD's IPSec stack. However, Keromytis apparently only started working for NetSec at a later date. De Raadt said that during this time, the concept of insecure initialisation vectors found its way into the OpenBSD code, but that it was removed again at a later stage. While the "padding Oracle" problem allowing encrypted data to be decrypted without a key was disclosed soon afterwards, this vulnerability was reportedly fixed, at least in the crypto layer, at that time.

According to de Raadt, the developers have already found two bugs during their current audits. For instance, the (CBC) padding Oracle vulnerability in connection with initialization vectors apparently wasn't fixed in the network drivers, but this is believed to have been caused by an oversight. The other flaw is related to an instruction in a hardware driver. De Raadt also mentions a problem in the subsystem for generating random numbers, but doesn't go into detail about it.

While de Raadt's email should give the users of OpenBSD and related projects reason to relax, it doesn't mean that everything has been clarified. There are still far too many inconsistencies. Whether skilfully injected back doors can be detected during a few days of code review is also questionable. A back door such as the one recently found in the source code of ProFTPD, and containing the suspicious password "HELP ACIDBITCHEZ" (sic!), is unlikely to be used in manipulations controlled by the FBI.

How well malicious code can be hidden was aptly demonstrated in the Underhanded C Contest in 2008: For this contest, developers were asked to manipulate an image file in a way that was undetectable even when subjecting the source code to close scrutiny. The winning code submitted by a Mr. Meacham was so well-concealed that not even the event organizers were able to describe how it works – the developer had to provide the explanation later in a blog posting.

Even if it eventually turns out that OpenBSD is free of duplicate keys and back doors, the incident will leave behind a bad after-taste: in how many other open source and closed source projects have government agencies actually been successful with their manipulations?

(crve)