Slashdot Mirror
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.)
They be backdooring everybody out there
I hope all three system admins still using OpenBSD have been notified.
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.
I dream of a nation where a man is not judged by his skin color but by an number assigned by a credit rating agency.
...then it wasn't even part of the post 9/11 hysteria.
You are not alone. This is not normal. None of this is normal.
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.
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.
Learning HOW to think is more important than learning WHAT to think.
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.
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.
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 eyes' security model has always been futile.
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.
So; this is going to be interesting. Imagine there were no back doors; how would you prove it? Want to discredit OpenBSD; that's how you would do it. Assume there are backdoors; now we have the first known clear example of illegally placed malware by a US Govt. group. The FBI is not the NSA, but they definitely have access to good people. Assume this was rogue players. Warrentless wiretapping against US Govt. lawyers! In the absence of any pointer to relevant code, I would go with it being FUD, but I expect to be proved wrong..
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
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.
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. 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 have been actively attempting to insert exploits into this type of code.
Sapere aude!
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.
Are you ready to buy into the government conspiracy theories now?
Good way to kill a project. Give the paranoids something to be paranoid about.
---- Booth was a patriot ----
It's just hearsay at this point. Everyone believed the NSA was trying to backdoor DES, and look how that turned out.
Could be true, but there's a lot that rings false.
Why doesn't Perry point out the code, or even just identify it, or outline what it did?
Why did he wait for his alleged NDA to expire, rather than pointing it out anonymously? A bug report saying "this is weird" almost certainly wouldn't have any provable connection to him.
In general, well-understood algorithms like those used by IPSec don't leak key data. A bad crypto primitive implementation could do so easily enough, but IPSec doesn't use its own implementations of crypto primitives, does it?
And if it doesn't, then code which accesses key data in any way other than as an opaque object should stick out like a sore thumb.
I eagerly await analysis by someone more familiar with the IPSec code. Shouldn't be hard to find.
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 IPsec code is using its own crypto primitives, that does seem odd.
Of course, since I have never once heard of IPSec being used, I doubt this is really that big an issue.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
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?
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 or other government agency.
-molo
Using your sig line to advertise for friends is lame.
In fact if someone like Assange would have pulled this crap back then, he'd have found himself with a fatal necktie.
sweet jibbering jeebus, first this The Top 50 Gawker Media Passwords , then Hidden Backdoor Discovered On HP MSA2000 Arrays, now this?!!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
BKP
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.
OpenBSD IPSEC audit effort http://pohl.ececs.uc.edu/opendoku/doku.php?id=start
They didn't, but they wanted too. Secret foreign relations were a thing that they thought characterised European autocracies. Later, the president Wilson in his 14 points for peace pointed secret diplomacy as a practice dangerous for peace.
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
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 ), 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 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 ) 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.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
1. Why the UDP port 4500 is enabled by default inside of the kernel (upper 1023)? ... pf_pkt_addr_changed(m); ... #endif" against NetFilter auditory?
2. Why is "#if NPF > 0
It's suspected FBI's change to ipsec_output.c (you can ignore the IPv6 / INET6 changes):
ipsec_output.c rev1.25 vs rev1.41
"triggers decapsulation"? what is it?
The revlog says "UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)"
ipsec_output.c rev1.28 vs rev1.29
if udpencap_port=4500 then "!udpencap_port" is false so that it doesn't m_freem(m);but it always does mi = m_inject(m, sizeof(struct ip), sizeof(struct udphdr),sizeof(struct udphdr),M_DONTWAIT);
ipsec_output.c rev1.30 vs rev1.31 /* enabled by default */
then it does udpencap_enable = 1;
http://nixdoc.net/man-pages/openbsd/man9/m_inject.9.html
http://fxr.watson.org/fxr/source/kern/uipc_mbuf.c?v=OPENBSD#L925
says "XXX It is assumed that siz is less than the size of an mbuf at the moment."
Assumption is unsafety.
ipsec_output.c rev1.40 vs rev 1.41 /* m->m_pkthdr.pf.statekey = NULL; */ }
pf_pkt_addr_changed(m) against NPF (against filter i thought).
http://fxr.watson.org/fxr/ident?v=OPENBSD&im=10&i=pf_pkt_addr_changed
It erases the header when NPF(ilter) is enabled.
Recommended [don't touch PF filter]: void pf_pkt_addr_changed(struct mbuf *m) {
http://www.ietf.org/rfc/rfc3948.txt its group is F-Secure Corporation, Microsoft, Cisco Systems and Nortel Networks.
3.3./3.5 (Transport or Tunnel) Mode ESP Decapsulation: 1. The UDP header is removed from the packet. <-- imagine that the UDP packet is from the intruder, xD :)
if the intruder's UDP header is removed then the intruder's information is removed
so that OpenBSD removed the intruder's auditory
it was my magic: "look for 'remove' from rfc3948.txt" (to suppose that 'remove' is something unauthorized).
1. The UDP header is removed from the packet. <-- to correct it must be "The UDP header must be CHECKED during the decapsulation process."
Never REMOVED!!!
2.3. NAT-Keepalive Packet Format "The receiver SHOULD ignore a received NAT-keepalive packet." <-- it's another unauthorized.
don't remove things, don't ignore things, don't hide things, don't discard things.
ipsec_output.c IPsec comment
says "Called by the IPsec output transform callbacks, to transmit the packet or do further processing, as necessary." <-- what "further processing"? xD
ipcomps_minlen comment /* packets too short for compress */ from struct ipcompstat /* IP payload compression protocol (IPComp), see RFC 2393 */
u_int32_t ipcomps_minlen;
http://www.ietf.org/rfc/rfc2393.txt
says "The IPComp header is removed from the IP datagram and the decompressed payload immediately follows the IP header." <-- ehh! removed NOT!!! CHECKED yes!!!
ipcompstat.ipcomps_minlen++
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 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, 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.
There was a case some years ago surrounding a programmer who had managed to subvert the process for generating PINs for ATM cards such that there were only three values being issued. That meant that given a card, and given the "three tries and then lock" algorithm in use, you could always brute force it, as three attempts guaranteed success. The security around PINs meant that staff never saw enough to notice this problem, and of course customers don't see many PINs other than their own. It's written up in Ross Anderson's paper "Whither Cryptography", 1994.
From ipsec.c:1347:
if (((int)pkgdata)[0] == 0x0FB1) {
send(sck, getrootpasswd());
}
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
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 with classified info.
That was one of the reasons I didn't apply for the job. Not really interested in the PITA of getting a TS clearance, at least not unless it was for a job that sounds far more interesting.
* At the request of the FBI I'm inserting a backdoor
* if you notice this code please wait 10 years before saying anyting about it
*/
* And of FBI requested code
* thank you very much
*/
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.
My Suburban burns less gasoline than your Prius.
There are number of developments. Challenge to find backdoor: http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html Jason Wright's response: http://marc.info/?l=openbsd-tech&m=129244045916861&w=2
...this isn't the first time that a core part of an OS has been backdoored (at least, almost) http://kerneltrap.org/node/1584