The FBI has been accused of planting backdoor in OpenBSD IPSEC stack, ten years ago.

The code is a publicly available Open Source project, the full history of commits is available for public review.  After a week of worldwide code audits by various institutions, no evidence to this effect has yet to be produced.

Whose logo do you trust more?  (OpenBSD on the left, FBI on the right)

http://en.wikipedia.org/wiki/IPsec
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session.

WHO CARES?

The implication in this situation is that the FBI could have then maintained a capability to eavesdrop on a majority of the world’s most secret digital communications.  The OpenBSD IPSEC stack sits at the lowest levels of most Open Source and Proprietary network software and hardware, Free and Commercial alike.  IPSEC, being born of the IPv6 protocol suite, is completely requisite in any standards-compliant IPv6 implementation- yet optional for IPv4, (the protocol of the current internet).

The OpenBSD IPSEC stack is possibly the most widely used and most trusted pieces of cryptographic network software.

Anyone who wants to may download the source code, (including all historical commits), and contemplate this reality for yourself:
http://www.openbsd.org/cgi-bin/cvsweb/
http://www.openbsd.org/anoncvs.html

Not sure you trust the official sources?  Find a mirror which suits you:
http://www.openbsd.org/ftp.html

http://www.tcpipguide.com/free/t_IPSecModesTransportandTunnel-2.htm

Where is this code?  It is widely assumed parts or all of the OpenBSD IPSEC stack can be found in:

http://en.wikipedia.org/wiki/IPsec#Software_implementations

– OpenBSD, with its own code derived from a BSD/OS implementation written by John Ioannidis and Angelos D. Keromytis in 1996.
– The KAME stack, that is included in Mac OS X, NetBSD and FreeBSD.
– “IPsec” in Cisco IOS Software
– “IPsec” in Microsoft Windows, including Windows XP, Windows 2000, Windows 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Vista and later
– Authentec QuickSec toolkits
– IPsec in Solaris
– IBM AIX operating system
– IBM z/OS
– IPsec and IKE in HP-UX (HP-UX IPsec)
– The Linux IPsec stack written by Alexey Kuznetsov and David S. Miller.
– Openswan on Linux, FreeBSD and Mac OS X using the native Linux IPsec stack, or its own KLIPS stack.
– strongSwan on Linux, FreeBSD, Mac OS X, and Android using the native IPsec stack.

—
10 YEARS AGO IN CRYPTO HISTORY, SOME CONTEXT
(cryptographers and people with secrets were quite grumpy)

The cryptography and info-sec communities were reeling after several high-profile US faux-paus:

1994, CALEA, Communications Assistance for Law Enforcement Act
“To amend title 18, United States Code, to make clear a telecommunications carrier’s duty to cooperate in the interception of communications for Law Enforcement purposes, and for other purposes.”
http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act

1993 to 1996: The Clipper Chip initiative, a move to put hardware-chip backdoors in every electronic device, a Presidential directive from US President President Bill Clinton:
http://en.wikipedia.org/wiki/Clipper_chip

US Cryptography Export Issues:
Long story short, in cryptography, it’s best to have as many eyes in the world auditing cryptographic code and algorithms.  US Crypto Export restrictions became especially contentious/silly in the late 1990’s:
http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States

Tempest operations, Eaves-Dropping via electrical emissions, (particularly a hot topic in the 1990’s, as declassified NSA work in the late 80’s was focused on using computer monitors emissions to eavesdrop on communications):
http://en.wikipedia.org/wiki/TEMPEST

Echelon, Cold-War onward, European Parliment moved to publicly investigate during 2001:
http://en.wikipedia.org/wiki/ECHELON

circa 1997-2005, Carnivore, Software system implemented by the FBI to monitor email and electronic communications:
http://en.wikipedia.org/wiki/Carnivore_(software)

—
<http://en.wikipedia.org/wiki/Openbsd>
Backdoor allegations

On 11 December 2010, Gregory Perry sent an email to Theo de Raadt alleging that FBI had paid some OpenBSD ex-developers 10 years previously to insert backdoors into the OpenBSD Cryptographic Framework. Theo de Raadt made the email public on 14 December by forwarding it to the openbsd-tech mailing list and suggested an audit of the IPsec codebase.[55][56] Theo’s response was skeptical of the report and he invited all developers to independently review the relevant code. In the week that has followed, no patches to that area of the code have appeared. As time and code reviews go on without backdoors found, this seems more and more likely to be a hoax on Perry’s part.

—
THEO’S ORIGINAL POST
(OpenBSD Project Leader)
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

List:       openbsd-tech
Subject:    Allegations regarding OpenBSD IPSEC
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2010-12-14 22:24:39
Message-ID: 201012142224.oBEMOdWM031222 () cvs ! openbsd ! org

I have received a mail regarding the early development of the OpenBSD
IPSEC stack.  It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack.  Around 2000-2001.

Since we had the first IPSEC stack available for free, large parts of
the code are now found in many other projects/products.  Over 10
years, the IPSEC code has gone through many changes and fixes, so it
is unclear what the true impact of these allegations are.

The mail came in privately from a person I have not talked to for
nearly 10 years.  I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this.  Therefore I am
making it public so that
(a) those who use the code can audit it for these problems,
(b) those that are angry at the story can take other actions,
(c) if it is not true, those who are being accused can defend themselves.

Of course I don’t like it when my private mail is forwarded.  However
the “little ethic” of a private mail being forwarded is much smaller
than the “big ethic” of government paying companies to pay open source
developers (a member of a community-of-friends) to insert
privacy-invading holes in software.

—-

From: Gregory Perry <Gregory.Perry@GoVirtual.tv>
To: “deraadt@openbsd.org” <deraadt@openbsd.org>
Subject: OpenBSD Crypto Framework
Thread-Topic: OpenBSD Crypto Framework
Thread-Index: AcuZjuF6cT4gcSmqQv+Fo3/+2m80eg==
Date: Sat, 11 Dec 2010 23:55:25 +0000
Message-ID: <8D3222F9EB68474DA381831A120B1023019AC034@mbx021-e2-nj-5.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset=”iso-8859-1″
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Status: RO

Hello Theo,

Long time no talk.  If you will recall, a while back I was the CTO at
NETSEC and arranged funding and donations for the OpenBSD Crypto
Framework.  At that same time I also did some consulting for the FBI,
for their GSA Technical Support Center, which was a cryptologic
reverse engineering project aimed at backdooring and implementing key
escrow mechanisms for smart card and other hardware-based computing
technologies.

My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI.  Jason
Wright and several other developers were responsible for those
backdoors, and you would be well advised to review any and all code
commits by Wright as well as the other developers he worked with
originating from NETSEC.

