Path: utzoo!utgpu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!ncrcae!opusc!ken From: ken@opusc.csd.scarolina.edu (Ken Sallenger) Newsgroups: alt.sources Subject: Re: GENERAL WARNING Summary: Another example Keywords: trapdoors in distributed binaries Message-ID: <1990Oct1.192920.679@opusc.csd.scarolina.edu> Date: 1 Oct 90 19:29:20 GMT References: <1990Sep29.004107.17548@metro.ucc.su.OZ.AU> Organization: Univ. of South Carolina, Columbia Lines: 37 In article <1990Sep29.004107.17548@metro.ucc.su.OZ.AU> glenn@suphys.physics.su.OZ.AU (Glenn Geers) writes: => => What about vendors deliberately putting trap-doors in their distributed => binaries? We have a rather advanced, esoteric parallel machine on campus. When it was first installed, a group of 6 programmers and systems types, along with a couple of faculty researchers, were the primary users for the first few months. It only took about 6 weeks for one of us (yes, I confess, it was I) to type "xyzzy" to the command interpreter prompt, just to see what would happen... The system halted, and the user who typed it was thrown into the diagnostic ROM monitor. I should point out that the account from which the magic cookie was issued had every privilege that an account could have. One almost didn't need to use the root account with all those priv's. The trapdoor was put there by the primary developer of the system (a high-powered hardware engineer who also happened at the time to be CEO of the company :-) and well, they never had gotten around to taking it out. The Customer Service type to whom I reported it couldn't believe what I was telling her at first. And she couldn't imagine why anyone would type "xyzzy" to a shell prompt in the first place! I guess she hadn't hung out with too many software hackers. Come to think of it, I don't know whether they ever _did_ get around to taking that out... -- Ken Sallenger / ken@bigbird.csd.scarolina.edu / +1 803 777-9334 Computer Services Division / 1244 Blossom ST / Columbia, SC 29208