De Raadt Doubts Alleged Backdoors Made It Into OpenBSD

itwbennett writes "In follow-up to last week's controversy over allegations that the FBI installed a number of back doors into the encryption software used by the OpenBSD operating system, OpenBSD lead developer Theo de Raadt said on a discussion list Tuesday, that he believes that a government contracting firm that contributed code to his project 'was probably contracted to write backdoors,' which would grant secret access to encrypted communications. But that he doesn't think that any of this software made it into the OpenBSD code base."

Comments

Audit necessary

[dewarrn1]

I hope that he's right, but without a thorough audit, who can say?

Re:Audit necessary

[CAPSLOCK2000]

Even with a thorough audit you will never be sure. That's the beauty of these kinds of accusations, no matter what you do, you can never 100% sure.
OpenBSD is among the best audited code in the world. People have been looking for this backdoor specifically for an entire week and nothing fishy has been found yet.

Re:Audit necessary

[Anonymous Coward]

Well, great way to halt the actual development, right?

Remember how Microsoft accused ReactOS of copying NT code?

They spent LOTS of time auditing.

Re:Audit necessary

[Anonymous Coward]

I hope that he's right, but without a thorough audit, who can say?

It is physically impossible that a backdoor makes it past De Raadt's ego into the kernel.

Re:Audit necessary

[milonssecretsn]

OpenBSD does have an ongoing code audit

Perhaps not as thorough as you were suggesting. However, I think for others who are not familiar with OpenBSD's ongoing code audit, the above link will be essential for fully understanding these stories.

Re:Audit necessary

[Eil]

As unlikely as it is that any backdoors have made it into OpenBSD, even an audit cannot conclusively prove that there are no backdoors in the code. Witness the Underhanded C Code Contest. The goal of the contest is to write a chunk of code that does something, well, underhanded that is difficult to detect even upon close examination of the code. The winners have been quite successful. Even with only 15-20 lines of code, it's a challenge to locate the underhandedness even when you know exactly what you're looking for. The phase "microscopic needle in a galactic hacksack" comes to mind when imagining the challenge of finding malicious code that may or may not even be there, in a code base thousands or millions of lines long.

Re:Audit necessary

[mysidia]

I hope that he's right, but without a thorough audit, who can say?

The whole scare behind crypto backdoors is they can include sidechannel leakage, and they can include subtle leakage through the underlying drivers. Which can amount to elaborate timing vulnerabilities and other types of vulnerabilities intentionally introduced that are poorly understood by developers in general.

Remember... even though the crypto in the SSH protocol was perfectly sound, as you were typing a password in SSH; a timing attack could be used to assist an attacker in guessing the password typed. For example, the minute timing between keystrokes can identify some passwords that are much more likely to have been typed than others, reducing the attack required to something much easier than brute force.

You can have a backdoor without even revealing the key material or having an obvious vulnerability; all the 3 letter agencies need is a mechanism of reducing the work to crack the key to something much less than brute force. If the operation of the cryptosystem in any way makes the key easier to get than brute force, then the attacker's work is massively reduced.

In other words, it's so subtle that even a thorough audit cannot say, and a complete rewrite of the code would be required to guarantee no intentionally backdoors by the original authors (though it won't guarantee no backdoors by the new authors. and it definitely won't guarantee no subtle vulnerabilities)

It's possible can be no visible error for an audit to discover, and yet, the way the code is structured, could cause information to still be vulnerable through essentially a form of compromising virtual emissions.

Re:Audit necessary

[Anonymous Coward]

That's not the point. The point is that every discussion these days ends in "citation needed" when there are no more arguments.

The _fact_ that BSD gets audited constantly is can be found easily, it's not obscure knowledge.

But, let me give you an example why this is annoying: You say that the burden of proof lies on the guy making the bold statement. Well, is that a fact? Can you cite some references for that? How are you so sure? Then you state that OpenBSD is an irrelevant niche OS. Well, that's your opinion, I think, unless you can point to some peer-reviewed research on the matter. And I could go on.

See how you can't have a normal discussion when one party doesn't bring arguments, but only shouts "citation needed"?

Re:Audit necessary

[Chris Burke]

To me, it doesn't matter where in the implementation the bug is, since it has to be rewritten anyway for readability reasons.

Which is a fallacious viewpoint, because when you reject the patch, the author could easily recode it within the appropriate coding guidelines yet the bug would remain. In fact, you could have refactored the code yourself and yet still kept the malicious payload.

Code style is important and it's right to reject a patch with it. It's wrong to say this negates the need to actually find the bug. Which you didn't.

It also BTW would trigger another alarm in the eyes of seasoned code reviewers: in the "isdigit() == true" branch it looses the read character, printing '0' instead.

And then someone would say "No, that's the [intended, benign] purpose of the routine".

So with the style issues resolved, and the thing you thought was the bug not being a bug at all, on what basis would this "seasoned code reviewer" reject the patch? At this point the only reason is because you know it's malicious. But if you didn't, it looks like this would have passed your review.

Don't feel bad about that, though. Feel bad about thinking finding flaws in deliberately crafted malicious code is so easy when real seasoned code reviewers know it isn't.

Link to the ACTUAL FREAKING POST

[brunes69]

Since the useless summary did not include one

http://marc.info/?l=openbsd-tech&m=129296046123471&w=2

Re:Sorry, but how..?

[vbraga]

One of the problems is the lack of people with enough knowledge and time to review, for free, something as cryptographic code.

What about the law?

[DoofusOfDeath]

If the FBI did this without a court order, wouldn't they have been in breech of laws regarding attempted wiretapping and/or unauthorized computer access?

If so, have we just accepted that the FBI, CIA, and NSA break laws with impunity, and that there's nothing we can do about it?

Link directly to Theo's post

[martyros]

A link to Theo's post on the subject is much more informative.

Highlights:

• Two of the guys named in the original allegation did work on the security stack, but
• Almost certainly didn't check in any malicious code, and
• "wrote much code in many areas that we all rely on. Daily. Outside the ipsec stack."

Also:

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.

Interesting approach to security,,,

[Giant Ape Skeleton]

"I doubt it, therefore it's not true": Security through incredulity!

The Spine Defense

[Giant Ape Skeleton]

I think you must really have no spine if you except money from the FBI to backdoor crypto software.

"I needed the money to pay for my prosthetic spine!"

Yes, you are right...

[PaulBu]

"Reflections on trusting trust", by Ken Thompson:

http://cm.bell-labs.com/who/ken/trust.html

Paul B.