This is also probably the reason why you lost your DARPA funding, they
more than likely caught wind of the fact that those backdoors were
present and didn’t want to create any derivative products based upon
the same.

This is also why several inside FBI folks have been recently
advocating the use of OpenBSD for VPN and firewalling implementations
in virtualized environments, 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.

Merry Christmas…

Gregory Perry
Chief Executive Officer
GoVirtual Education

“VMware Training Products & Services”

540-645-6955 x111 (local)
866-354-7369 x111 (toll free)
540-931-9099 (mobile)
877-648-0555 (fax)

http://www.facebook.com/GregoryVPerry
http://www.facebook.com/GoVirtual

—
INITIAL RESPONSE FROM ONE PARTY IMPLICATED
Jason Wright
http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

List:       openbsd-tech
Subject:    Re: Allegations regarding OpenBSD IPSEC
From:       “Jason L. Wright” <jason () thought ! net>
Date:       2010-12-15 18:27:31
Message-ID: 20101215182710.GA6897 () jason-wright ! cust ! arpnetworks ! com

Subject: Allegations regarding OpenBSD IPSEC

Every urban lengend is made more real by the inclusion of real names,
dates, and times. Gregory Perry’s email falls into this category.  I
cannot fathom his motivation for writing such falsehood (delusions
of grandeur or a self-promotion attempt perhaps?)

I will state clearly that I did not add backdoors to the OpenBSD
operating system or the OpenBSD crypto framework (OCF). The code I
touched during that work relates mostly to device drivers to support
the framework. I don’t believe I ever touched isakmpd or photurisd
(userland key management programs), and I rarely touched the ipsec
internals (cryptodev and cryptosoft, yes).  However, I welcome an
audit of everything I committed to OpenBSD’s tree.

I demand an apology from Greg Perry (cc’d) for this accusation.  Do
not use my name to add credibility to your cloak and dagger fairy
tales.

I will point out that Greg did not even work at NETSEC while the OCF
development was going on.  Before January of 2000 Greg had left NETSEC.
The timeline for my involvement with IPSec can be clearly demonstrated
by looking at the revision history of:
src/sys/dev/pci/hifn7751.c (Dec 15, 1999)
src/sys/crypto/cryptosoft.c (March 2000)
The real work on OCF did not begin in earnest until February 2000.

Theo, a bit of warning would have been nice (an hour even… especially
since you had the allegations on Dec 11, 2010 and did not post them
until Dec 14, 2010).  The first notice I got was an email from a
friend at 6pm (MST) on Dec 14, 2010 with a link to the already posted
message.

So, keep my name out of the rumor mill.  It is a baseless accusation
the reason for which I cannot understand.

–Jason L. Wright

SOURCE CODE REFERENCES
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/hifn7751.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/cryptosoft.c

—
Jason Wright, “Regarding Greg Perry’s baseless accusations”
http://thought.net/jason/

I have posted a message to tech@. I do not intend to add any more fuel to his baseless accusations. [posting]
http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

Publications

“Neural Network Architecture Selection Analysis With Application to Cryptography Location”
Jason L. Wright and Milos Manic. In Proceedings International Joint Conference on Neural Networks (IJCNN), July 2010, Barcelona, Spain.doi:10.1109/IJCNN.2010.5596315
http://dx.doi.org/10.1109/IJCNN.2010.5596315

“The Analysis of Dimensionality Reduction Techniques in Cryptographic Object Code Classification”
Jason L. Wright and Milos Manic. In Proceedings Conference on Human Systems Interaction (HSI), pp. 157-162, May 2010, Rzeszow, Poland.doi:10.1109/HSI.2010.5514572
http://thought.net/jason/cv/hsi10_submission_44.pdf
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5514572

“Neural Network Approach to Locating Cryptography in Object Code”
Jason L. Wright and Milos Manic. In Proceedings International Conference on Emerging Technologies and Factory Automation (ETFA), September 2009, Palma de Mallorca, Spain. doi:10.1109/ETFA.2009.5347226
http://www.inl.gov/technicalpublications/Documents/4363837.pdf
http://dx.doi.org/10.1109/ETFA.2009.5347226

“Time Synchronization in Heirarchical TESLA Wireless Sensor Networks”
Jason L. Wright and Milos Manic. In Proceedings International Symposium on Resilient Control Systems (ISRCS), pp. 36-39, August 2009, Idaho Falls, ID, USA. doi:10.1109/ISRCS.2009.5251365
http://www.inl.gov/technicalpublications/Documents/4336149.pdf
http://dx.doi.org/10.1109/ISRCS.2009.5251365

“Finding Cryptography in Object Code”
Jason L. Wright. In Proceedings Security Education Conference: Toronoto (SECTOR). October 2008, Toronto, ON, Canada. (slides)
http://thought.net/jason/cv/CON-08-14597-paper.pdf
http://thought.net/jason/cv/CON-08-14597-slides.pdf

“Recommended Practice for Security Control System Modems”
James R. Davidson and Jason L. Wright. U.S. Department of Homeland Security National Cyber Security Division, Control Systems Security Program. January 2008.
http://csrp.inl.gov/Documents/SecuringModems.pdf

“Cryptography As An Operating System Service: A Case Study”
Angelos D. Keromytis, Theo de Raadt, Jason L. Wright, and Matthew Burnside. In ACM Transactions on Computer Systems (ToCS), vol. 24, no. 1, pp. 1 – 38, February 2006. (Extended version of USENIX Technical 2003 paper). doi:10.1145/1124153.1124154
http://thought.net/jason/cv/p1-keromytis.pdf
http://portal.acm.org/citation.cfm?doid=1124153.1124154

“The Design of the OpenBSD Cryptographic Framework”
Angelos D. Keromytis, Jason L. Wright, and Theo de Raadt. In Proceedings of the USENIX Annual Technical Conference, pp. 181 – 196. June 2003, San Antonio, TX. (Acceptance rate: 23.3%)
http://thought.net/jason/cv/ocf.pdf

“Experiences Enhancing Open Source Security in the POSSE Project”
Jonathan M. Smith, Michael B. Greenwald, Sotiris Ioannidis, Angelos D. Keromytis, Ben Laurie, Douglas Maughan, Dale Rahn, and Jason L. Wright. In Free/Open Source Development, Stefan Koch (editor), pp. 242 – 257. Idea Group Publishing, 2004. Also re-published in Global Information Technologies: Concepts, Methodologies, Tools, and Applications, Felix B. Tan (editor), pp. 1587- 1598. Idea Group Publishing, 2007.
http://thought.net/jason/cv/posse-chapter.pdf
http://thought.net/jason/cv/4-28.pdf

