18-Feb-87 21:15:21-PST,16123;000000000000 Mail-From: NEUMANN created at 18-Feb-87 21:14:07 Date: Wed 18 Feb 87 21:14:06-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.48 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Wednesday 18 February 1987 Volume 4 : Issue 48 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Four near air misses in 1986; Radar failure (Lindsay F. Marshall) Computer failure causes flight delays (Rodney Hoffman) Real RISKS (as opposed to virtual risks) of aircraft (Eugene Miya) Trojan Horse alert (Al Stangenberger) Computerized Town Data Vanish (Jerry Leichter) Re: UCSD work on human error (Alexander Glockner) Connector risk (Rob Horn) Re: Electronic steering (Brint Cooper) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- From: "Lindsay F. Marshall" Date: Wed, 18 Feb 87 10:11:29 GMT To: risks@csl.sri.com Subject: Four near air misses in 1986 From the Observer 15th Feb 87: 17 March 86. A crowded One-Eleven jet and a Short 330 commuter aircraft descend to land simultaneously on Aberdeen's single runway. The jet screams over the top of the slower plane, cuts through its descent path, then aborts landing, narrowly averting catastrophe. An Aberdeen radar controller is blamed. 28 November 86. An Iran Air jumbo jet is told to stay at 6,000ft but instead climbs and almost collides with an Air UK Fokker F27 in holding stack over Heathrow. The Iranian crew's poor English makes analysis of the incident impossible. 13 December 86. Over Detling, Kent, a Britannia Airways 737 from Luton to Munich comes within half a mile of a One-Eleven bound for Amsterdam from Gatwick. The controller handling 14 aircraft simultaneously, had forgotten the 737's existence. 22 December 86. A British Midland One-Eleven en route from Heathrow to Leeds is instructed to climb to 28,000ft. Over Cranfield, Bedfordshire, it passes a United States Air Force KC135 tanker aircraft crossing the airway at the same altitude. The pilot of the passenger jet takes evasive action. A trainee controller had forgotten the presence of the military jet. ------------------------------ From: "Lindsay F. Marshall" Date: Wed, 18 Feb 87 10:11:58 GMT To: risks@csl.sri.com Subject: Radar failure (From the Observer 15th Feb 87) At 6.30 a.m. on 15 November 1986 the London Air Traffic Control Centre (LATCC) at West Drayton suffered a total loss of main power as the morning rush of flights began. A standby generator also failed. Radar screens covering Wales and England south of Newcastle went blank. The IBM 9020 computer shut down, halting updating of flight progress strips. Controllers had to revert to writing strips manually. Radio contact with aircraft was precariously maintained by a battery supply with a life of 30 minutes. Pilots continued to fly in the busy airspace without radar by scrupulously maintaining their separation from other planes. But without radar monitoring by controllers on the ground little could have been done if a jet had strayed. Power was restored five minutes before the batteries gave out. The fault was blamed on a freak sequence of events started by the failure of a small capacitor. Managers were eager to clear the backlog of flights but the computer would not function normally. It displayed some radar blips but not others. The LATCC controller said: 'We were pushed to handle more aircraft but refused because the computer could have gone down at any time. 'There were many near misses that morning, all due to equipment failures. We were lucky. If the same sequence of events occurs in the summer, the effect does not bear thinking about.' ------------------------------ Date: 18 Feb 87 08:06:35 PST (Wednesday) From: Hoffman.es@Xerox.COM Subject: Computer failure causes flight delays To: RISKS@CSL.SRI.COM Excerpted and edited from the Los Angeles Times, Feb. 15, 1987: FLIGHT DELAYS LAID TO COMPUTER MALFUNCTIONING By Dean Murphy Flights from airports throughout Southern California were delayed during most of the day on Friday because of a 30-minute early morning computer failure at the Los Angeles Air Route Traffic Control Center at Palmdale, according to Federal Aviation Administration spokesman Russ Park. A backup system was activated 14 minutes after the outage. The aging computer, known as the 9020, has been the source of numerous controllers' complaints, and is expected to be replaced later this year. It provides information abot the flight plans of aircraft over a 180,000-square-mile area of Southern California, southern Utah, southern Nevada and western Arizona. Palmdale controllers give flight instructions to pilots while they are flying above 10,000 feet between areas that are covered by controllers at individual airports. The 9020 failed 12 times during the last six months of 1986, with an average failure time of about four minutes. The outage Friday forced air traffic controllers to ground flights for 15 minutes during the morning rush period at airports throughout the area. Combined with heavy air traffic and rainy weather, delays continued through much of the day. Airport and airline spokesmen said that most of the delays were minor, describing the situation as more of an irritation that a significant disruption in service. The outage posed no safety hazard to passengers. Controllers lost flight plan information -- including such things as the flight number, altitude and airline of each flight -- during the 14-minute transition to the backup system, but they were able to continue tracking the planes on radar screens. -- Rodney Hoffman ------------------------------ Date: Tue, 17 Feb 87 18:23:18 pst From: eugene@AMES-NAS.ARPA (Eugene Miya) To: risks@sri-csl.ARPA Subject: Real RISKS (as opposed to virtual risks) of aircraft Been some time since I've sent something in, but Alan Marcum brings up some good issues with respect to flying aircraft. Alan brings up some good buzzwords like a systems approach to training. What does this really mean? You don't want a pilot doing "long-hand" reasoning as the plane is falling out of the sky. This is not to say they are reading paper when they are going down either. Pilots get a systems approach (so believed right now), but it is not clear what they don't need to know. A friend at the MVSRF (featured in the Nova episode for NASA/Ames) pointed out in a local meeting at PARC a couple of months back that checklists are written in blood. (Obviously dramatic, but true.) I have also learned in recent days that war gaming and battle management can be regarded as `batch' rather than `interactive' in nature. There are those local `interactive' things called "engagements," but good commanders set up battles months and weeks in advance to anticipate the widest variety of contingencies, and not to fight or fly "on the fly." This is part of why checklists exist. They are hardcopy versions of our memory. They don't forget, or suffer interference. We try to think of contingencies before they exist. Sure, they are hardwired, and have lots of problems, and there are people doing research on check lists here and other places. Yes, if we get lax because of computers, this is a computer associated risk. The human factors people have done LOTS of work to differentiate knobs in planes. If we computer people fail to do a similar job with software (as an example), then we will kill people. --eugene miya, NASA Ames Research Center p.s. would you trust your life to any single line of code you wrote? think about it, before answering. I've worked on flight (space) projects, but not man-rated, don't know if I could. ------------------------------ Date: Mon, 16 Feb 87 15:58:01 PST From: forags%violet.Berkeley.EDU@berkeley.edu To: risks@csl.sri.com, trojans@violet.berkeley.edu Subject: Trojan Horse alert (from mod.computers.ibm-pc) ... This one could be serious, given the popularity of PC-Write. Al Stangenberger, Forestry, U.C. Berkeley Date: Thu, 12 Feb 87 11:12:22 EST From: "Peter J. Laughton" Subject: PC-Write Trojan Horse In light of the announcement of PC-WRITE availability to Info-IBMPC readers (volume 6, issue 8), I considered that it would be valuable to share the following warning: ---------------------------------------- TROJAN HORSE ALERT: BOGUS PC-WRITE 2.7x ---------------------------------------- The latest INFOWORLD (02/09/87) reports the discovery of a bogus version of PC-WRITE. Tom Wilkinson, the sysop in Los Angeles who discovered it says "the trojan version when invoked, destroys the file allocation table of a user's hard disk, and initiates a low level format, destroying the hard disk's data." The bad version pretends to be the latest version, PC-WRITE 2.71 and is 98,274 bytes long. The real version of 2.7 is 98,242 bytes long, and the real version of 2.71 is 98,644 bytes. Wilkinson says the version posted on Compuserve is the real version. INFOWORLD reports that "Quicksoft, PC-WRITE's developer, is offering $2500 reward for the first person who identifies the creator of the bogus program and a $5000 reward for the person who provides proof that convicts the perpetrator." Don Richardson, 02/10/87 From: jam@mitre-bedford.ARPA According to Quicksoft, the publisher of PC-Write, the latest version is 2.71. Version 2.72 is a hack containing a booby trap, and trashes hard disks. BEWARE! Version 2.71 is a minor update of 2.7. They will not release a version 2.72. They are trying to notify bulletin boards of the existence of the bogus version, but are walking a thin line: they don't want to scare people away from PC-Write. I use version 2.7 and like it a lot. Joshua Morris, jam@mitre-bedford ------------------------------ Date: 16 FEB 1987 13:04:53 EST From: To: risks@csl.sri.com Subject: ``Computerized Town Data Vanish'' (From the Sunday 15 Feb 87 New York Times) Prescott Valley, Ariz., Feb. 14 (AP) -- All the computerized financial records of this Rocky Mountain community have been erased, leaving officials with no idea how much money has been spent this year or how much cash the town has left. Mayor Phil Beeson told the Town Council on Thursday that the account shows a balance of zero. He called it "positively a case of deliberate attack." Lyn Newton, assistant town clerk, said Friday that there is "strong circumstantial evidence pointing to one person" whom she would not identify. Ms. Newton said she discovered the problem over the weekend as she began closing out the books for January for the town of 2,700 residents. "All our expenditure accounts and all of our revenue accounts were erased," she said. "The thing that scared me so badly is that we have no valid means of knowing where we are. By the time this was discovered, we could have been way over budget." The records apparently were erased sometime between Jan. 1 and last week, Ms. Newton said. They can be reconstructed, she said, but the task will be time consuming and expensive and will be complicated by the fact that the town manager, assistant town manager and town clerk all left office in recent weeks. And, she said, it is time to begin preparing next year's budget. ------------------------------ Date: Mon, 16 Feb 87 23:12:23 pst From: sdcsvax!beowulf.UCSD.EDU!glockner@ucbvax.Berkeley.EDU (Alexander Glockner) To: CSL.SRI.COM!RISKS@sdcsvax.sdcsvax.ucsd.edu Subject: Re: UCSD work on human error (RISKS DIGEST 4.47) Organization: EE/CS Dept. U.C. San Diego Regarding the UCSD work on human error mentioned in the last line of the most recent risks digest: Donald Norman (norman%sdics@sdcsvax.ARPA) is the investigator who has done the most work here on the subject. ------------------------------ Date: Mon, 16 Feb 87 17:57:08 est From: wanginst!infinet!rhorn@harvard.HARVARD.EDU (Rob Horn) To: risks@sri-csl.arpa Subject: Connector risk The growing popularity of using the RJ series connectors (aka `telephone modular jacks') for terminal cabling is exposing a lot of people to a major risk. These jacks are directly interchangable with normal telephone jacks, and you can be sure that people will make mistakes and plug terminals into telephone equipment. This can do tremendous damage, and may even pose a health risk. When a telephone rings, the ring signals are a pulsed DC that can reach as high as 150 volts! In terms of vaporized semi-conductors, this is just as destructive as plugging your connector into an electric outlet. The frequency, voltage, and power don't quite match standard electric power but they are more than enough to totally destroy any unprotected electronics. The health risk arises from the potentially poor grounding of the digital electronics. These circuits are not normally designed to be safe with 150 volts on them. This risk may be shortlived since the digital circuit will quickly self destruct. Telephone extension cables with RJ connectors pose a greater hazard. When the phone rings there is high voltage on that connector. If a child is chewing on it when the phone rings there is a real risk of death from electrocution. (The hazard to adults is lower since they don't normally chew on cables, and the power levels are low enough that the odds are in favor of a nasty jolt instead of fatal one.) Beware of using these connectors in inappropriate circumstances. (I was warned quite thoroughly by our Mechanical Design people when I suggested it. I learned then for the first time that telephones are not UL approved, nor will they ever be, because of this 150 volt risk.) Rob Horn UUCP: ...{decvax, seismo!harvard}!wanginst!infinet!rhorn Snail: Infinet, 40 High St., North Andover, MA ------------------------------ Date: Tue, 17 Feb 87 9:30:06 EST From: Brint Cooper To: risks@csl.sri.com Subject: [Amos Shapir: Re: Electronic steering] The following makes me wonder why no widespread concern exists about failure of "conventional" power steering and brakes when an auto engine dies. I have had both experiences, fortunately without accident, and they are frightening. If we haven't worried about that risk, will we collectively worry about the risk of an electronic system failure? _Brint > From: Amos Shapir > In RISKS-4.46 Steve McLafferty writes: >The killer (pun intended) is the electronic four-wheel steering. There is >no mechanical connection whatsoever between the steering wheel and the >steering gearboxes! I really hope that scheme never makes it to production! Last time I heard, power steering and brakes are designed in such a way that even when all power is lost, the driver can still control the car and stop manually. Amos Shapir ------------------------------ End of RISKS-FORUM Digest ************************ -------