Reflections on Thompsons Reflections

Reflections on Thompsons Reflections

Written By
Peter Coffee
Peter Coffee
Feb 5, 2004
3 minute read
eWeek content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Every few years, I find it worth my time to re-read Ken Thompsons August 1984 article, “Reflections on Trusting Trust,” based on his 1983 Turing Award lecture that described what he called “the cutest program I ever wrote.” The lecture does not merely describe the anatomy of a clever hack: it demonstrates the need for important IT systems to be treated as fundamentally untrustworthy, and to be guarded by independent technical and procedural limits on what they are able to do.

Thompsons lecture is still being cited, for example, in discussions of computer-based voting systems in elections. His warnings also come to mind after reading William Safires column for the New York Times, released this morning, about the Wests deliberate sabotage of the former Soviet Unions campaign of Cold War technology theft–specifically, the Trojan Horse that was implanted in stolen pipeline-control software to create “the most monumental non-nuclear explosion and fire ever seen from space” (as described by Thomas Reed in his forthcoming book, “At the Abyss: An Insiders History of the Cold War.”) If you dont want to wait for next months publication of Reeds book, you can find additional background on Safires column in an article by Gus Weiss, whom Safire calls the “mild-mannered economist” who “engineered” the sabotage effort.

Thompsons device for concealing a “back door” superuser account was discoverable only by someone with access to the entire chain of system software, including the compiler that was used to compile the compiler. It was not a theoretical exercise, but a convenient method that he devised for ensuring access to the early Unix systems that he was often asked to help fix.

And Thompsons lecture was followed, ten years later, by my April 1994 article, “Distributed Objects Form Info Highway Hazards”: although no longer online, so far as I can determine, that article was cited by another writer later that year in a still-accessible Defcon II conference paper on the nature of cyber-crime. My key point was that compound documents, with their invisible invocations of the applications that create their embedded objects, are constantly re-linking the users chain of trust through unknown participants: the expected results, I argued, were both local breaches of security and global surges of network activity.

Five years later, in April 1999, I suggested (in the wake of the all-too-predictable Melissa worm) that ease-of-use features in the then-forthcoming Office 2000 would further fuel the firestorm, with deadly combinations of features such as the Outlook preview pane and the incorporation of active content into HTML-formatted e-mail. Harried SCO Web site staff can only wish that Id been more successful in persuading people that our network-intensive applications need anti-lock brakes, so to speak, as well as automatic transmissions.

That ends this mornings history lesson, and I hope youll pardon the retrospective tone. Its hardly original to point out that most successful IT attacks involve long-known vulnerabilities, but this mornings headlines seemed to call for this review of both old demonstrations and newly disclosed examples.

I welcome your own war stories, cold or hot, at peter_coffee@ziffdavis.com.

eWeek Logo

eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site's focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.