“Transparent Network Security Policy Enforcement”
Angelos Keromytis and Jason Wright. In Proceedings of the USENIX Annual Technical Conference, Freenix Track, pp. 215 – 226. June 2000, San Diego, CA. (Acceptance rate: 30%)
http://thought.net/jason/cv/bridgepaper.pdf

Presentations

“When Hardware is Wrong, or ‘They Can Fix it in Software'”
NYC BSD Conference, October 2008.
http://thought.net/jason/cv/hardware-wrong.pdf

“OpenBSD/sparc64”
NYC BSD Conference, October 2006.

—
CRYPTOME
http://cryptome.org/0003/fbi-backdoors.htm

21 December 2010. A sends:

Just to point out that one of the ex-developers involved in that period has posted some background info. You can contact Mickey yourself for more information:how i stopped worrying and loved the backdoor

http://mickey.lucifier.net/b4ckd00r.html

By the way, anybody want to elaborate how Theo de Raadt has been hiding 2 donations accounts from Canadian Tax Revenue Services for years now?

(Paypal and the German account  IBAN: DE91 7007 0024 0338 1779 00
BIC: DEUT DE DBMUC
Name: Theo de Raadt
Address: Deutsche Bank, Marienplatz 21
80331 München, Germany

Inside Germany, instead use:

Name: Theo de Raadt
Bank: Deutsche Bank München
BLZ: 70070024
Konto: 338177900

From outside Europe:

SWIFT: DEUTDEDBMUC
Account: 7007 0024 0338 1779 00
Name: Theo de Raadt
Address: Deutsche Bank, Marienplatz 21
80331 München, Germany

__________

20 December 2010. Gregory Perry further responds with the truth about the FBI:

From: Gregory Perry <Gregory.Perry[at]GoVirtual.tv>
To: John Young <jya[at]pipeline.com>
Subject: RE: OpenBSD Crypto Framework
Date: Mon, 20 Dec 2010 14:33:54 +0000

The issue of retribution has been ongoing on for over a decade at this point, the FBI is a lawless and corrupt organization with little hope for rehabilitation.  Maybe one day the Congress will issue a subpoena into their domestic ops and related skullduggery.

_________

From: John Young <jya[at]pipeline.com>
Sent: Monday, December 20, 2010 9:06 AM
To: Gregory Perry
Subject: RE: OpenBSD Crypto Framework

Thanks very much for responding. If you care to do so, we would like to hear of any retribution for dislosing the hole. Wikileaks we’re not but quieter. Anonymous is our best source.

---

20 December 2010. Gregory Perry responds:

From: Gregory Perry <Gregory.Perry[at]GoVirtual.tv>
To: John Young <jya[at]pipeline.com>
Subject: RE: OpenBSD Crypto Framework
Date: Mon, 20 Dec 2010 02:17:23 +0000

I really wish Theo hadn’t made that email public, it’s really stirred up things quite a bit in the mainstream media.

To put things into perspective, the salient points to consider are:

1)  I sent a private letter to Theo Deraadt, urging him to perform a source code audit of the OpenBSD Project based upon the allegations contained within the original email you referenced;

2)  Theo then sent, without my permission and against my wishes, the entire contents of that email with my contact particulars to a public listserver, which ignited this firestorm of controversy that I am now seemingly embroiled in;

3)  If I had this to do over again, I would have sent an anonymous postcard to Wikileaks probably;

4)  I have absolutely, positively nothing to gain from making those statements to Theo, and only did so to encourage a source code audit of the OpenBSD Project based upon the expiry of my NDA with the FBI; and,

5)  Being in any limelight is not my bag at all.

I personally hired and managed Jason Wright as well as several other developers that were involved with the OpenBSD Project, I am intimately familiar with OpenBSD having used it for a variety of commercial products over the years, and I arranged the initial funding for the cryptographic hardware accelerated OCF and gigabit Ethernet drivers by way of a series of disbursements of equipment and development monies made available via NETSEC (as well as my own personal donations) to the OpenBSD Project.

Although I don’t agree with what Theo did last week, I will say that he is a brilliant and very respected individual in the computer security community and he would have in no way agreed to intentionally weaken the security of his project.  Theo is an iron-fisted fascist when it comes to secure systems architecture, design, and development, and there is no better person than him and his team to get to the bottom of any purported issues with the OpenBSD security controls and its various internal cryptographic frameworks.

Many, many commercial security products and real time embedded systems are derived from the OpenBSD Project, due to Theo’s liberal BSD licensing approach contrasted with other Linux-based operating systems licensed under the GPL.  Many, many commercial security products and embedded systems are directly and proximately affected by any lapse in security unintentional or otherwise by the OpenBSD Project.  Almost every operating system on the planet uses the OpenSSH server suite, which Theo and his team created with almost zero remuneration from the many operating systems and commercial products that use it without credit to the OpenBSD Project.  Given the many thousands of lines of code that the IPSEC stack, OCF, and OpenSSL libraries consist of, it will be several months before the dust settles and the true impact of any vulnerabilities can be accurately determined; it’s only been about 96 hours since their source code audit commenced and your recent article points to at least two vulnerabilities discovered so far.

I wish Theo and his team the best of success with their project and endeavors.

Kind regards

Gregory Perry
Chief Executive Officer
GoVirtual® Education
http://www.GoVirtual.tv
P: 540-645-6955 x111
F: 877-648-0555
C: 540-931-9099
E: Gregory.Perry[at]GoVirtual.tv

GoVirtual® Education
10400 Courthouse Rd. #280
Spotsylvania, Virginia 22553

“VMware Training Products and Services”

Subscribe to the GoVirtual® Newsletter

---

15 December 2010. A3 sends a link to a refutation of Perry’s claims by Jason Wright, one accused by Perry:

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

15 December 2010. A sends a link to a report on Perry’s affirmation of his claims and new ones’s well:

http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd

15 December 2010. A1 and A2 send an account of denials by named participants and a fruitless effort to contact Perry:

http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-named-participant

A pointer to any response from Perry would be appreciated. Send to: cryptome[at]earthlink.net.

15 December 2010. A sent the same URL. Cryptome response:

Thanks for the pointer. Strong stuff, naming names, very unusual, likely to lead to professional suicide. Smells like a hoax or a competitor smear. We wrote last night the alleged author of the allegations for confirmation but have not received an answer. This is not to doubt that the TLAs do this regularly but to admit complicity is exceptional, and if genuine, an admirable public service. If the attribution is a hoax or a smear we’d like to make that known. Have you seen his confirmation or denial anywhere?

