There was no source to peruse, so the Open/Closed source argument is bogus. This was a "binary" hack - he hacked his own copy of the compiler source to include "I'm compiling the login program" identification that injected the back door code into the login executable, AND he added "I'm recompiling the compiler" identification that reinjected the entire hack into the compiler output. He then built the hacked compiler, installed it, and removed all his source code. From that point, anyone who used his compiler executable to compile either the login program or the compiler would get a hacked executable. Once he installed his hacked compiler into the common build environment, everyone was "infected", because everyone ended up using the hacked compiler executable to bootstrap a new system.

Just a thought on what O'Dowd had to say.
The backdoor into Unix was in the binary unix code. At the time, Unix was a closed source, proprietary product.
In fact Ken Thompson's action demonstrates the insecurity of closed source proprietary code, rather than any failing of the open source methodology. O'Dowd's assertion "without demanding proof that it contains no subversive or dangerous code" says it all.
No such proof is possible when closed source code is used. Every single line of code in open source can be read by the user and compiled by the user themselves(including the compiler), ie this is the highest trust possible, only binary code produced by the end user is used in the end users system.

Biased opinions are such - biased.

For mission-critical applications, e.g. defense, nuclear or medical usage, audits must be done. This must apply to any products being selected for usage, be it open-sourced or closed-sourced.

The advantage of open-sourced products of "many eyes", as the article author will have it - remains. How many eyes see the codes of the closed-sourced software? Any how many eyes for the open-sourced?

"demanding proof that it contains no subversive or dangerous code". Are you going to accept the proof without any work (read, audit) on your part, O'Dowd?

And who equated closed-sourced products with "trusted code"?! You're probably doing so, O'Dowd.

Ken Thompson's time was before the advent of the Internet, when so many eyeballs and brain sacks are now being brought together. Basing an entire speech on "one exception to the rule" exhibits narrow-mindedness.

IMHO

You idiots don't get what Ken T was saying. It's that distributing hacked tools permits a hacked end binary. Seeing the source of the end binary doesn't do squat.

You guys should go back to your H.S. lessons and leave programming to the pros.

what the hell is this guy talking about. can't you read the linux source code and make sure it has no such code that can be compromised!! bozo.

So he's noting that Thompson added a back door in the UNIX binaries. Well, if you had the source, you'd not have needed 14 years and a confession to figure that out would you?

O'Dowd does not seem to understand the process by which new code is contributed to open source projects. All code has an owner who serves as a gatekeeper and must approve any code that is added to the official tree. I suppose it's possible for a nefarious individual to get into that role, but it's just as possible for that nefarious individual to get a job at a company that provides proprietary software where a security vulnerability or worse could be planted.

One could also paint an Orwellian fantasy about how a single operating system that is being used universally could be used as a tool of a totalitarian government to gain hegemony.

The threats Mr. O'Dowd points out should be considered seriously but chosing proprietary rather than open source software is not the solution.

Here is my counter attack to the authors obvious troll.

A recent Cisco security advisory announced that “all models” of their WLSE and HSE wireless LAN devices have a hard-coded back-door password which gives an attacker complete control over that section of your infrastructure.

Firstly, it is to Cisco’s credit that they follow a policy of openly announcing such an embarrassing vulnerability. Many providers prefer to hide their problems, fold any fixes into routine updates and hope their customers pick up those updates before any malefactors pick up control of the customers’ networks, which in this age of several probes per internet address per minute is totally unacceptable.

However, one sentence in the advisory is very unsettling to me as an extensive user of Open Source products: “There is no workaround.”

Open Source policies not only reduce the risk of back-dooring by empowering customers and potential customers to audit the software themselves, but they also reduce the incentive for back-dooring by making it more likely that any perpetrator will be caught, and in that event “everybody” would know what and how that had been done by whom. Consequently, back-dooring in serious Open Source projects is very rare.

Even more attractive from a security perspective is that because all of the parts are to hand, each customer would have been in a position to work around the issue by simply lopping out the offending code on the spot and deploying an updated version of the software within a matter of hours, sometimes minutes. This can be critically important for customers who prize security above all else.

Open Source projects also have a good track record for prompt security responses. The KDE team, for example, once delivered a secured version of their SSL transport within a hundred minutes of being made aware of an issue. Part of this responsiveness is simply the absence of corporate red tape, and part of it is the pointlessness of trying to hide or deny a problem for publicity damage control reasons when the whole world can check for themselves.

To read more about how secure open source is, please go to http://www.theage.com.au/articles/2004/04/09/1081326916427.html

Ken Thompson's compiler trojan scenario can by greatly mitigated by cross vendor bootstrapping.

http://groups.google.com/groups?selm=slrna4f868.7gd.heretic@heretic.ihug...
Other than manual inspection of the resulting compiler binary, a solution
for this is too use many third party C compilers and enviroments for the
original bootstrap compiler build and compare the resulting code after
the resulting compiler has rebuild itself for the third time. If the
result greatly differs then manualy inspect the generated code where
it differs.

Folks: Ken Thompson wrote that it is possible to trojan a compiler that way. He never wrote that he actually did this (and for the whole time since 1970? When was the first C compiler written? Was there ever a "login" program back then?)

Dear Mr. O'Dowd should get his facts straight first.

Ken Thompson's scenario deals with a poisoned compiler. The way to get around this is to originally/occasionally build the gcc compiler from a completely independently created (perhaps even a comercial) compiler, and confirm that the output of this process is identical to using the 'standard' compiler shipped with the distribution. This would confirm that the toolchain is poison free. This should probably be done once by each distribution maker when they build the final 'gold' distribution from scratch.

In "Reflections on Trusting Trust", Ken Thompson talked about this - back in August 1984.

Here's what he wrote in full:

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.

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.

This is why you have SELinux, "Security-Enhanced Linux" - hardened by the NSA

O'Dowd's getting run over by a free and agile OS, that's all.

Dan O'Dowd is President and chief executive officer of Green Hills Software - which sells compilers and RTOS for embedded systems. No wonder he does not like Linux!! I'm not saying his opinions are valueless, or that they should simply be dismissed. But it's worth bearing in mind that Green Hills develops software that Linux is directly competing with: embedded operating systems.