FBI Alleged To Have Backdoored OpenBSD's IPSEC Stack 536
Aggrajag and Mortimer.CA, among others, wrote to inform us that Theo de Raadt has made public an email sent to him by Gregory Perry, who worked on the OpenBSD crypto framework a decade ago. The claim is that the FBI paid contractors to insert backdoors into OpenBSD's IPSEC stack. Mr. Perry is coming forward now that his NDA with the FBI has expired. The code was originally added ten years ago, and over that time has changed quite a bit, "so it is unclear what the true impact of these allegations are" says Mr. de Raadt. He added: "Since we had the first IPSEC stack available for free, large parts of the code are now found in many other projects/products." (Freeswan and Openswan are not based on this code.)
Hide yo keys, hide yo passwords (Score:5, Funny)
They be backdooring everybody out there
Re: (Score:2, Funny)
They be backdooring everybody out there
You don't have to come and confess, we're looking for you, we gonna find you.
Re: (Score:2, Insightful)
Sure gonna. You left your fingerprint and all you are so dumb. You are really dumb. For real.
(I can't believe how well this fits...)
what is this, backdoor week on /. ?!!! (Score:3)
Re:Hide yo keys, hide yo passwords (Score:5, Funny)
'Deys combin' through ur net-dumps,
'Deys snatchin ur packets up,
Tryin' ta read 'em so y'all need ta,
Hide yo' keys, hide yo' crypts,
Hide yo' keys, hide yo' crypts,
Hide yo' keys, hide yo' crypts,
An' hide yo' passwords cause they backdoorin' everybody out here.
You don't have to come an' confess, we lookin' for you,
We gon find you,
We gon find you.
So we can run and check DAT,
Run and check DAT,
Run and check DAT,
Homeboy, home-home, homeboy.
We got your source code and you left timestamps and all,
You are so dumb,
You are really dumb, fo' real.
I was attacked by the NSA on black projects.
So dumb, so dumb, so dumb, so.
'Deys combin' through ur net-dumps,
'Deys snatchin ur packets up,
Tryin' ta read 'em so y'all need ta,
Hide yo' keys, hide yo' crypts,
Hide yo' keys, hide yo' crypts,
Hide yo' keys, hide yo' crypts,
An' hide yo' passwords cause they backdoorin' everybody out here.
You don't have to come an' confess, we lookin' for you,
We gon find you,
We gon find you.
So we can run and check DAT,
Run and check DAT,
Run and check DAT,
Homeboy, home-home, homeboy.
Oh shit... (Score:5, Funny)
I hope all three system admins still using OpenBSD have been notified.
Re:Oh shit... (Score:5, Funny)
Re:Oh shit... (Score:5, Insightful)
While funny, it misses the bigger picture of the OpenBSD stack/code being hidden in other devices, especially vpn/firewall appliances.
Re:Oh shit... (Score:5, Funny)
My brother and I have OpenBSD boxes as our firewalls and site-to-site VPNs between our houses.
Who is the third person?
The FBI guy of course.
But but but (Score:5, Insightful)
Many eyes makes FOSS software invulnerable to this sort of attack?
Not trying to troll here, but seriously people should be doing more audits, especially themselves.
If this has been there for ten years, then this is ten years too late in spotting it.
Re:But but but (Score:5, Interesting)
Re: (Score:2)
Please tell me you're not referring to the "NSAKey" urban legend.
Re: (Score:2)
Re:But but but (Score:5, Informative)
Some of the files SCO claimed were infringing turned out to be BSD code, and as such, entirely okay (SCO couldn't claim rights to BSD code because of the Regents of the U of C vs AT&T case).
-- Barbie
Re:But but but (Score:5, Funny)
mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi
e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij
4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB
AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292
PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR
YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r
it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa
5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe
UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+
n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE=
Goddammit. Now I'm gonna have to change my Slashdot password.
Re:But but but (Score:5, Insightful)
Re:But but but (Score:4, Insightful)
Use the source! There's no need to wonder, pick a likely function, audit it, and post your results!
Re: (Score:3)
Governments have been keeping secrets ever since there have been governments. you think the founding fathers blabbed all their plans to the people at large?
Re:You pay for corruption. (Score:4, Insightful)
In fact if someone like Assange would have pulled this crap back then, he'd have found himself with a fatal necktie.
Re:You pay for corruption. (Score:4, Interesting)
Re:But but but (Score:5, Informative)
Is Google really that hard to use?
http://www.computerworld.com/s/article/9141105/NSA_helped_with_Windows_7_development
"Working in partnership with Microsoft and elements of the Department of Defense, NSA leveraged our unique expertise and operational knowledge of system threats and vulnerabilities to enhance Microsoft's operating system security guide without constraining the user to perform their everyday tasks, whether those tasks are being performed in the public or private sector," Richard Schaeffer, the NSA's information assurance director, told the Senate's Subcommittee on Terrorism and Homeland Security yesterday as part of a prepared statement.
Re: (Score:3)
Also from that link...
This is not the first time that the NSA has partnered with Microsoft during Windows development. In 2007, the agency confirmed that it had a hand in Windows Vista as part of an initiative to ensure that the operating system was secure from attack and would work with other government software. Before that, the NSA provided guidance on how best to secure Windows XP and Windows 2000.
Oh, my sides! I guess that was an epic FAIL for the NSA then? (Either that, or Windows might actually have been more vulnerable to attack without their help.)
Re: (Score:3)
People always forget about the second mission of the NSA - securing the government computing infrastructure. That's why they cough up stuff like SELinux, or their hardening manuals.
Putting a backdoor into windows would be stupid unless you at the same time make sure there is a backdoor-free version for government use. Ensuring that would mean no government office can ever buy a windows off-the-shelf, it all has to be coordinated centrally. At an operation that size, I'm not sure you could keep it a secret.
S
Re: (Score:3)
Well,they can just build in backdoors to which only they have keys, and keep it secret.
They are a secret service. They know (from their own painful experience) that secrets do not stay secrets for unlimited times, and the more people know about it, the less so.
Seriously, sending an agent with a lockpick set is several orders of magnitude cheaper than creating a secret cryptographic backdoor. I'm very certain the NSA is no stranger to every trick in the book. I do, however, think that they are too smart to do the obvious thing.
Re: (Score:3)
A master key to a crypto algorithm that does not per se include one would require modifications to the algorithm. It would very likely be noticed at the very first code audit.
Seriously, I think the NSA is happy that everyone thinks they added some backdoor to windows. Because while everyone spends their time looking for it there, whatever they really did gets no attention.
Re: (Score:3)
(#) Copyright (c) 1983 The Regents of the University of California. All rights reserved.
Re:But but but (Score:5, Insightful)
I doubt the situation would be any better if OpenBSD had been commercial and closed source. Who's to say the same back door isn't in Tru64, HP-UX and AIX?
Re: (Score:3, Insightful)
Commercial is different though, with FOSS I and (everyone else should for that matter), expect that there are no backdoors and it does exactly what it says it does.
That is supposed to be one of the biggest "selling points" of FOSS.
Re: (Score:3)
On the other hand the government can legally require software vendors to include backdoors and keep it secret. (See original DES machines IIRC.)
With closed source, you don't even have a chance here.
Re:But but but (Score:5, Interesting)
Ah the old NSA DES conspiracy theory. The NSA suggested two changes to DES: 1) shorten the key 2) changed the S-boxes. They gave no public explanation for the latter and for years the story was that this somehow introduced a backdoor into the algorithm. The truth came out over a decade later:
"Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique in the 1970s. This was indeed the case; in 1994, Don Coppersmith published some of the original design criteria for the S-boxes. According to Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret."
Of course, they could still be lying, better keep the tinfoil hat on.
Re: (Score:3)
Steven Levy is a rather authoritative source.
I would not doubt his word.
Re:But but but (Score:5, Insightful)
One of the biggest selling points of FOSS is that you can audit it at leisure, without having to go to the maker, give them a GOOD reason why you'd want to audit the source and sign NDAs with blood.
Unaudited, FOSS is just as well audited as closed source. Duh.
In other words, as long as everyone's too lazy/cheap/dumb to actually DO an audit, yes, FOSS is by no means more secure than CSS.
Re: (Score:3)
In other words, as long as everyone's too lazy/cheap/dumb to actually DO an audit, yes, FOSS is by no means more secure than CSS.
With FOSS, though, all it takes is for ONE person to not be too lazy/cheap/dumb to actually notice an anomaly and people will be all over it like piranhas on a floating cow.
Re: (Score:3)
Re: (Score:3)
Or the code is there, for you to look at, if you want. There's no guarantee someone else has or that it's quality code.
Yet we are frequently and loudly told by Open Source evangelists that the fact lots of people CAN look at the code *implicitly* means lots of people WILL be looking at the code.
This is, as the GP said, supposed to be one of the biggest selling points of Open Source.
Re: (Score:3)
Yet we are frequently and loudly told by Open Source evangelists that the fact lots of people CAN look at the code *implicitly* means lots of people WILL be looking at the code.
Yes, and?
Nobody expects some 'if key == 0123456789 user = root' style of coding here. A lot of people actually look at code.
But there is a huge difference between spotting incidental coding errors (bugs) and deliberate, obfuscated Covert Channels. Here we talk about the latter category.
Re:But but but (Score:5, Insightful)
Actually it would likely be harder. In the case of OSS, all you have to do is get people to contribute to the code. The FBI doesn't really have to be sneaky about it at all, other than that the people don't reveal who they work for. They could even lie about who they are as it is all done over the net anyhow. If it gets discovered, well no big deal really. I mean it is free and open, nobody made them accept those contributions. There's no legal problems that I can see.
In the case of a company, you have to either subvert or plant employees there. Doing that without a court order would be illegal. It also has to go on undetected, of course, and that is much harder since the employee works physically at the company. Then there's the problem that if it becomes known, you may have a lawsuit on your hands, or congressional inquiry, and so on. Big companies wield a lot of power and would likely not be amused in the slightest.
However what the GP is really saying overall is that if this turns out to be true (please note I am doubtful of that) it shows a weakness in the "many eyes" idea. That mantra is repeated over and over by OSS advocates almost like an incantation, that because something is open it means that all sorts of people are looking it over and there won't be anything evil in it. That is not the case, of course. Some OSS stuff is well audited, some is not. If this proves to be true it would show that even the pretty well audited stuff is not immune, that just having the source out in the open is not enough to guarantee security.
So Sycraft-fu (Score:5, Funny)
Are you ready to buy into the government conspiracy theories [slashdot.org] now?
Re:So Sycraft-fu (Score:5, Informative)
Not that this has ever happened before, mind you:
The Baltimore Sun, About December 4, 1995, pp. 9-11.
as found in Cryptome [cryptome.org]
Re:But but but (Score:5, Informative)
http://www.openbsd.org/reprints/article_20000419.html [openbsd.org]
"The recent incident of "backdoors" in Microsoft software is indicative of a fundamental problem that electronic commerce will need to address very soon," Jerry Harold, president & co-founder of NetSec [...] Even if Microsoft has stringent internal requirements for software assurance, it's very difficult to catch a backdoor that may be hidden by a single coder deep inside hundreds of thousands of lines of code," said Harold
"This is why NetSec builds its products on an operating system (OpenBSD) that has made security its number one goal," Harold told SOURCES. "The source for the operating system was re-built from the ground up for security and is publicly available. As a result, it is continuously subjected to rigorous security review by independent software engineers around the world. This has additional benefits because secure code often tends to be well designed, stable, and efficient."
Re: (Score:3, Interesting)
And it's not like closed-source would be any better - then, the FBI can just pay the company to slip one in. I'm not worried about my OpenBSD box - it's already far more secure than my Windows rigs are. Hell, I haven't even bothered updating it in years - it's still running 3.6.
Re:But but but (Score:5, Insightful)
Re: (Score:3)
Upgrading is fairly painless these days, from what I recall.
Download new kernel, installer version or whatnot.
Reboot, boot to it.
Press U for upgrade or somesuch.
Untar the new config files, check/merge the ones you've changed.
then uh.. pkg_add upgrade or so
The longest part is merging config, if you've made a lot of changes to the default. I seem to think there is a tool to hold your hand for it too, sysmerge?
not too bad. I think it was worse in the 3.x days though, it's been a while.
Re: (Score:3)
OpenBSD: the operating system so secure that the FBI is scared of it.
Re: (Score:3)
The remaining question is, did the CIA, NSA, KGB, FSB, and MI5 all add backdoors too, or do they have cross-licensing agreements...
Re:But but but (Score:5, Interesting)
It isn't necessarily obvious.
Basically, the idea is that bits of the key leak. And how is this accomplished?
For example - if a key bit is 0, you take one code path, if 1, another. Make the two paths different lengths. It may be possible to affect packet timing. Or... A function may end with "x - y" and then return "z". No leak? Not so clear, the carry/borrow may be leaking information to the caller (on x86 style hardware).
Anyway, it probably isn't a "back door", just some means of determining enough key bits to make brute force practical is enough. And this sort of thing can be subtle. It can even be based on the machine code generated for certain sequences by a particular compiler (the "x-y; return z" sequence above, for example).
Re:But but but (Score:5, Insightful)
Re:But but but (Score:5, Funny)
i do. great film.
Re: (Score:2)
Re:If this was ten years ago... (Score:5, Interesting)
No, but it was part of the post-Wassenaar agreement (Dec. 1998) that de-weaponized open source crypto. 10 years ago would have been around OpenBSD 2.8 (12/1/2000) which introduced AES and was the first release after the expiration of the RSA patent.
v2.7 saw the introduction of hardware-accelerated IPSec only 6 months before.
They were moving fast and furious on IPSec. This would have been an opportune time to spike them.
But has it been confirmed? (Score:5, Insightful)
Why engage in mass speculation? Check out the code from the time period in question and audit it for a back door. I don't know why everyone should get up in arms over an allegation that may very well be unfounded.
Could be hard (Score:5, Insightful)
You have to remember that something like that wouldn't be in the code with a /*evil shit goes here*/ before it. To have survived it would need to be well hidden. The idea that you can just look at code and find problems is false. I mean were that the case, no software would ever have any bugs.
So to find it could take a lot of work, even when you know there is something to look for.
This presumes, of course, there IS something to look for and this isn't just some guy making shit up. I'm leaning more towards that option since I don't see why the FBI wouldn't have a longer NDA. Classified material is generally done for 50 years, and something like that would surely be classified.
Re: (Score:3)
if classified, it would be CIA. FBI has nether mandate, nether authority to declare anything 'classified'.
Re: (Score:3)
Citation needed. In addition to being a law-enforcement agency, the FBI is the USA's domestic intelligence agency (actually a slightly weird state of affairs, if you're used to countries that like to keep military and civilian stuff separate). That means that, in theory, it does the same sort of stuff the CIA does, if said stuff happens within the USA - the American equivalent of MI5 and MI6, respectiv
Says who? (Score:3)
Some years ago I was looking at a job at the FBI. Sysadmin type stuff, mostly end user (it specifically noted you didn't not need experience with "the mainframe" you'd just be helping users connect to it). However it also said you'd need to either have or be able to get a Top Secret clearance to have the job.
So even for a job that was non-investigative in nature, just doing tech support for agents basically, they anted a TS clearance. That tells you something about the likelihood of coming in to contact wit
Re: (Score:3)
I found it!
It's hidden away in:
#include <stdio.h>
See, your code might be fine... but everything the compiler tosses in may not.
42 Grams. (Score:2)
Because mass speculation is fun!
More seriously, some of the code obfuscation competitions out there show that code auditing alone may not be enough to track down every vulnerability - a single dedicated enough individual can probably slip something past that's too subtle to notice, especially if they're making a lot of 'good' commits at the same time.
Now realise that the article suggests that there may have been several people at this and the problem becomes evident.
Basically, over reliance on the 'many ey
Re:42 Grams. (Score:5, Insightful)
The code obfuscation competitions won't be good examples - since obfuscated code looks hard to understand, which would make it more noticeable to auditors, or even "normal programmers" looking at the code.
It'll be stuff like "The Underhanded C Contest": http://underhanded.xcott.com/?page_id=17 [xcott.com]
Or this: http://www.debian.org/security/2008/dsa-1576 [debian.org]
Or "accidentally" leave in a few exploitable buffer overflows or other "normal" bugs.
As for over reliance on "many eyes", just relying on it is over-reliance. The "many eyes" claim is not applicable when it comes to _security_ bugs.
There are many eyes, but they're all "watching TV". They'll notice if a bug crashes their DVR or causes image corruption, other than that no.
There are only very few skilled experienced eyes auditing the code, and not all of those are on the "defending" side.
Re: (Score:3, Insightful)
If the backdoor was done well, it may be impossible to confirm. Not that this is how it was done, but many encryption routines define lots and lots of constants. Random large primes and that sort of thing. You could assume that these constants were chosen for cryptographically sound reasons, and you might be right. You could also assume that these constants were created using an external "secret key", and that anyone with this secret key would be able to decrypt data, and you might be right. Or maybe i
Re: (Score:3)
I'm not a crypto geek, so I only recently read about Nothing up my sleeve numbers [wikipedia.org] (here on Slashdot, in fact). After seeing that I'd guess seemingly random large constants would already be considered suspicious.
Re: (Score:3)
Re:But has it been confirmed? (Score:5, Funny)
Shit, I just found it. How'd we miss this before?
if (Password == "JOSHUA")
{
printf("Greetings Professor Falken");
godmode = true;
return;
}
Re: (Score:2)
That's all we needed to know...
EVERYONE lock down your BSD boxen and prepare for Thermonuclear War!!1!
Do I want to play a game? NO!
Many eyes only works when the many eyes give two shits and are not worthless lackeys only pretend to have coding sK1llz. I know, I put all sorts of wacky references and useless nonsense into my Perl scriptings, and no one ever says a word. If my hat was black, someone's enterprise would be so screwed.
Re: (Score:2)
beeb, beeb, beeb.
it's not there !
keep looking, it has to be
list games
beeb, beeb, beeb.
play tic tac toe
(something like that...)
Re: (Score:3)
Because crypto is hard math and an absolute bitch to get right. The e-mail talks about inserting side-channel key-leaking mechanisms. Finding these may be nigh unto impossible because they simply could be a property of a specific mathematical function that has a subtle weakness.
In short, 99% of coders could audit this all day long and find absolutely nothing. You have to be a coder and a mathematician and a crypto specialist or you're probably just wasting your time.
This is why, time and again, companies
Only two remote holes in the default install (Score:2)
and probably no more NDA'd fed goon contributors in a heck of a long time!
Only two remote holes... (Score:5, Interesting)
Considering OpenBSD has performed extensive code audits and this is part of the core code, this is going to bring the argument about the importance of security code audits to the forefront.
They have their place, but...10 years and by one of the most anal-retentive, paranoid coding groups out there. Ouch.
Re:Only two remote holes... (Score:5, Insightful)
99.99% of code can be cleaned by talented enough audit freaks. Crypto code is in the other 0.01%. Proper cryptography development requires doctorate level mathematics skills.
Doctorate level math skills not needed ... (Score:5, Informative)
99.99% of code can be cleaned by talented enough audit freaks. Crypto code is in the other 0.01%. Proper cryptography development requires doctorate level mathematics skills.
Such math skills are needed to develop the algorithms but not to implement a provided algorithm or to verify the coded implementation.
Not likely (Score:4, Insightful)
It would be the NSA doing this and they wouldn't require a NDA that would expire. Such an agreement would be that it never would be revealed. Sounds like a hoax.
French ssh port (ssf) suggested strange weaknesses (Score:5, Interesting)
from ftp://ftp.nluug.nl/pub/metalab/docs/linux-doc-project/linuxfocus/English/Archives/lf-2003_03-0273.html
I often like to point out an incomprehensible weakness of the protocol concerning the "padding" (known as covered channel): in both version 1 and 2 the packets, have a length which is a multiple of 64 bits, and are padded with a random number. This is quite unusual and therefore sparing a classical fault that is well known in encrypting products: a "hidden" (or "subliminal") channel. Usually , we "pad" with a verified sequence as for example, give the value n for the byte rank n (self describing padding). In SSH, the sequence being (by definition) randomized, it cannot be checked. Consequently, it is possible that one of the parties communicating could pervert / compromise the communication for example used by a third party who is listening. One can also imagine a corrupted implementation unknown by the two parties (easy to realize on a product provided with only binaries as generally are commercial products). This can easily be done and in this case one only needs to "infect" the client or the server. To leave such an incredible fault in the protocol, even though it is universally known that the installation of a covered channel in an encryption product is THE classic and basic way to corrupt the communication, seems unbelievable to me . It can be interesting to read Bruce Schneier's remarks concerning the implementation of such elements in products influenced by government agencies. (http://www.counterpane.com/crypto-gram-9902.html#backdoors).
I will end this topic with the last bug I found during the portage of SSH to SSF (French version of SSH), it is in the coding of Unix versions before 1.2.25. The consequence was that the random generator produced ... predictable... results (this situation is regrettable in a cryptographic product, I won't go into the technical details but one could compromise a communication while simply eavesdropping). At the time SSH's development team had corrected the problem (only one line to modify), but curiously enough without sending any alert, not even a mention in the "changelog" of the product... one wouldn't have wanted it to be known, he wouldn't have acted differently. Of course there is no relationship with the link to the above article.
Re:French ssh port (ssf) suggested strange weaknes (Score:5, Interesting)
So what he was saying is, that they are padding with a potentially unencrypted random number, that can be used to guess earlier and later random numbers, and thus break SSH. The random number is a hint for crackers / PRNG guessers.
No, that a deliberately "broken" implementation of ssh (either on server or on client) could use the padding to leak the session key, and that without access to the code there would be no way to tell (... because the padding is "supposed" to be random...).
Quite clever actually, and reminescent about the ways how the French subverted the Luxembourgish Luxtrust system.
Luxtrust [luxtrust.lu] token are hardware crypto token containing a private key. The key (supposedly) is generated randomly by the token at initialization and never leaves the token, and can only be used to establish session keys and sign messages, where the critical calculation happens on the token. The key is used to secure banking transactions, so that for example, the French tax administration cannot spy on the communication between French citizens and their Luxembourgish bank.
That's the theory. The catch is, the tokens are manufactured by the French company Gemalto [gemalto.fr], and each token's random number generator will only ever "generate" private keys from a limited set (different for each token, of course). So, French tax administration can trivially infer the private key by looking up the public key in a table provided by Gemalto.
The scheme is virtually undetectable, because:
Result: Luxembourg spent millions on an inconvenient crypto scheme, which works neither on modern 64 bit compiters nor on mobiles, and which is useless for its purpose.
Re: (Score:3)
Hmm.. now interesting (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
You are a cynical bastard.
I like that. :-)
Re:Hmm.. now interesting (Score:5, Insightful)
If it is true, it was submitted as source code, subject to review, accepted by the community, and installed by users. I see nothing illegal here.
I also don't see where it's necessarily warrantless wiretapping. Sure, it could be used for that, but this kind of thing could also absolutely be used for warranted wiretapping. The FBI goes to a judge, gets a warrant, captures the traffic, and decrypts it using the backdoor. Again, nothing illegal.
There are ethical issues with intentionally subverting such a project, but I don't see legal issues such as you claim.
Why the software? (Score:2)
It makes more sense to hardcode a vulnerability into network hardware.
NDA with the FBI has expired (Score:2)
I really doubt that an NDA with the FBI would ever 'expire', even if you 'expire'.
Verification? (Score:2)
Anyone can make claims like 'ya, it was there, long ago, trust me'. How about some proof?
AND if there is proof, what are we going to do about it?
Wikileaks (Score:2)
Smear Campaign? (Score:5, Interesting)
Good way to kill a project. Give the paranoids something to be paranoid about.
It's just a claim (Score:3)
It's just hearsay at this point. Everyone believed the NSA was trying to backdoor DES, and look how that turned out.
Denial by Scott Lowe (Score:5, Informative)
The original message claimed Scott Lowe was on the FBI payroll:
for example Scott Lowe is a well
respected author in virtualization circles who also happens top be on
the FBI payroll, and who has also recently published several tutorials
for the use of OpenBSD VMs in enterprise VMware vSphere deployments.
In response, Scott Lowe has denied any affiliation with the FBI [marc.info] or other government agency.
-molo
(A) Scott Lowe denies the charge (Score:5, Informative)
I interviewed Scott Lowe this evening for ITworld and he denies the allegations. Asked why Perry made his charge, Lowe speculated that Perry may have meant another Scott Lowe [itworld.com].
BKP
An NDA that expires? I suspect a hoax. (Score:4, Interesting)
For those of you who are interested in finding out the facts, start by reading the whole thread on openbsd-tech (eg http://marc.info/?t=129236639300001&r=1&w=2 [marc.info] ), it's only a handful of messages so far and I find Damien Miller's response at http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 [marc.info] particularly enlightening. (You're using Damien's code right now, in some other window -- he's been a major OpenSSH developer for quite a while).
Then again, I have to agree with Bob Beck (see http://marc.info/?l=openbsd-tech&m=129236730027908&w=2 [marc.info] ) that this is fairly likely to part of a personal vendetta of some sort, possibly against either the OpenBSD project or even something totally unrelated, using the OpenBSD project only as the attention-grabber in contexts such as /.
At this point we have only allegations with some finger pointing, I for one look forward to any real information to surface. The best way to draw out the real information behind this is to do what Theo did - publish the allegations and let the involved parties explain themselves in public.
It's obvious once you know what to look for (Score:3)
From ipsec.c:1347:
if (((int)pkgdata)[0] == 0x0FB1) {
send(sck, getrootpasswd());
}
Hmmm kinda reminds me of ... (Score:4, Funny)
Garibaldi: Think they'll ever find that transmitter you slipped G'Kar?
Sinclair: No. because there isn't one.
Garibaldi: There isn't? Wait—
Sinclair: I lied. I figured if there were a transmitter, sooner or later they'd find it and remove it. But if I just told them there was, they'd keep looking. Indefinitely.
Garibaldi: Commander, do you have any idea of the tests they'll put him through, the things they'll do to him trying to find a transmitter that's not there?
Sinclair: Yes.
Re: (Score:2)
Certain parts from FreeBSD's and NetBSD's implementation of Unix were incorporated in NeXTSTEP, the core of Mac OS X.
So this might mean Mac OS X is not affected? I'm not knowledgeable enough on *BSD to know.
Re: (Score:3)
So this might mean Mac OS X is not affected? I'm not knowledgeable enough on *BSD to know.
While there is significant shared code between the BSD's and OS X and even Linux distributions; OpenBSD ships with an IPv4 IPSec stack that is pretty much only used by OpenBSD. OS X and most other BSDs use the KAME stack.
Re: (Score:3)
So this might mean Mac OS X is not affected? I'm not knowledgeable enough on *BSD to know.
I don't believe that Mac OS X is affected since OpenBSD only used the IPv6 part of the Kame Project [wikipedia.org]. Apparently OpenBSD developed their own version of IPSec while the other BSD variants used the IPSec implementation from the Kame Project.
Since Mac OS X's IPSec is derived from the one in FreeBSD and NetBSD it's not directly linked to the IPSec in OpenBSD. This doesn't mean that it hasn't been compromised, all code is suspect - even implementations in Linux and Windows - simply because it seems like people ha
Re:I forget... (Score:5, Informative)
No. NeXTSTEP pre-dated NetBSD and FreeBSD. NeXTSTEP was based on BSD Tahoe 4.3, and OS X took code from all three codebases (OS X was NetBSD-heavy in the early days until Jordan Hubbard joined Apple and influenced further conversion to FreeBSD code).
To this day you can find BSD code from all BSD codebases, but not quite as much from OpenBSD. Run 'strings' on the libraries to get the skinny.
Re: (Score:2)
From the ipsec(4) manpage for Mac OS X 10.6 [manpagez.com], history section:
The implementation described herein appeared in WIDE/KAME IPv6/IPsec stack.
The KAME [kame.net] stack is the same stack used in NetBSD [gw.com] and FreeBSD [freebsd.org].
Even though NeXTSTEP was forked earlier [levenez.com] from the BSD codebase than the other BSD flavors there has still been considerable sharing between it, Mac OS X, and the other BSD flavors. OpenBSD is one exception to this since it tends to be a more closed ecosystem than the other BSD variants.
Re: (Score:2)
Re: (Score:2)
In Soviet Russia, YOU spy on the American gov't!
This version of the joke is the most chillingly accurate I've ever seen.
Re: (Score:2)
Well, I would HOPE that if they've secretly cracked all the crypto then they can monitor everything Al Quaeda and Wikikeaks do or say. Since to be honest that level of crypto is being mostly used by schmucks these days
Since that doesn't seem to be the case, I think it's probably note likely that this claim is much more bogus. Why aren't they using these backdoors to punish enemies ?
Re: (Score:2)
Re: (Score:3)
Except for side channel attacks, which many implementations of the crypto primitives are vulnerable to, since avoiding all of them is very hard.
But that would be flaws in the primitives. Primitives can be misused in creating a cryptographic scheme, but the scheme was specified outside OpenBSD so mistakes in the scheme would not be specific to OpenBSD. We also know that the scheme was implemented more or less correctly, or it would fail to inter-operate with other IPSec implementations. Hmm... so unless IPse
Re:Many eyes make bugs / backdoors shallow (Score:5, Informative)
Re:Many eyes make bugs / backdoors shallow (Score:5, Informative)
It seems that link may have been /.ed. They are doing precisely as you say.
Here is a dump of the information, last I had it.
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate [twitter.com]
The etherpad [piratenpad.de] (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION
Original Email:
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 [marc.info]
The code:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c [openbsd.org]
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c [openbsd.org]
Misc:
What other software includes the OpenBSD IPSEC implementation?
Not Linux:
Triaging Linux; git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Initial commit 6c55c29fa, Oct 2002, Alexey Kuznetsov
Does not appear to be derived from the above? (checking strings from ipsec_input.c version 1.54.2.3, Oct 2002). Neither copyright information nor comment strings match. Linux's IPSec implementation looks original.
'git log -p --grep=IPSEC' on the above clone shows complete history for the period.
Communications:
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate [twitter.com]
PublicPad (this document); http://piratenpad.de/condition-beige [piratenpad.de]
Press:
http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/ [forbes.com]
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd [slashdot.org]
We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to Canada to
develop OpenSSH for this reason), so direct interference in the crypto
code is unlikely. It would also be fairly obvious - the crypto code
works as pretty basic block transform API, and there aren't many places
where one could smuggle key bytes out. We always used arcrandom() for
generating random numbers when we needed them, so deliberate biases of
key material, etc would be quite visible.
oored-OpenBSDs-IPSEC-Stack
http://www.reddit.com/r/programming/comments/elw0x/allegations_regarding_openbsd_ipsec_fbi_backdoors/ [reddit.com]
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC [metafilter.com]
Docs:
http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html [archive.org]
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm [gsaadvantage.gov]
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/* [archive.org]
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html [archive.org]
Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright [linkedin.com]
Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs [openbsd.org]