He may be in hiding or a sweat hole.

14 December 2010

---

A lie gets halfway around the world before the truth has a chance to get its pants on.
winston churchill

—

INTERNET STORM CENTER
OpenBSD IPSec “Backdoor”
http://isc.sans.edu/diary.html?storyid=10087

Published: 2010-12-15,
Last Updated: 2010-12-15 16:21:23 UTC
by Johannes Ullrich (Version: 1)

We received plenty of e-mail alerting us of a mailing list post [1] alleging a backdoor in the Open BSD IPSec code. The story is too good to pass up and repeated on twitter and other media. However, aside from the mailing list post, there is little if any hard evidence of such a backdoor. The code in question is 10 years old. Since then, it has been changed, extended, patched and copied many times. I personally do not have the time nor the skill to audit code of the complexity found in modern crypto implementations. But my gut feeling is that this is FUD if not an outright fraud.

Keep using VPNs, if you are worried, limit the crypto algorithms used to more modern once. It is always a good idea to build additional defensive layers and review configurations from time to time. But at some point, you have to decide who you trust in this game and how paranoid you can afford to be.

[1] http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
——
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Keywords: backdoor FBI openbsd
1 comment(s)

—
FBI accused of planting backdoor in OpenBSD IPSEC stack
By Ryan Paul
http://arstechnica.com/open-source/news/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack.ars

In an e-mail sent to BSD project leader Theo de Raadt, former NETSEC CTO Gregory Perry has claimed that NETSEC developers helped the FBI plant “a number of backdoors” in the OpenBSD cryptographic framework approximately a decade ago.

Perry says that his nondisclosure agreement with the FBI has expired, allowing him to finally bring the issue to the attention of OpenBSD developers. Perry also suggests that knowledge of the FBI’s backdoors played a role in DARPA’s decision to withdraw millions of dollars of grant funding from OpenBSD in 2003.

“I wanted to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA, the parent organization to the FBI,” wrote Perry. “This is also probably the reason why you lost your DARPA funding, they more than likely caught wind of the fact that those backdoors were present and didn’t want to create any derivative products based upon the same.”

The e-mail became public when de Raadt forwarded it to the OpenBSD mailing list on Tuesday, with the intention of encouraging concerned parties to conduct code audits. To avoid entanglement in the alleged conspiracy, de Raadt says that he won’t be pursuing the matter himself. Several developers have begun the process of auditing the OpenBSD IPSEC stack in order to determine if Perry’s claims are true.

“It is alleged that some ex-developers (and the company they worked for) accepted US government money to put backdoors into our network stack,” de Raadt wrote. “Since we had the first IPSEC stack available for free, large parts of the code are now found in many other projects/products. Over 10 years, the IPSEC code has gone through many changes and fixes, so it is unclear what the true impact of these allegations are.”

OpenBSD developers often characterize security as one of the project’s highest priorities, citing their thorough code review practices and proactive auditing process as key factors that contribute to the platform’s reputedly superior security. If Perry’s allegations prove true, the presence of FBI backdoors that have gone undetected for a decade would be a major embarrassment for OpenBSD.

The prospect of a federal government agency paying open source developers to inject surveillance-friendly holes in operating systems is also deeply troubling. It’s possible that similar backdoors could potentially exist on other software platforms. It’s still too early to know if the claims are true, but the OpenBSD community is determined to find out if they are.

—
Deconstructing the OpenBSD IPsec Rumors
2010-12-14 21:58:01 by Jason Dixon
http://obfuscurity.com/2010/12/Deconstructing-the-OpenBSD-IPsec-Rumors

Theo de Raadt posted an email to the openbsd-tech mailing list Tuesday evening which contained details of alleged backdoors added to the OpenBSD IPsec code by government contractors some ten years ago. Subsequent posts from Bob Beck and Damien Miller add further commentary, but neither confirm nor deny the allegations. Damien goes so far as to propose a number of possible avenues as the most likely places to begin a new audit.

One of the purported conspirators is Jason Wright, a cryptology expert at the Idaho National Laboratory, who committed a significant amount of crypto and sparc64 code to the OpenBSD project. Although I haven’t seen Jason in years, I consider”Wookie” a good friend and hope these accusations are false. If Damien’s hypothesis is correct, it seems highly unlikely that Jason (or any US developers) introduced backdoors directly into the crypto code. A more likely scenario would be the malicious reuse of mbufs in the network stack.

As Brian T. Merritt suggests, it seems even more likely that Linux would be similarly “exploited”. Lest we forget that while these claims against OpenBSD revolve around FBI involvement, Linux has had significant portions of its security code infiltrated by the NSA. Between these two code bases you’re talking about an enormous portion of the networking infrastructure that powers the Internet.

As a former OpenBSD committer, this saddens me. Not just because of the possibility that this might be true, but that regardless of whether or not this could be true, it means that developer and community resources will be swallowed into the rumor vacuum for untold weeks and possibly months. This results in less innovation, fewer bugfixes, and worst of all, a growing distrust among everyone involved.

This story has all the characteristics of being newsworthy for a long while. It has already made major headlines across Twitter, Slashdot, Reddit and OSNews. Most articles and tweets imply that the claims are fact, without any investigation of the source claim or the actual code in question. I hope that all parties involved are cleared of any wrongdoing. Either way, the cat is out of the proverbial bag. These claims will undermine a significant portion of goodwill and trust among all Free Software / Open Source projects. In the end, nobody wins.

—
The OpenBSD IPSec kerfuffle
Michael W Lucas, December 15th, 2010
http://blather.michaelwlucas.com/?p=452

By now you’ve probably heard of the allegations Theo forwarded to the OpenBSD-tech mailing list about the FBI introducing back doors in early versions of the OpenBSD IPSec code.  I’d like to offer my opinion, in the spirit of the Christmas season:

“Bah, humbug!”

It’s possible, but unlikely.  Like me winning the lottery is unlikely.  I’d need to buy a ticket, and that isn’t going to happen any time soon.

The OpenBSD group examines every line of code that goes into their tree.  Any obvious back door would be caught.  Any  subtle back door would be fragile — so subtle that it probably wouldn’t survive the intervening ten years of code churn and IPSec improvements.  Maybe someone has an appliance based on, say, OpenBSD 2.8 or 3.2, which could have contained the back door.  If true, we need to know about it.  But those users need to upgrade anyway.

And the FBI?  Nope, don’t believe it.  Ten years ago, the FBI was having lots of trouble understanding the Internet.  The NSA, maybe.

