FBI Alleged To Have Backdoored OpenBSD's IPSEC Stack

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

Comments

Hide yo keys, hide yo passwords

[Anonymous Coward]

They be backdooring everybody out there

Re:Hide yo keys, hide yo passwords

[iCEBaLM]

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

[Anonymous Coward]

I hope all three system admins still using OpenBSD have been notified.

Re:Oh shit...

[Delarth799]

Well they would have been notified sooner but the clouds kept interfering with our smoke signals.

But but but

[igreaterthanu]

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

[MichaelSmith]

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:But but but

[Sycraft-fu]

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.

Re:But but but

[gnapster]

So what you are saying is, your OpenBSD box is running a version that is missing 60% of the timeline where edits could have been made to break this backdoor?

Re:But but but

[Anonymous Coward]

i do. great film.

Re:But but but

[ratboy666]

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

[recoiledsnake]

http://www.openbsd.org/reprints/article_20000419.html

"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:But but but

[jon787]

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:But but but

[The Wild Norseman]

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.

Could be hard

[Sycraft-fu]

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.

French ssh port (ssf) suggested strange weaknesses

[Anonymous Coward]

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:But has it been confirmed?

[InlawBiker]

Shit, I just found it. How'd we miss this before?

        if (Password == "JOSHUA")
        {
                printf("Greetings Professor Falken");
                godmode = true;
                return;
            }

Re:If this was ten years ago...

[chill]

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.

So Sycraft-fu

[Anonymous Squonk]

Are you ready to buy into the government conspiracy theories now?

Re:So Sycraft-fu

[TarPitt]

Not that this has ever happened before, mind you:

Zug, Switzerland. For four decades, the Swiss flag that flies in front of Crypto AG has lured customers from around the world to this company in the lake dis- [words missing] most sensitive diplomatic and military communications value Switzerland's reputation for business secrecy and political neutrality. Some 120 nations have bought their encryption machines here.

But behind that flag, America's National Security Agency hid what may be the intelligence sting of the century. For years, NSA secretly rigged Crypto AG machines so that U.S. eavesdroppers could easily break their codes, according to former company employees whose story is supported by company documents.

The Baltimore Sun, About December 4, 1995, pp. 9-11.

as found in Cryptome

Re:Many eyes make bugs / backdoors shallow

[inca34]

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

The etherpad (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION

Original Email:

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

The code:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c

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
PublicPad (this document); http://piratenpad.de/condition-beige

Press:

http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd

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/
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC

Docs:

http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/*
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html

Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright

Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs