Friday, December 24, 2010

It was just last week that Theo de Raadt, OpenBSD founder and developer, posted an email that claimed the Federal Bureau of Investigations paid OpenBSD developers to leave backdoors in its IPSEC network security stack.

Since then early audits have found some questionable code, contributors denied any wrongdoing, and the original source reaffirmed his allegations.

When the original post hit the mailing list December 14, journalists attempted to contact those named in the allegation.

Brian Proffitt, FOSS journalist at ITWorld, contacted two individuals by the name given in the original email as participating in the deception and received denials from both.

Another named in the email, Jason Wright, answered the posting from de Raadt saying,

Every urban lengend is made more real by the inclusion of real names, dates, and times. I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF). The code I touched during that work relates mostly to device drivers to support the framework. I don't believe I ever touched isakmpd or photurisd (userland key management programs), and I rarely touched the ipsec internals (cryptodev and cryptosoft, yes). However, I welcome an audit of everything I committed to OpenBSD's tree. I demand an apology.

Gregory Perry, original source of de Raadt's information, suggested a review of all the code committed by "Jason Wright and several other developers he worked with originating from NETSEC."

de Raadt told iTWire's Sam Varghese that "Until 2 days ago I had no idea that both Jason and Angelos (Keromytis) in the past did work for a company that does that business. And it is true, wow, that company really was in that business! Now they (the company) belong to Verizon."

Sam Varghese spoke with Perry who defended his claims saying, "I have absolutely, positively nothing to gain from making those statements to Theo, and only did so to encourage a source code audit of the OpenBSD Project based upon the expiry of my NDA with the FBI.

Being in any limelight is not my bag at all. If I had this to do over again, I would have sent an anonymous postcard to WikiLeaks."

It'll take time to go through all the code but de Raadt said "two bugs in our cryptographic code" have already been found. "We are assessing the impact. We are also assessing the 'archeological' aspects of this," he added.

No further information on the nature or significance of these bugs was given, but the scope of the allegations have far reaching implications for OpenBSD and Open Source in general.

OpenBSD is used in many commercial solutions based on its reputation of being very secure. If security risks of this magnitude are found it could undermine this long earned reputation and call into question the very concept of "many eyes." de Raadt said that the many eyes concept is very real, but the Open Source working relationship is greatly based on trust and not every commit is reviewed.

The wide sweeping effects of any deliberate security holes found in OpenBSD could very well be less trust and more review within Open Source projects across the board.

UPDATE: In further developments, de Raadt said yesterday that Angelos had worked on the cypto stack in question for four years when accepting a contract at NETSEC.

Angelos "wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on.

That crypto layer ontained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out."

de Raadt further said, "I believe that NETSEC was probably contracted to write backdoors as alleged.
If those were written, I don't believe they made it into our tree. They might have been deployed as their own product.

If such NETSEC projects exists, I don't know if Jason, Angelos or others knew or participated in such NETSEC projects."

So, it appears the original allegations that developers working on OpenBSD networking code could have worked on backdoors but there is no proof and had opportunity to add them to OpenBSD but they probably didn't. And if they did, it was probably pulled out long ago anyway. The bugs previously mentioned were not found to backdoor code.

Wednesday, December 22, 2010

A new project has produced a large and growing list of the private SSL keys that are hard-coded into many embedded devices, such as consumer home routers. The LittleBlackBox Project comprises a list of more than 2,000 private keys right now, each of which can be associated with the public key of a given router, making it a simple matter for an attacker to decrypt the traffic passing through the device.

Published by a group called /dev/ttyS0, the LittleBlackBox database of private keys gives users the ability to find the key for a specific router in several different ways, including by searching for a known public key, looking up a device's model name, manufacturer or firmware version or even giving it a network capture, from which the program will extract the device's public certificate and then find the associated private SSL key.

Craig Heffner, a member of the group who developed the project, posted a link to the database on Saturday on the Full Disclosure mailing list. Users can download the LittleBlackBox code from Google Code. The fact that encryption keys were hard-coded into many embedded devices has been known for some time, but extracting the key and then finding a router that's using it has been a challenge until now.

Recommended Reads

"Here’s where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor’s Web site and extract the SSL private key from the firmware image," the group said in a blog post accompanying the code release. "Currently LittleBlackBox has over 2,000 unique private SSL keys and growing, primarily belonging to routers and VPNs. Although at the moment the vast majority of the keys belong to various DD-WRT firmware, there are keys from Cisco, Linksys, D-Link and Netgear as well."

SSL is the default standard for encryption on the Web and is used to secure most transactions online, including e-commerce and online banking.

Friday, December 17, 2010

Ever wonder what's sucking the life out of your Linux laptop's battery or contributing to higher electric bills in the server room?

Check out Powertop, a tool for profiling a system to see what is using the most power.

Powertop was developed a few years ago to help profile systems and see what could be done to make Linux better at power savings.

It was aimed primarily at laptops, as many folks would install Linux on a laptop and then find out that battery performance was far worse under Linux than Windows.

You don't even need to run Powertop to benefit from it. Some of the most common power-gulping culprits are listed on the LessWatts.org website.

Many of these have been fixed in the upstream projects that caused unnecessary wakeups (like ntp waking up every second, or Pidgin checking every 5 seconds to check on idle time). Something as simple as a blinking cursor can cause a wake up every few seconds, and additional power consumption.

But you might want to get a look at what's going on under your system's hood specifically. Powertop should be packaged for all major Linux distros, though it might not be installed by default.

After installing Powertop, start it up as root (or using sudo) by running powertop. Now you'll see an output that's very similar to top but showing the top causes for wakeups.

It also displays the ACPI estimate for power usage; at the bottom of the output, it will show suggestions (if any) to improve power performance -- or it will notify you of processes preventing the disk from going into powersave mode.