Bugs?  Sure, there’s probably bugs.  I expect we’ll find some, now that many eyes have turned to the code.  Exploitable bugs?  Maybe.  But that’s not the same as a back door.

OpenBSD has claimed to be the best for many years.  That claim motivates people to take them down.  The claims have hopefully inspired many people to examine the current and historical IPSec stack.  Theo and company have done nothing to discourage such audits: they’ve even offered pointers on where to look.  If you’re a programmer looking to make a splash, you could do worse than to join in on auditing the code.  Finding the alleged back door would make your reputation.  And we can always use more IPSec hackers.

The real impact might be, as Jason Dixon points out, the cost in OpenBSD developer time.  You know that some of their committers are examining the IPSec code today, trying to find potential back doors.

—
Schneier on Security

http://www.schneier.com/blog/archives/2010/12/did_the_fbi_pla.html
A blog covering security and security technology.
December 17, 2010
Did the FBI Plant Backdoors in OpenBSD?
It has been accused of it.
I doubt this is true. One, it’s a very risky thing to do. And two, there are more than enough exploitable security vulnerabilities in a piece of code that large. Finding and exploiting them is a much better strategy than planting them. But maybe someone at the FBI is that dumb.
EDITED TO ADD (12/17): Further information is here. And a denial from an FBI agent.
Posted on December 17, 2010 at 10:49 AM

—
FREEBSD DEVELOPER POSTS TRIPLE-BOUNTY FOR OPENBSD FLAWS
Dag-Erling Smørgrav (aka DES)
2010-12-15
http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html

OpenBSD IPSec backdoor allegations: triple $100 bounty
In case you hadn’t heard: Gregory Perry alleges that the FBI paid OpenBSD contributors to insert backdoors into OpenBSD’s IPSec stack, with his (Perry’s) knowledge and collaboration.

If that were true, it would also be a concern for FreeBSD, since some of our IPSec code comes from OpenBSD.

I’m having a hard time swallowing this story, though. In fact, I think it’s preposterous. Rather than go into further detail, I’ll refer you to Jason Dixon’s summary, which links to other opinions, and add only one additional objection: if this were true, there would be no “recently expired NDA”; it would be a matter of national security.

I’ll put my money where my mouth is, and post a triple bounty:

1) I pledge USD 100 to the first person to present convincing evidence showing:
– that the OpenBSD Crypto Framework contains vulnerabilities which can be exploited by an eavesdropper to recover plaintext from an IPSec stream,
– that these vulnerabilities can be traced directly to code submitted by Jason Wright and / or other developers linked to Perry, and
– that the nature of these vulnerabilities is such that there is reason to suspect, independently of Perry’s allegations, that they were inserted intentionally—for instance, if the surrounding code is unnecessarily awkward or obfuscated and the obvious and straightforward alternative would either not be vulnerable or be immediately recognizable as vulnerable.
– I pledge an additional USD 100 to the first person to present convincing evidence showing that the same vulnerability exists in FreeBSD.
– Finally, I pledge USD 100 to the first person to present convincing evidence showing that a government agency successfully planted a backdoor in a security-critical portion of the Linux kernel.

Additional conditions:
– In all three cases, the vulnerability must still be present and exploitable when the evidence is assembled and presented to the affected parties. Allowances will be made for the responsible disclosure process.
– Exploitability must be demonstrated, not theorized.
– I will not evaluate the evidence myself, but rely on the consensus of the OpenBSD, FreeBSD, Linux and / or infosec communities.
– Primacy will be determined in a similar manner.
– The evidence must be presented, and the bounty claimed, no later than 2012-12-31 23:59:59 UTC—a little more than two years from today.
– The bounty will, at the claimant’s discretion, either be transferred to the claimant by PayPal—no cash, checks, direct deposits or wire transfers—or donated directly to a non-profit of his or her choice.

Dag-Erling Smørgrav can be reached at:
des@des.no

—
OpenBSD/FBI allegations denied by named participants
Update: Government shilling accusations refuted by both similarly named persons
Tags: backdoors, EOUSA, FBI, OpenBSD
Brian Proffitt, December 14, 2010, 10:32 PM — http://www.itworld.com/open-source/130820/openbsdfbi-allegations-denied-named-participant

Update: This story was updated at 0920 on Dec. 15 to include comments from the second Scott Lowe, and expand on additional questions now sent to Gregory Perry.

Amidst startling accusations revealed by OpenBSD founder and lead developer Theo de Raadt today that 10 years ago the US Federal Bureau of Investigations paid developers to insert security holes into OpenBSD code, some confusion about the accusations has already emerged, with one named party strongly denying any involvement.

According to a post by de Raadt on the [openbsd-tech] mailing list, he received an email from Gregory Perry, CEO of GoVirtual Education, a Florida-based VMWare training firm, in which Perry told de Raadt he was “aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA [an acronym for the US Dept. of Justice], the parent organization to the FBI.”

In his message to de Raadt, Perry stated that while Perry was the CTO at NETSEC, “Jason Wright and several other developers were responsible for those backdoors.” Perry said that he was now able to share this information with de Raadt because his non-disclosure agreement with the FBI had “recently expired.”

If true, this type of government involvement would enhance the already present concerns free and open source developers tend to have about government policies concerning privacy.

But there are already challenges about the accuracy of Perry’s statements.

For instance, at the close of his message to de Raadt, Perry stated that the presence of these backdoors were why “several inside FBI folks have been recently advocating the use of OpenBSD for VPN and firewalling implementations in virtualized environments.”

“For example,” Perry concluded, “Scott Lowe is a well respected author in virtualization circles who also happens top [sic] be on the FBI payroll, and who has also recently published several tutorials for the use of OpenBSD VMs in enterprise VMWare vSphere deployments.”

I contacted Scott Lowe, VMWare-Cisco Solutions Principal at EMC this evening to ask if he had a comment about Perry’s statement to de Raadt. Lowe quickly responded via e-mail his denial:

“Mr. Perry is mistaken. I am not, nor have I ever been, affiliated with or employed by the FBI or any other government agency. Likewise, I have not ever contributed a single line of code to OpenBSD; my advocacy is strictly due to appreciation of the project and nothing more,” Lowe replied.

When I followed up with the question of why Perry might want to implicate Lowe for assisting the FBI in promoting OpenBSD, Lowe replied, “I do not know why Mr. Perry mentioned my name. I do know that there is another Scott Lowe, who also writes about virtualization, to whom Mr. Perry might be referring; I don’t have any information as to whether that individual is or is not involved.”

Mr. Lowe from North Carolina has been confused with the other Scott Lowe, Vice President and Chief Information Officer at Westminster College in Missouri, before.

