Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

De Raadt Doubts Alleged Backdoors Made It Into OpenBSD

timothy posted more than 3 years ago | from the giving-away-all-our-best-tricks dept.

Open Source 136

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."

cancel ×

136 comments

Sorry! There are no comments related to the filter you selected.

Audit necessary (5, Insightful)

dewarrn1 (985887) | more than 3 years ago | (#34640146)

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

Re:Audit necessary (5, Informative)

CAPSLOCK2000 (27149) | more than 3 years ago | (#34640304)

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 (5, Interesting)

Anonymous Coward | more than 3 years ago | (#34640460)

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 (1)

dougmc (70836) | more than 3 years ago | (#34641412)

They spent LOTS of time auditing.

Looking for code taken from somewhere else is relatively simple when you have access to both sets of code -- all it takes is a program that looks for the same code in each set. (It's not trivial, mind you, but it's not terribly difficult.)

Looking for backdoors or cryptographic weaknesses (intentional or otherwise) -- that's MUCH harder.

Re:Audit necessary (3, Insightful)

drinkypoo (153816) | more than 3 years ago | (#34641596)

And while you are entirely correct, the differentiating factor between OpenBSD and basically any other operating system is that it is under continual code review for things that might cause security problems, which has famously rendered OpenBSD immune to a number of attacks to which other systems are vulnerable, including systems which started with the same common codebase. As such OpenBSD seems least likely of all possible projects which could have absorbed this code.

Re:Audit necessary (3, Insightful)

jc42 (318812) | more than 3 years ago | (#34643970)

They spent LOTS of time auditing.

Looking for code taken from somewhere else is relatively simple when you have access to both sets of code

So did MS actually show the ReactOS people the supposedly stolen code? A few years ago, when MS made similar accusations of stolen Windows code in linux, there were lots of calls for MS to tell us exactly what code they were talking about. MS simply stonewalled those requests, and continued to make vague, non-specific public accusations that couldn't be validated. It was widely understood to be a marketing ploy, to put the fear of Microsoft's lawyers into potential linux customers' minds.

If a company is serious about infringements, the laws generally require that the accusers state explicitly what is being infringed where, and give the culprits a chance to remove the offending infringement. An accusation without the specifics is legally worthless, since nobody can stop doing something if they don't know what the something is.

There was also the suspicion that, if there was common code in both OSs, it was because MS "stole" the publicly-published linux code rather than the other way around. But, while that's more credible (due to the difficulty in getting a copy of MS's source code), it's a different story than we're talking about here.

There was at least one bit of humor in the "linux stole from Windows" story. At one point, a MS rep mentioned a line count for the stolen code. Someone did a count, and said that the number matched the number of "/*" and "*/" lines in the linux kernel source. This might sound frivolous, but it goes along with the famous story of the Sys/V version of /bin/true, which was a shell script consisting solely of a blank line and an AT&T copyright notice. MS claiming copyright ownership of comment delimiters would be roughly similar to AT&T claiming copyright ownership of a blank line.

Re:Audit necessary (0)

Anonymous Coward | more than 3 years ago | (#34642304)

I might be wrong, but IIRC Microsoft didn't accuse them.. they caught someone in the fact of using leaked Windows sources to implement ReactOS functionality, and rightly stopped themselves to audit and cleanup, to avoid future possible (and probable) accusations. Beside, the copied code existed and they removed it.

The code doesn't even have to be in the source (3, Interesting)

brokeninside (34168) | more than 3 years ago | (#34640862)

If they can get a backdoor built into the compiler used to build the binaries for the general releases, the backdoor doesn't have to be anywhere in the source.

So, yeah, an audit isn't foolproof.

Re:The code doesn't even have to be in the source (1)

SwedishPenguin (1035756) | more than 3 years ago | (#34641284)

So audit the compiler. ;) And then audit the compiler that compiled the compiler. In the end I suppose you need to build a compiler by hand to make sure no backdoors are present.

Re:The code doesn't even have to be in the source (1)

firewrought (36952) | more than 3 years ago | (#34643180)

In the end I suppose you need to build a compiler by hand to make sure no backdoors are present.

In the end, you'd have to build the computer and all it's components by hand, at least from the standpoint of Thompson's "Reflections on Trusting Trust".

Re:The code doesn't even have to be in the source (1)

Unequivocal (155957) | more than 3 years ago | (#34643332)

Can't you just compare your compiler binary with a known good source? If they're different and they should be the same then the warning bells go off. And it seems like borrowing a gc binary from someplace far away from your codebase and toolchain and trusted ought to be a simple way to boot strap back into safe territory?

Re:The code doesn't even have to be in the source (1)

mysidia (191772) | more than 3 years ago | (#34641334)

If they can get a backdoor built into the compiler used to build the binaries for the general releases, the backdoor doesn't have to be anywhere in the source.

This is why they should rebuild the compiler from source for every release, and make sure to publish the source code to that compiler, as well as the low-level code used to bootstrap that compiler, and always use a boot CD from the previous release to verify that the bootstrap compiler binary has not changed from the original version.

The initial bootstrap for the system compiler is the real problem -- a backdoor hidden there could propagate itself into all binaries generated by it.

And since it basically has to be written in machine language, whether the binary bootstrap is an assembler or lightweight C compiler, it is the perfect place to hide code.

Re:The code doesn't even have to be in the source (1)

Minwee (522556) | more than 3 years ago | (#34643292)

This is why they should rebuild the compiler from source for every release, and make sure to publish the source code to that compiler,

Okay then. What should they use to rebuild the compiler? Do they need to rebuild the compiler compiler? And what happens if the compiler compiler compiler compiler compiler has been compromised?

It's turtles all the way down.

Re:The code doesn't even have to be in the source (1)

mysidia (191772) | more than 3 years ago | (#34643492)

Okay then. What should they use to rebuild the compiler?

This is called the 'bootstrap'. A couple pieces of software written in machine language whose sole purpose is to compile the compiler.

The alternative is to hand-compile the compiler, by having a human read off the source code and manually translate by hand each function into machine language. A very time consuming process, and only feasible with fairly simple compilers.

However, you can use a very simple compiler to compile a more complex compiler.

For example, you can write your C compiler in a subset of C that can be compiled by a more primitive compiler.

Re:Audit necessary (1, Flamebait)

e065c8515d206cb0e190 (1785896) | more than 3 years ago | (#34641444)

OpenBSD is among the best audited code in the world.

Citation needed. I'm not necessarily thinking the opposite, but is OpenBSD really that much audited? Are we talking about the kernel? The network stack? Or the encryption protocols?

Re:Audit necessary (1)

Anonymous Coward | more than 3 years ago | (#34641514)

Do your own goddamn research, you lazy git. Stop shouting "citation needed". It wasn't funny when XKCD did it, and it got stale fast.

Re:Audit necessary (0)

Anonymous Coward | more than 3 years ago | (#34642172)

Uh, hello?
The burden of proof lies on the guy making bold statement. OpenBSD is an irrelevant niche OS, why should it be among the best audited code in the world? Just because a few nerds keep repeating that meme? Not really convincing.

Re:Audit necessary (4, Insightful)

Anonymous Coward | more than 3 years ago | (#34642664)

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 (0)

Anonymous Coward | more than 3 years ago | (#34642504)

Citation needed.

Re:Audit necessary (1)

Nadaka (224565) | more than 3 years ago | (#34642878)

If you know who is suspect and have good version control, you can use identify any changes that they made and start looking for problems there. It won't be 100% sure because they there is always a possibility that you don't suspect the right people.

Re:Audit necessary (1)

DaMattster (977781) | more than 3 years ago | (#34642934)

True, you cannot be 100% sure but you are almost guaranteed to be safer using OpenBSD to secure your systems than any other operating system. Imagine using Windows to secure your infrastructure. I am not stupid enough to do that. Even Cisco and Linux have been compromised but it is much, much harder. Despite these allegations, I would throw an OpenBSD box to protect my infrastructure any day.

Re:Audit necessary (5, Funny)

Anonymous Coward | more than 3 years ago | (#34640496)

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 (5, Informative)

milonssecretsn (1392667) | more than 3 years ago | (#34640544)

OpenBSD does have an ongoing code audit [openbsd.org]

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 (4, Insightful)

Eil (82413) | more than 3 years ago | (#34640658)

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 [xcott.com] . 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 (3, Interesting)

ThePhilips (752041) | more than 3 years ago | (#34641212)

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.

First two examples on the front page haven't passed even through my shallow code review.

The third sample failed at readability (ambiguous operator precedence) and I would have immediately subjected it to re-factoring.

It is not that difficult to detect the problems.

My first, the most generic rule of code review: code works much like the way it looks. And I know for a fact that OpenBSD folks use that rule too.

P.S. The 3 samples I looked at are the winners from the year 2008.

Re:Audit necessary (2)

Rhaban (987410) | more than 3 years ago | (#34642130)

The third sample failed at readability (ambiguous operator precedence) and I would have immediately subjected it to re-factoring.

The operator precedence have nothing to do with the maliciousness of the code (if the third sample is the code from John Meacham). This part could have been refactored any way you'd like, the exploit is in the algorithm itself.

Re:Audit necessary (1, Interesting)

ThePhilips (752041) | more than 3 years ago | (#34642654)

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

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.

Re:Audit necessary (1)

Anonymous Coward | more than 3 years ago | (#34642942)

It's SUPPOSED to lose the character. The whole point is to censor an image, and it does that by replacing the to-be-censored region with black pixels (value 0). The evil part is the information it leaves behind the resulting image. I don't think you understand how it works.

Re:Audit necessary (4, Insightful)

Chris Burke (6130) | more than 3 years ago | (#34643246)

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.

Re:Audit necessary (1)

Anonymous Coward | more than 3 years ago | (#34643296)

"seasoned" code reviewers who can't understand what the program is supposed to do in the first place? You are overestimating your competence.

It's supposed to write a '0'! The sneaky bit is it writes extra zeroes depending on what is being "censored".

Good luck with a rewrite when your resulting program has better readability but doesn't even work.

See: http://underhanded.xcott.com/?p=8 [xcott.com]

The object of this year's contest: write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out

Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.

The removed pixels don't have to be perfectly reconstructable; if a very faint signal remains, that's often good enough for redacted document scans. Indeed, an attacker may know that a redacted block might be one of two words, and any tiny bit of leakage that helps her determine which is more likely is technically a valid attack. However, more points are given for greater pixel leakage.

And the PPM format: http://netpbm.sourceforge.net/doc/ppm.html [sourceforge.net]

Re:Audit necessary (0)

Anonymous Coward | more than 3 years ago | (#34643720)

I agree, these submissions are lame. (Spoiler alert: I will talk about them.)

The first example is a WTF for using a boolean expression as a bit shift operand. I noticed this as weird before I noticed the lack of parenthesis. If I saw this in some code I was working on I would rewrite it to something more readable.

The second example is a WTF because it hard codes buffer sizes that are separate from the declaration of the array. It also formats an error message before the assertion has failed. If I saw this in a code base I was working on, I would rewrite this to do the formatting inside the if block, declaring the array there and using sizeof() instead of this gibberish.

The third example is totally unreadable code that I don't want to even bother analyzing. If I were auditing code I would figure out what it's doing and rewrite it.

All of these would be sore thumbs in a code review. Getting this into production code would have to rely on your co-contributors being nitwits.

Re:Audit necessary (1)

jhol13 (1087781) | more than 3 years ago | (#34643724)

I call bullshit.

I am certain that a few thousand lines of code like that, which is about average of C I have seen during last ~20 years, it would pass your audit.

There is exactly zero change that you would fix every single missing parenthesis.
Besides, as pointed out, the missing parentheses has nothing to do with the problem.

Re:Audit necessary (1)

Abcd1234 (188840) | more than 3 years ago | (#34642786)

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.

Except, of course, they know who these contributors were, and they have a source control system. Scrutinizing their changes would be trivial.

Of course, it's always possible they worked through third-party intermediates, or broke into the SCM, but if that's the case, the OpenBSD team has far bigger problems, IMO.

Re:Audit necessary (5, Insightful)

mysidia (191772) | more than 3 years ago | (#34641108)

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 (1)

Ecks (52930) | more than 3 years ago | (#34642210)

Anyone using ssh to it's maximum security potential isn't sending a password across the channel more than once. On new systems I use some variation of the following to push my key onto the remote system.

$ ssh-add
$ ssh -A myUser@remoteSystem "ssh-add -L >> ~/.ssh/authorized_keys; chmod 644 ~/.ssh/authorized_keys"

Anyone using ssh with passwords would do well to read up on public key authentication in ssh.

-- Ecks

Re:Audit necessary (2)

toofishes (1096147) | more than 3 years ago | (#34643384)

$ man ssh-copy-id

Re:Audit necessary (1)

lysdexia (897) | more than 3 years ago | (#34642540)

From TFA:

Since Perry's allegations were made public, developers have found two new bugs in OpenBSD, but de Raadt said Tuesday that he thinks that neither of them is a back door.

In fact, de Raadt seems to think that the whole incident has helped OpenBSD. "I am happy that people are taking the opportunity to audit an important part of the tree which many had assumed -- for far too long -- to be safe as it is," he said.

Strange how much fuss... (1)

gmelis (1501569) | more than 3 years ago | (#34640166)

...can be made over something so obvious. OpenBSD's code has been screened again and again. If something was amiss somebody would have noticed it. Even now that such allegations have been made, anybody could go over the code and check for such backdoors. Yet nothing has been reported yet. What the f..k. I'll continue putting my trust on OpenBSD for security in data communication.

Re:Strange how much fuss... (3, Interesting)

tomz16 (992375) | more than 3 years ago | (#34640240)

...can be made over something so obvious. OpenBSD's code has been screened again and again. If something was amiss somebody would have noticed it . . .

Yeah just look for the parts commented //super secret FBI backdoor, shhh!

You obviously have not seen things like this http://underhanded.xcott.com/ [xcott.com]

Re:Strange how much fuss... (-1)

Anonymous Coward | more than 3 years ago | (#34640974)

This isn't Linux. The standards for getting code accepted into OpenBSD are quite a bit higher...

Re:Strange how much fuss... (-1, Redundant)

ThePhilips (752041) | more than 3 years ago | (#34641278)

You obviously have not seen things like this http://underhanded.xcott.com/ [xcott.com]

I have just seen them, and they all fail simple shallow code review or code readability test.

Re:Strange how much fuss... (0)

Anonymous Coward | more than 3 years ago | (#34643688)

Not your code review..

Posters above just pointed out how you didn't even understand the point of the code, yet you don't admit your mistakes?

Re:Strange how much fuss... (1)

Minwee (522556) | more than 3 years ago | (#34643692)

Well, if you have a few minutes I think that Theo deRaadt has a few lines of code [openbsd.org] that could use your expert review.

Re:Strange how much fuss... (3, Insightful)

bejiitas_wrath (825021) | more than 3 years ago | (#34640248)

The OpenBSD source as is known is the best for security as everything is screened and checked, this would have been discovered in that process. Microsoft, who checks their source? They could have any backdoors installed and how would you know? The Open Source way is the best way.

Re:Strange how much fuss... (-1)

Anonymous Coward | more than 3 years ago | (#34643802)

OpenBSD code is audited by OpenBSD developpers. Microsoft Code is audited by Microsoft developpers.

So who do you trust, the guys to whom you gave money to have their OS or the guys you've took their product for free?

Re:Strange how much fuss... (1)

Galactic Dominator (944134) | more than 3 years ago | (#34643950)

Microsoft Code is audited by Microsoft developpers.

How do you know?

So who do you trust, the guys to whom you gave money to have their OS or the guys you've took their product for free?

I'll take the commit logs and src history can review.

The Windows religion requires faith that comprehensive audits are done. Give money and hope you get returns.

The science of open source allows you to verify for yourself provided you have the skill and time. There is still cost involved with the use of such products, but it's at least fully accountable.

Lose that misconception, please (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34640280)

First, most "open source" code is written by employees working for a corporation.

Second, nobody reviews it outside a very small number of people. It's easy to miss things like well-hidden back doors. And that's not even getting into the politics of open source review and the insular cliques of developers - just try and get anyone to listen to you when you start saying you found a back door.

Third, it's cryptographic code. There are probably an uncountable number of "back doors" that could be incorporated into the code that would get by almost all very experienced and very good cryptographic programmers. Just write the code in such a way that you remove a little bit of randomness. Hell, maybe you can write what looks like perfect code but rely on a quirky compiler optimization to do your work for you. It won't matter how many times you screen the source code for something like that. And how many good, experienced cryptographic coders spend their spare time reviewing BSD code in detail anyway?

Re:Strange how much fuss... (1)

Anonymous Coward | more than 3 years ago | (#34640368)

There are already admissions made by Theo and others that there *are* some security problems with the code in question, which have been addressed with commits on 12/15 and 12/16 of this year. Whether or not these are the "backdoors" originally referred to is unknown. Here's validation of my statement -- read the entire post from De Raadt, as it includes admissions as well as the commits themselves. And don't forget to read the very last paragraph of his post too.

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

Does this mean OpenBSD is insecure? No, but it does mean that the "fuss" you refer to has actually brought to light things that were in fact missed in the past. Draw your own conclusions from that.

And de Raadt is ALWAYS rational. (-1)

Anonymous Coward | more than 3 years ago | (#34640184)

Always.

He thinks? (0)

Anonymous Coward | more than 3 years ago | (#34640268)

Well, I think I'll wait until he knows.

Re:He thinks? (2)

pete_norm (150498) | more than 3 years ago | (#34642104)

Until then, refrain from using any other programs and operating systems because the best anyone can say is that they think their code is secure.

Re:He thinks? (1)

Anonymous Coward | more than 3 years ago | (#34642250)

You'll "wait"? You're going to stop using IPSEC until it's all been re-audited?

Sorry, but how..? (0)

bhunachchicken (834243) | more than 3 years ago | (#34640350)

Please pardon my likely sheer ignorance (or even misunderstanding) on this topic, but how is it possible for someone to code a backdoor into encryption software in an open source project..? I mean, wouldn't someone notice..? Isn't that like someone just making another entrance to your house and then painting it over to match the brickwork..?

Unless, of course, all code is accepted in general good faith and there are very few eyes that are looking at this sort of thing.

Or it's open source code talking to closed source drivers, or something..?

Re:Sorry, but how..? (-1)

Anonymous Coward | more than 3 years ago | (#34640424)

Please pardon my likely sheer ignorance (or even misunderstanding) on this topic, but how is it possible for someone to code a backdoor into encryption software in an open source project..? I mean, wouldn't someone notice..?

Assuming other people are reviewing the code, there's still the possibility of subtle, deliberate bugs. A number of examples can be found in the Underhanded C Contest [xcott.com] .

Re:Sorry, but how..? (1)

AccUser (191555) | more than 3 years ago | (#34640428)

The backdoor in question might simply be a guaranteed or determinable byte-sequence in a stream, which could aid in the decoding of said stream. It need not be a simple --with-backdoor option passed on the command line... ;)

Re:Sorry, but how..? (1)

0123456 (636235) | more than 3 years ago | (#34641326)

The backdoor in question might simply be a guaranteed or determinable byte-sequence in a stream, which could aid in the decoding of said stream. It need not be a simple --with-backdoor option passed on the command line... ;)

Except the output of the IPSEC stack has to interoperate with other IPSEC stacks. IPSEC basically takes TCP/IP data, encrypts it and sticks on some headers.... if it doesn't do that the correct way then it's not going to be able to talk to machines using a different stack. Even if it only corrupts a small number of packets, someone's eventually likely to notice that some are getting dropped.

Certainly it could generate poor random keys, or somehow leak private key bits into the key or random padding so that the other end of the connection could extract them. But creating a hole that would allow a third party to easily tap into IPSEC while remaining interoperable and not being obvious wouldn't be easy... of course that means that if it existed it wouldn't be easy to find either.

Re:Sorry, but how..? (4, Insightful)

vbraga (228124) | more than 3 years ago | (#34640430)

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

Re:Sorry, but how..? (1)

Knuckles (8964) | more than 3 years ago | (#34640440)

Bugs are often not obvious. As someone else pointed out above, the code may even look perfectly fine but can still exploit compiler quirks. Also, look at at http://www.ioccc.org/ [ioccc.org]

Re:Sorry, but how..? (1)

martyros (588782) | more than 3 years ago | (#34640466)

Isn't that like someone just making another entrance to your house and then painting it over to match the brickwork..?

Check out the Underhanded C Contest [xcott.com] . Sure, a patch containing, "if(packet_csum=SEKRUT_FBI_BACKD00R_P4KT) { /* d0 3v1Lz */ }" would get noticed pretty quickly. But good security is really subtle; it's probably difficult, but not impossible, to make proper-looking code that actually screws up in just the right places. The main problem is that anything that subtle is as likely to get broken accidentally as well.

Re:Sorry, but how..? (0)

ThePhilips (752041) | more than 3 years ago | (#34641322)

Check out the Underhanded C Contest

I have checked it and yes all the code there has trivial coding bugs which are very easy to spot to professional coders.

Re:Sorry, but how..? (2)

TheRaven64 (641858) | more than 3 years ago | (#34642098)

Not to mention the fact that most of the bugs are hidden in idioms that OpenBSD's style(7) explicitly prohibit. These would be refactored before being committed, and the hidden bugs would probably be fixed without anyone noticing that they were there...

Re:Sorry, but how..? (0)

Anonymous Coward | more than 3 years ago | (#34642316)

Hurrah, we're saved!!! ThePhilips can review the OpenBSD code in a matter of hours, with one hand tied behind his back, while riding a horse, barebacked, and handily certify everything with 100% certainty.

Dork.

Re:Sorry, but how..? (1)

Anonymous Coward | more than 3 years ago | (#34640500)

Please pardon my likely sheer ignorance (or even misunderstanding) on this topic, but how is it possible for someone to code a backdoor into encryption software in an open source project..? I mean, wouldn't someone notice..?

Like how everyone saw the UnrealIRCD trojan [linux.com] as soon as it was inserted in the source? Oh wait...

Re:Sorry, but how..? (1)

m50d (797211) | more than 3 years ago | (#34642700)

You mean the one that wasn't actually inserted into the source, but rather the binary was replaced on their server? The one that could never have happened on a system that uses signed packages (as I believe Debian does by default now)?

Re:Sorry, but how..? (0)

Anonymous Coward | more than 3 years ago | (#34640586)

Read this for an idea, someone hacked in some well crafted code that appeared innocent, had the machine not been hacked it probably would have stayed
http://kerneltrap.org/node/1584

Re:Sorry, but how..? (3, Informative)

0123456 (636235) | more than 3 years ago | (#34641206)

Read this for an idea, someone hacked in some well crafted code that appeared innocent, had the machine not been hacked it probably would have stayed

That code is neither innocent nor well-crafted. Setting uid to zero is not 'innocent' and using '&& (x = 0)' is not well-crafted since it will always evaluate to false. I don't know whether the compiler will generate a warning in that case, but it should, and while a brief look through the code might miss that it's using = instead of ==, any kind of code review worthy of the name would spot it and flame the developer who wrote it.

Re:Sorry, but how..? (1)

gsslay (807818) | more than 3 years ago | (#34640608)

Step 1. Contribute lots of shoddy obfuscated code that no-one will follow without a lot of effort. Comment code minimally with suggestions that what it's doing is so obvious to anyone who knows anything, it's hardly worth mentioning

Step 2. Conceal deep in your shoddy obfuscated code your backdoor. Do not call it Back_door_func.

Step 3. As long as your code works no-one will touch it or try to pick it apart. Hope no other coder is brave enough to suggests your code is beyond all understanding.

Re:Sorry, but how..? (1)

johneee (626549) | more than 3 years ago | (#34640674)

Except that with a project as high profile as OpenBSD, code that shoddy would never be accepted.

I hope.

Right? Anyone?

Re:Sorry, but how..? (0)

Anonymous Coward | more than 3 years ago | (#34640756)

Except that with a project as high profile as OpenBSD, code that shoddy would never be accepted.

I hope.

Right? Anyone?

Ever look at SSH source code? It really fits the GP's description:

obfuscated code that no-one will follow without a lot of effort. Comment code minimally with suggestions that what it's doing is so obvious to anyone who knows anything, it's hardly worth mentioning

Re:Sorry, but how..? (1)

arivanov (12034) | more than 3 years ago | (#34642708)

Every commit needs to be signed off by at least several more people as far as I know and a lot of commits to key parts need to be signed off by Mr Ego himself till this day.

Obfuscated? Shoddy? Forget that.

The same is the story with all BSDs. They can be used as a textbook on how to write code and in a lot of places you do not even need the (otherwise excellent) documentation to determine what is going on. It is just readable (TM).

Re:Sorry, but how..? (0)

Anonymous Coward | more than 3 years ago | (#34642712)

According to this [openbsd.org] , yes.

Re:Sorry, but how..? (0)

Anonymous Coward | more than 3 years ago | (#34640634)

Putting in a deliberate bug that the developer can use as an exploit. The code will look fine, but an off by one looping error can lead to stack-smashing or nop-sleds. Under normal conditions the bug doesn't show up, but feed it the wrong data and you have a backdoor when the code goes wobbly.

Re:Sorry, but how..? (1)

Andy Dodd (701) | more than 3 years ago | (#34641244)

The original email sort of gave hints to this, referencing side channel/key leaking vulnerabilities. Side channel attacks can be VERY esoteric and difficult to identify - Look at Adi Shamir's work with abusing the Pentium 4's HyperThreading implementation.

However, I believe within the first days of the audit, some of the code contributions from Netsec appeared to, if anything, be an attempt at eliminating a potential timing-based side channel attack.

Honestly, I still can't figure out why Theo even believes that this company might have been contracted. It would be basically impossible for the FBI to contract out an organization to backdoor the FBI's parent organization's communications system as claimed - you'd have to have some VERY creative accounting to be able to hide that from the parent organization, and if there were even the slightest bit of truth to Perry's claims, you can bet there's a massive political shitstorm going on within the DOJ over this.

Link to the ACTUAL FREAKING POST (4, Informative)

brunes69 (86786) | more than 3 years ago | (#34640360)

Since the useless summary did not include one

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

Re:Link to the ACTUAL FREAKING POST (0)

Anonymous Coward | more than 3 years ago | (#34640406)

Thats what you get when publications mass submit all their day's stories to /.

You can trust the government (2, Funny)

C_amiga_fan (1960858) | more than 3 years ago | (#34640370)

Don't know why everyone's so concerned? If the FBI put backdoors into BSD or any other operating system, then it's for a good purpose - to protect us. "Sure there are some problem but they are doing the best they can, and we should not criticize them." - B5 chick

Re:You can trust the government (1)

cpu6502 (1960974) | more than 3 years ago | (#34640410)

I sincerely hope that was sarcasm.

Sad thing is I know an Art Teacher just like that. "Stop criticizing the cops." And I reply, "But the video shows them beating a citizen who had done nothing wrong (just walking his dog)." "I'm sure if the cops were beating him, they had a justified reason to do so." "....."

Anyway the FBI should not be spying on us via backdoors in our OSes (or phones or thermostats or cars) - it violates the LEGAL requirement to obtain a search warrant from a judge.

Re:You can trust the government (0)

Anonymous Coward | more than 3 years ago | (#34643468)

Sad thing is I know an Art Teacher just like that. "Stop criticizing the cops." And I reply, "But the video shows them beating a citizen who had done nothing wrong (just walking his dog)."

Rational person's response: "I guess that shows those particular cops were a bunch of assholes. I'm sure there's many, many more who actually do their jobs right and protect the people. Let's do something about those few assholes, then."

Paranoid persecution complex Slashdot basement dweller: "See? SEE?!? That proves it right there! They're ALL out to get us! You can't trust none of those DIRTY COPS! Just like that one DIRTY COP who pulled me over once because I didn't believe in their IMAGINARY RULES! OH MY GOD TEH WAR HAS BEGUN MY BROTHERS AND SISTERS. We can take back our country from these people who stole it from us I have my rights my guns I ammo cops mrmmmrm *trails off*" *hides shaking in makeshift bunker with guns, ammo, and beef jerky, shooting at anything that comes within visible range of the bunker's window, uneasily humming tuneless rebellion songs to pass the time*

What about the law? (4, Insightful)

DoofusOfDeath (636671) | more than 3 years ago | (#34640444)

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?

Re:What about the law? (1)

morgauxo (974071) | more than 3 years ago | (#34640762)

Yup. Pretty much. Welcome to Ameika! It's been that way at least since Hoover and it's only getting worse.

I'm not a lawyer (1)

brokeninside (34168) | more than 3 years ago | (#34640876)

But I think it would only be against the law for law enforcement to use such backdoors. I don't know that any existing law prohibits law enforcement agencies from the creation of such backdoors for possible future use.

Re:I'm not a lawyer (1)

DaMattster (977781) | more than 3 years ago | (#34642880)

Well, it shows that you are not a lawyer because the DoJ can invoke a national security interests clause to be able to utilize these back doors. It is legal but very, very shady and unethical.

Re:What about the law? (1)

Andy Dodd (701) | more than 3 years ago | (#34641364)

Even more difficult to believe, the claim is they did it in order to spy on another organization within the DOJ.

Legal or not, any truth to this would have ignited a political shitstorm within the DOJ.

Also note: If there were anything possibly illegal about this, the fact that the alleged target organization of the backdooring (EOUSA) is FULL OF LAWYERS, you can bet someone would've been torn a new legal asshole over this.

Re:What about the law? (0)

Anonymous Coward | more than 3 years ago | (#34642336)

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?

Considering that the FBI is itself an illegal organization (no such authority for any domestic law enforcement exists in the Constitution except perhaps for investigation of counterfeiting or piracy on the high seas, the former of which is done by the secret service and the latter of which is a function of the Navy), it's silly to be shocked that the illegal organization is doing something illegal.

Why be concerned about little crimes when the big ones are embraced by the vast majority of the people?

(Note that there may indeed be a legitimate role for something like the FBI. But if it is legitimate, the only legal and proper way to create such an organization and fund it with federal dollars would be a Constitutional amendment).

Re:What about the law? (2)

DragonWriter (970822) | more than 3 years ago | (#34643706)

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?

Probably not; AFAIK -- even assuming wiretapping laws would apply -- there is no law prohibiting the FBI from contracting others to build in a capacity that could be used for wiretapping. The only time they would need a warrant is to actually make use of the facility.

Link directly to Theo's post (4, Informative)

martyros (588782) | more than 3 years ago | (#34640510)

A link to Theo's post [marc.info] 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,,, (4, Funny)

Giant Ape Skeleton (638834) | more than 3 years ago | (#34640572)

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

Plankton, scum, etc. (0)

Anonymous Coward | more than 3 years ago | (#34640702)

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

The Spine Defense (5, Funny)

Giant Ape Skeleton (638834) | more than 3 years ago | (#34640798)

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!"

You get what you pay for. (3, Insightful)

Dcnjoe60 (682885) | more than 3 years ago | (#34640958)

Hah, that's just like the government contractor -- write a backdoor into a system that doesn't actually work. Since the so called announcement, and the source being available. If this back door were true, wouldn't there be a patch issued for it?

Personally, I think that the leak got it wrong, it's not about making OpenBSD insecure, it was to openly create the BSoD in another well known operating system.

Re:You get what you pay for. (2)

0123456 (636235) | more than 3 years ago | (#34641222)

Hah, that's just like the government contractor -- write a backdoor into a system that doesn't actually work.

Does this mean that the government can demand their money back?

Thank goodness for BSD and Theo (0)

Anonymous Coward | more than 3 years ago | (#34641128)

If we didn't have the BSDs, trust would be much harder to achieve

thank god for community-minded ethical coders

proving, once again, that not everyone is evil

Yeah, right... (2)

curious.corn (167387) | more than 3 years ago | (#34641712)

Backdoors, who needs backdoors?

Forgetting to close an attack vulnerability on all but the software encryption implementation is a much more dramatic and questionable error. Anyone that has taken the trouble to add hardware acceleration to their encryption stands a good chance to have something to protect from undesired access.

But, by doing so they have exposed themselves to the vulnerability itself. Brilliant!

Thoughts (2)

DaMattster (977781) | more than 3 years ago | (#34642150)

FUD is already getting spread around about OpenBSD, see the following article from Linux Journal, "Allegations of OpenBSD back doors may be true" [bit.ly] This came as a comment from within the article. The journalist rambles on about far reaching impacts and doomsday scenario for the project. Okay, reality check. If backdoors are found, (a) Theo and company immediately release patches closing the back doors and (b) the FBI would get another black eye for being caught in a major public lie. Far reaching, my ass. In the end, the only changes made will be to close off core commit privileges to all US-based, OpenBSD contributers. Only certain trusted individuals will have core commit privileges. Say what you want about Theo, the man sticks to his principles like cement. Even if back doors are found, I'll still continue to trust OpenBSD as the most secure OS in the world. Why? For every security hole in OpenBSD found, I'll bet that there are several hundred in other operating systems. A 1/~250 ratio is not bad at all!

Re:Thoughts (2)

durdur (252098) | more than 3 years ago | (#34642952)

Certainly OpenBSD has a good track record and finding and fixing security flaws. But in this case, I wouldn't assume the flaw, if any, can be found quickly and fixed. The post alleging it was certainly not very detailed about it.

I don't know man but (1)

Provocateur (133110) | more than 3 years ago | (#34642602)

was there someone behind him showing today's newspaper headlines when he made the statement? We just want to make sure...

cryptome.org (0)

Anonymous Coward | more than 3 years ago | (#34642754)

some more details from cryptome [cryptome.org]

Code.. Schmode! (0)

Anonymous Coward | more than 3 years ago | (#34643736)

Sniff your network. Make sure your hardware doesn't suffer from anal leakage. And don't forget to put the building into a Faraday cage.

Suspicious timing (1)

Daedalon (848458) | more than 3 years ago | (#34644046)

Has anyone else considered the timing of this?

Just as Wikileaks has made it fashionable to expose government wrongdoings and showed how feasible it is to get and handle information that government agencies are interested in, comes the allegation that the most secure system in the world isn't secure.

The vulnerability would specifically be one that the U.S. agencies can exploit. In other words, the agencies that serve the government that is most embarrassed by recent leaks seem to have more teeth now. At the same time the system most likely used by leakers seems to be less secure. As an intentional move by U.S. government this would serve the purpose of making the established projects lose some of their confidence and spend time fretting over this, and to cause possible startups to consider their intended path too risky.

As Theo said, the claims may have some merit into them. FUD works best if it's partly true. In this case the timing is such a coincidence it makes the claims even more suspicious.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>