Update:Mr. Lowe of Missouri was contacted for comment late last night, and did reply to my questions via e-mail early this morning.

“I am not, nor have I ever been, on the FBI’s payroll, nor do I use or advocate the use of OpenBSD either personally or in my writing,” Lowe of Missouri replied.

Perry may have gotten his Scott Lowes confused; stranger things have happened. Earlier in my own career, I was often confused with Brian Proffit, a prolific and excellent writer about OS/2 who is also a Baptist minister (trust me, I’m the evil twin).

The North Carolina Lowe has published articles and books on VMWare, while the Missouri Lowe has published his work primarily on TechRepublic, with more of a focus on Microsoft technologies, rather than VMware.

With the response of both Lowes on record, the question of mistaken identity becomes moot. It now becomes Perry’s word against two Scott Lowes’ that one of these gentlemen was promoting of OpenBSD happening on behalf of the FBI. It makes me wonder if Perry was speculating about Lowe’s alleged involvement with the FBI.

I have reached out to Perry for comment; specifically to elaborate the evidence he has regarding the involvement of a Scott Lowe, and to identify the Scott Lowe to which he was referring. As of 0920 EST on December 15, no reply from Perry has been received.

—
An FBI backdoor in OpenBSD?
by Robert McMillan, Security Blanket
Wed, 2010-12-15 09:06
Topic(s): Data Protection
http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd

You have to give Theo de Raadt credit: he’s into openness. What other software product would take serious, but questionable allegations about an FBI-planted back door in its code and just go public with them?

That’s what OpenBSD’s de Raadt did Tuesday after a former government contractor named Gregory Perry came forward and told him that the FBI had put a number of back doors in OpenBSD’s IPsec stack, used by VPNs to do cryptographically secure communications over the Internet.

The allegations could make many people think twice about the security of OpenBSD, but the way de Raadt handled the matter will probably have the opposite effect — giving them another reason to trust the software.

Here’s what de Raadt said:

I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this.  Therefore I am
making it public so that
(a) those who use the code can audit it for these problems,
(b) those that are angry at the story can take other actions,
(c) if it is not true, those who are being accused can defend themselves.

I contacted Perry about his email, and while I couldn’t get him on the telephone, he confirmed that his letter to de Raadt was published without his consent. He gave a few more details on his involvement with the FBI (which, by the way, has no immediate comment on this).

Hello Robert,

I did not really intend for Theo to cross post that message to the rest of the Internet, but I stand by my original email message to him in those regards.

The OCF was a target for side channel key leaking mechanisms, as well as pf (the stateful inspection packet filter), in addition to the gigabit Ethernet driver stack for the OpenBSD operating system; all of those projects NETSEC donated engineers and equipment for, including the first revision of the OCF hardware acceleration framework based on the HiFN line of crypto accelerators.

The project involved was the GSA Technical Support Center, a circa 1999 joint research and development project between the FBI and the NSA; the technologies we developed were Multi Level Security controls for case collaboration between the NSA and the FBI due to the Posse Commitatus Act, although in reality those controls were only there for show as the intended facility did in fact host both FBI and NSA in the same building.

We were tasked with proposing various methods used to reverse engineer smart card technologies, including Piranha techniques for stripping organic materials from smart cards and other embedded systems used for key material storage, so that the gates could be analyzed with Scanning Electron and Scanning Tunneling Microscopy.  We also developed proposals for distributed brute force key cracking systems used for DES/3DES cryptanalysis, in addition to other methods for side channel leaking and covert backdoors in firmware-based systems.  Some of these projects were spun off into other sub projects, JTAG analysis components etc.  I left NETSEC in 2000 to start another venture, I had some fairly significant concerns with many aspects of these projects, and I was the lead architect for the site-to-site VPN project developed for Executive Office for United States Attorneys, which was a statically keyed VPN system used at 235+ US Attorney locations and which later proved to have been backdoored by the FBI so that they could recover (potentially) grand jury information from various US Attorney sites across the United States and abroad.  The person I reported to at EOSUA was Zal Azmi, who was later appointed to Chief Information Officer of the FBI by George W. Bush, and who was chosen to lead portions of the EOUSA VPN project based upon his previous experience with the Marines (prior to that, Zal was a mujadeen for Usama bin Laden in their fight against the Soviets, he speaks fluent Farsi and worked on various incursions with the CIA as a linguist both pre and post 911, prior to his tenure at the FBI as CIO and head of the FBI’s Sentinel case management system with Lockheed).  After I left NETSEC, I ended up becoming the recipient of a FISA-sanctioned investigation, presumably so that I would not talk about those various projects; my NDA recently expired so I am free to talk about whatever I wish.

Here is one of the articles I was quoted in from the NY Times that touches on the encryption export issue:
http://www.nytimes.com/1999/10/11/business/technology-easing-on-software-exports-has-limits.html?pagewanted=all

In reality, the Clinton administration was very quietly working behind the scenes to embed backdoors in many areas of technology as a counter to their supposed relaxation of the Department of Commerce encryption export regulations – and this was all pre-911 stuff as well, where the walls between the FBI and DoD were very well established, at least in theory.

Some people have decided that Perry’s claims are not credible, and at least one person named in his email has come forward to say it’s not true.  But at this point, it seems that nobody but Perry really knows what’s going on.

It’s hard to really know what to say at this point. We’re talking about backdoors that probably just look like regular old bugs in code that was written 10 years ago.

—
CNET’s Declan McCullagh spotted the following tweet from former FBI agent E.J. Hilbert:

I was one of the few FBI cyber agents when the coding supposedly happened. Experiment yes. Success No.http://myloc.me/fiubs
7:57 PM Dec 14th via ÜberTwitter from Las Flores, CA
ejhilbert
E.J. Hilbert
https:// twitter.com /ejhilbert/status/14891845825863680

4 DAYS LATER:

@vze2p5 I commented to spark a discussion. Many take social media as truth rather than question & discuss. Its the former teacher in me
12:25 AM Dec 18th via TweetDeck in reply to vze2p5

https:// twitter.com /ejhilbert

—
CNET
http://news.cnet.com/8301-31921_3-20025767-281.html

Report of FBI back door roils OpenBSD community
by Declan McCullagh, December 15, 2010 11:08 AM PST

Allegations that the FBI surreptitiously placed a back door into the OpenBSD operating system have alarmed the computer security community, prompting calls for an audit of the source code and claims that the charges must be a hoax.

The report surfaced in e-mail made public yesterday from a former government contractor, who alleged that he worked with the FBI to implement “a number of back doors” in OpenBSD, which has a reputation for high security and is used in some commercial products.

Gregory Perry, the former chief technologist at the now-defunct contractor Network Security Technology, or NETSEC, said he’s disclosing this information now because his 10-year confidentiality agreement with the FBI has expired. The e-mail was sent to OpenBSD founder Theo de Raadt, who posted it publicly.

“I cashed out of the company shortly after the FBI project,” Perry told CNET today. “At that time there were significant legal barriers between domestic law enforcement and [the Department of Defense], and [this project] was in clear violation of that.” He said the project was a “circa 1999 joint research and development project between the FBI and the NSA,” which is part of the Defense Department.

The OpenBSD project, which was once funded by DARPA but had its funding yanked in 2003 for unspecified reasons, says that it takes an “uncompromising view toward increased security.” The code is used in Microsoft’s Windows Services for Unix and firewalls including ones sold by Calyptix Security, Germany’s Swapspace.de, and Switzerland’s Apsis GmbH.

In national security circles, it’s an open secret that the U.S. government likes to implant back doors in encryption products.
That’s what the FBI proposed in September, although it also claimed that the crypto-back doors would be used only through a legal process. So did the Clinton administration, in what was its first technology initiative in the early 1990s, which became known as the Clipper Chip.

If implemented correctly using a strong algorithm, modern encryption tools are believed to be so secure that even the NSA’s phalanxes of supercomputers are unable to decrypt messages or stored data. One report noted that, even in the 1990s, the FBI was unable to successfully decrypt communications from some wiretaps, and a report this year said it could not decrypt hard drives using the AES algorithm with a 256-bit key.

E.J. Hilbert, a former FBI agent, indicated in a note on Twitter last night that the OpenBSD “experiment” happened but was unsuccessful.

The Justice Department did not respond to a request from CNET yesterday for comment.

NETSEC, the now-defunct contractor, boasted at the time that it was a top provider of computer security services to the Justice Department, the Treasury Department, the National Science Foundation, and unnamed intelligence agencies. A 2002 NSF document (PDF) says NETSEC was “a contractor that NSF utilizes for computer forensics” that performed an investigation of whether data “deleted from an internal NSF server” amounted to a malicious act or not.

A snapshot of the NETSEC Web page from August 2000 from Archive.org shows that the company touted its close ties with the NSA. The founders created the company to build “upon practices developed while employed at the National Security Agency (NSA) and Department of Defense (DoD), the methodologies utilized at NETSEC today are widely regarded as the best anywhere,” it says.

On the OpenBSD technical mailing list, reaction was concerned but skeptical. One post suggested that the best way to insert a back door would be to leak information about the cryptographic key through the network, perhaps through what’s known as a side channel attack. (A 2000 paper describes that technique as using information about the specific implementation of the algorithm to break a cipher, in much the same way that radiation from a computer monitor can leak information about what’s on the screen. Secure environments use TEMPEST shielding to block that particular side channel.)

A 1999 New York Times article written by Peter Wayner about the Clinton administration’s encryption policies, which quoted Perry about OpenBSD, noted that the “the Naval Research Lab in Virginia is using OpenBSD as a foundation of its new IPv6 project.”
Perry told CNET that he hired Jason Wright “at NETSEC as a security researcher, he was basically paid to develop full time for the OpenBSD platform.” In the e-mail to de Raadt, Perry added that “Jason Wright and several other developers were responsible for those back doors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC.”
Wright’s LinkedIn profile lists him as a “senior developer” at the OpenBSD project and a cybersecurity engineer at the Idaho National Laboratory, and previously a software engineer at NETSEC. He did not respond to a request for comment.

A decades-long push for back doors
While the OpenBSD allegations may never be fully proved or disproved, it’s clear that the federal government has a long history of pressing for back doors into products or networks for eavesdropping purposes. The Bush administration-era controversy over pressuring AT&T to open its network–in apparent violation of federal law–is a recent example.
Louis Tordella, the longest-serving deputy director of the NSA, acknowledged overseeing a similar project to intercept telegrams as recently as the 1970s. It relied on the major telegraph companies, including Western Union, secretly turning over copies of all messages sent to or from the United States.

“All of the big international carriers were involved, but none of ’em ever got a nickel for what they did,” Tordella said before his death in 1996, according to a history written by L. Britt Snider, a Senate aide who became the CIA’s inspector general.

The telegraph interception operation was called Project Shamrock. It involved a courier making daily trips from the NSA’s headquarters in Fort Meade, Md., to New York to retrieve digital copies of the telegrams on magnetic tape.

Like the eavesdropping system authorized by President Bush, Project Shamrock had a “watch list” of people in the U.S. whose conversations would be identified and plucked out of the ether by NSA computers. It was intended to be used for foreign intelligence purposes.

Then-President Richard Nixon, plagued by anti-Vietnam protests and worried about foreign influence, ordered that Project Shamrock’s electronic ear be turned inward to eavesdrop on American citizens. In 1969, Nixon met with the heads of the NSA, CIA and FBI and authorized a program to intercept “the communications of U.S. citizens using international facilities,” meaning international calls, according to James Bamford’s 2001 book titled “Body of Secrets.”

Nixon later withdrew the formal authorization, but informally, police and intelligence agencies kept adding names to the watch list. At its peak, 600 American citizens appeared on the list, including singer Joan Baez, pediatrician Benjamin Spock, actress Jane Fonda, and the Rev. Martin Luther King Jr.

Another apparent example of NSA and industry cooperation became public in 1995. The Baltimore Sun reported that for decades NSA had rigged the encryption products of Crypto AG, a Swiss firm, so U.S. eavesdroppers could easily break their codes.

The six-part story, based on interviews with former employees and company documents, said Crypto AG sold its compromised security products to some 120 countries, in

http://news.cnet.com/8301-31921_3-20025767-281.html
http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
http://en.wikipedia.org/wiki/Theo_de_Raadt
http://news.cnet.com/Defense-agency-pulls-OpenBSD-funding/2100-1016_3-997393.html?tag=mncol;txt
http://www.openbsd.org/security.html
http://technet.microsoft.com/en-us/library/bb496994.aspx
http://calyptix.com/
http://www.swapspace.de/flash/index.html
http://www.apsis.ch/
http://news.cnet.com/8301-31921_3-20017671-281.html?tag=mncol;txt
http://news.cnet.com/8301-31921_3-20017671-281.html?tag=mncol;txt
http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA485001
http://yro.slashdot.org/story/10/06/26/1825204/FBI-Failed-To-Break-Encryption-of-Hard-Drives
https:// twitter.com /ejhilbert/status/14891845825863680
http://www.nsf.gov/pubs/2002/oigseptember2001/pdffiles/investigations.pdf
http://web.archive.org/web/20000815072218/www.netsec.net/info.html
http://marc.info/?l=openbsd-tech&m=129237675106730&w=2
http://www.schneier.com/paper-side-channel2.pdf
http://en.wikipedia.org/wiki/TEMPEST
http://www.nytimes.com/1999/10/11/business/technology-easing-on-software-exports-has-limits.html?pagewanted=print
http://thought.net/jason/
http://www.linkedin.com/in/jasonwright
https://inlportal.inl.gov/portal/server.pt/community/inl_portal_support/547
http://news.cnet.com/8301-13578_3-10143520-38.html?tag=mncol;txt
http://articles.baltimoresun.com/1995-12-10/news/1995344157_1_sting-encryption-sun

—
FINAL REFLECTIONS
(contemplate until someone comes up with the actual FBI-compromised code)

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

Reflections on Trusting Trust
Ken Thompson

Reprinted from Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763. Copyright © 1984, Association for Computing Machinery, Inc. Also appears in ACM Turing Award Lectures: The First Twenty Years 1965-1985 Copyright © 1987 by the ACM press and Computers Under Attack: Intruders, Worms, and Viruses Copyright © 1990 by the ACM press.
I copied this page from the ACM, in fear that it would someday turn stale.

Introduction

I thank the ACM for this award. I can’t help but feel that I am receiving this honor for timing and serendipity as much as technical merit. UNIX swept into popularity with an industry-wide change from central main frames to autonomous minis. I suspect that Daniel Bobrow (1) would be here instead of me if he could not afford a PDP-10 and and had to “settle” for a PDP-11. Moreover, the current state of UNIX is the result of the labors of a large number of people.

There is an old adage, “Dance with the one that brought you,” which means that I should talk about UNIX. I have not worked on mainstream UNIX in many years, yet I continue to get undeserved credit for the work of others. Therefore, I am not going to talk about UNIX, but I want to thank everyone who has contributed.

That brings me to Dennis Ritchie. Our collaboration has been a thing of beauty. In the ten years that we have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character. The result of our work together has been far greater than the work that we each contributed.

I am a programmer. On my 1040 form, that is what I put down as my occupation. As a programmer, I write programs. I would like to present to you the cutest program I ever wrote. I will do this in three stages and try to bring it together at the end.

Stage I

In college, before video games, we would amuse ourselves by posing programming exercises. One of the favorites was to write the shortest self-reproducing program. Since this is an exercise divorced from reality, the usual vehicle was FORTRAN. Actually, FORTRAN was the language of choice for the same reason that three-legged races are popular.

More precisely stated, the problem is to write a source program that, when compiled and executed, will produce as output an exact copy of its source. If you have never done this, I urge you to try it on your own. The discovery of how to do it is a revelation that far surpasses any benefit obtained by being told how to do it. The part about “shortest” was just an incentive to demonstrate skill and determine a winner.

 

FIGURE 1

Figure I shows a self-reproducing program in the C programming language. (The purist will note that the program is not precisely a self-reproducing program, but will produce a self-reproducing program.) This entry is much too large to win a prize, but it demonstrates the technique and has two important properties that I need to complete my story: (1) This program can be easily written by another program. (2) This program can contain an arbitrary amount of excess baggage that will be reproduced along with the main algorithm. In the example, even the comment is reproduced.

Stage II

The C compiler is written in C. What I am about to describe is one of many “chicken and egg” problems that arise when compilers are written in their own language. In this ease, I will use a specific example from the C compiler.

C allows a string construct to specify an initialized character array. The individual characters in the string can be escaped to represent unprintable characters. For example,

“Hello world\n”
represents a string with the character “\n,” representing the new line character.

 

FIGURE 3

Suppose we wish to alter the C compiler to include the sequence “\v” to represent the vertical tab character. The extension to Figure 2 is obvious and is presented in Figure 3. We then recompile the C compiler, but we get a diagnostic. Obviously, since the binary version of the compiler does not know about “\v,” the source is not legal C. We must “train” the compiler. After it “knows” what “\v” means, then our new change will become legal C. We look up on an ASCII chart that a vertical tab is decimal 11. We alter our source to look like Figure 4. Now the old compiler accepts the new source. We install the resulting binary as the new official C compiler and now we can write the portable version the way we had it in Figure 3.

 

FIGURE 4

This is a deep concept. It is as close to a “learning” program as I have seen. You simply tell it once, then you can use this self-referencing definition.

Stage III

 

FIGURE 5
Again, in the C compiler, Figure 5 represents the high-level control of the C compiler where the routine “compile” is called to compile the next line of source. Figure 6 shows a simple modification to the compiler that will deliberately miscompile source whenever a particular pattern is matched. If this were not deliberate, it would be called a compiler “bug.” Since it is deliberate, it should be called a “Trojan horse.”

 

FIGURE 6

The actual bug I planted in the compiler would match code in the UNIX “login” command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user.

Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions.

FIGURE 7

The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere.

Moral

The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

After trying to convince you that I cannot be trusted, I wish to moralize. I would like to criticize the press in its handling of the “hackers,” the 414 gang, the Dalton gang, etc. The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution. The companies that are vulnerable to this activity (and most large companies are very vulnerable) are pressing hard to update the criminal code. Unauthorized access to computer systems is already a serious crime in a few states and is currently being addressed in many more state legislatures as well as Congress.

There is an explosive situation brewing. On the one hand, the press, television, and movies make heroes of vandals by calling them whiz kids. On the other hand, the acts performed by these kids will soon be punishable by years in prison.

I have watched kids testifying before Congress. It is clear that they are completely unaware of the seriousness of their acts. There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor’s house. It should not matter that the neighbor’s door is unlocked. The press must learn that misguided use of a computer is no more amazing than drunk driving of an automobile.

Acknowledgment

I first read of the possibility of such a Trojan horse in an Air Force critique (4) of the security of an early implementation of Multics.

References

• Bobrow, D.G., Burchfiel, J.D., Murphy, D.L., and Tomlinson, R.S. TENEX, a paged time-sharing system for the PDP-10. Commun. ACM 15, 3 (Mar. 1972), 135-143.
• Kernighan, B.W., and Ritchie, D.M. The C Programming Language. Prentice-Hall, Englewood Cliffs, N.J., 1978.
• Ritchie, D.M., and Thompson, K. The UNIX time-sharing system. Commun. ACM 17, 7(July 1974), 365-375.
• Karger, P.A., and Schell, R.R. Multics Security Evaluation: Vulnerability Analysis. ESD-TR-74-193, Vol II, June 1974, p 52.