Subject: RISKS DIGEST 9.88 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 2 May 1990 Volume 9 : Issue 88 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Booby-trapped contracted software (Tom Kopp) Death rate inflated in St. Bruno area, health report finds (David Sherman) Software Bug Causes Shuttle Countdown Hold at T-31 Seconds (Karl Lehenbauer) Criticism of "Glass Cockpits" (1) and (2) (Martyn Thomas) A320 Bangalore crash (Martyn Thomas) A320 criticisms reported (Martyn Thomas) Re: computer parks hundreds of cars illegally (Andrew E. Birner) (Apparently) widespread problem with census 800 number (Timothy M. Wright) Re: You think YOU have problems with your telephone company? (Chris Lewis) Telephone switch problems (Webber) White paper available: "Improving the Security of Your UNIX System" (Davy Curry) Virus found in a game software on the market (Yoshio Oyanagi) Re: Computers and names with special characters (Bandy) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.00 (j=0) ---------------------------------------------------------------------- Date: 1 May 90 03:07:07 GMT From: tkopp@carroll1.cc.edu (Tom Kopp) Subject: Booby-trapped contracted software A programmer from Waukesha Wisconsin (Name is in the article, I won't post it here) is to be charged with "destroying computer data" and causing damage in excess of $2,500. If convicted, maximum penalties will be 5 years prison, and $10,000 in fines. The programmer wrote the code such that he could shut it off at will in the future. The client refused to pay, so he killed the software. [Computerworld, 23 April 1990] ------------------------------ Date: Tue, 1 May 90 16:22:49 EDT From: dave@lsuc.on.ca (David Sherman) Subject: Death rate inflated in St. Bruno area, health report finds Toronto Star, May 1, 1990: Death rates in the St. Bruno school neighbourhood are not among the highest in Toronto, as city records previously showed, and in some cases are actually lower than the city-wide average. A study by city health officials says a "computer programming error" incorrectly inflated death rates in the area by almost 100%, causing widespread concern among residents.... Corrected figures show that 12 to 13 people per 1,000 die in the neighbourhood east of the school each year... Earlier statistics claimed 22 of every 1,000 residents in that area die each year, a rate almost three times as high as the city average.... The new report said an age factor was incorrectly fed into the computer calculations, lumping together all deaths of people over age 65.... St. Bruno was built on the site of a former steel plant. The site was also once occupied by the phototoxicology and radiation testing laboratory operated by the environment ministry. St. Bruno has remained closed since March, when teachers and students complained of unusual health problems, including six teachers who had developed fibroid tumours and three who had uterine cancer. Shortly after the school was closed, an incorrect report said the two census districts immediately east of the school ... had the second and third highest death rates in the city. ------------------------------ Date: 1 May 90 19:52:42 CDT (Tue) From: karl@sugar.hackercorp.com (Karl Lehenbauer) Subject: Software Bug Causes Shuttle Countdown Hold at T-31 Seconds According to Aviation Week (April 30, 1990, pg. 24), a software problem caused a three minute hold at T-31 during the launch countdown of the shuttle mission that orbited the Hubble Space Telescope on April 24th. At T-48 seconds, newly written software detected that the outboard external tank liquid oxygen fill and drain valve was open when it should have been closed. The ground launch sequencer (GLS) stopped the countdown clock at T-31 seconds. George T. (Ted) Sasseen, director of shuttle engineering, said that the software changes were made after an incident that occurred on April 2nd, where a pipe burst and sprayed water over a 4,000 volt motor control assembly, shorting it and causing the launch processing system (LPS) control room to go down, prompting concern that the LPS could lose power in the last few seconds of the countdown. Sasseen said that unless oxygen is drained within nine minutes after the flow is stopped, a phenomenon called "geysering" could rupture plumbing and destroy the tank. "So the fix was to put a purge in that [liquid oxygen] line and to put a small gas pad in it. We did that by hand after the inboard valve was closed and before the outboard valve was closed. The GLS sent its 'close outboard' command at 48 sec." He said that about 10 sec. after this happened, "everyone looked around and said, 'Oh boy. We were dumb.'..." Sasseen said the processing team violated one of its own cardinal rules that says: Never make a software change unless you can run it many, many times in simulations and tests. He said, "There are oddities about software changes that you don't always get the first time through. And the basic rule we violated is that it wasn't tested enough." He said the purge/gas pad software may be removed because it is unlikely that there would be a total launch processing system launch between T-31 sec. and T-0. "But I want to emphasize that the software safed the system as it was supposed to." To their credit, the system engineers were able to determine what the problem was and fix it within three minutes. A more cautious approach might have been to scrub the launch until a more careful analysis and review was performed. ------------------------------ Date: Tue, 1 May 90 12:40:06 BST From: Martyn Thomas Subject: Criticism of "Glass Cockpits" (1) A leaked copy of the draft report by the Air Accident Investigation Branch into the Jan 1989 737-400 crash at Kegworth, UK, criticises the ergonomics and user-friendliness of the CRT and LED display systems and engine instruments, according to Flight Int'l (May 2-8). The crash occurred after the crew shut down the wrong engine following vibration caused by a fan-blade failure. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. ------------------------------ Date: Tue, 1 May 90 12:47:44 BST From: Martyn Thomas Subject: Criticism of "Glass Cockpits" (2) Dr Roger Green, of the RAF Institute of Aviation Medicine, gave a lecture to the Royal Aeronautical Society in late April 1990 in which he said that operating in a digital "glass cockpit" increases the liklihood that pilots will not maintain an independent mental picture of systems status and flight profile - "always necessary for critical surveillance but also for dealing with the unexpected" according to Flight Int'l (2-8 May 90). This may have been a factor in the Korean Airlines KAL 007 navigation errors which led to it being shot down by the USSR. Green adds that cockpit ergonomics and instrument design are not subjected to such exhaustive testing as are airframes: "The rigour with which these things are evaluated leaves a lot to be desired". Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. ------------------------------ Date: Tue, 1 May 90 12:59:29 BST From: Martyn Thomas Subject: A320 Bangalore crash The report in Flight Int'l (2-8 May 1990) on the Bangalore crash makes very interesting reading. It is too detailed to summarise, and too long to post, but the account of the number of "flight modes" which the A320 went through in the two minutes before the crash, and the side-effects of each (which seem not to have been understood properly by the pilots) makes operating an A320 appear surprisingly complex and error-prone. It is certainly very different from flying a fully manual airplane, and the secondary effects (such as selecting a target altitude leading to the engines being retarded to idle, and needing several seconds to develop full power again) need to be well understood by the pilots. I recommend the report in Flight, and I hope that someone who understands the A320 systems is able to post an analysis of what went wrong to RISKS. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. ------------------------------ Date: Tue, 1 May 90 13:10:04 BST From: Martyn Thomas Subject: A320 criticisms reported Andrew McKechnie, in a letter in Flight Int'l (May 2-8) reports that the February issue of Log (the journal of the British Airline Pilots' Association) contains two observations on the A320 systems by an A320 pilot. "The author, who has experience of flying the A320, claims that the display of airspeed is less than compelling and also that he has 'experienced an occasion when the autothrottle made no attempt to hold a correct speed'." Comment by MCT: the latter point could be a misunderstanding of the active flight mode and therefore of the speed which the fly-by-wire system deemed to be correct. In other words, if the incident reported really occurred, it could be evidence of a technical malfuction OR it could be evidence of the pilot's difficulty in understanding what speed he/she had caused the computers to select as the target speed. In either case it is relevent to RISKS. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. ------------------------------ Date: Tue, 01 May 90 14:04 PDT From: ZENITH Subject: Re: (Not necessarily) computer parks hundreds of cars illegally I saw the TV reports (on the local NBC affiliate, Channel 5). I'd like to add a bit to what's been said so far about the (allegedly) undeserved parking tickets: 1) According to the news reports, the city blames the incident on human error--on the part of the officer issuing the ticket, the operator keying in the information, or both. This time (see below), they didn't try to call it a computer error; that designation came from those reporting on the story. 2) Illinois license plates indicate a registration type and plate number. Taxis have Taxi plates; the plate numbers end in TX, as well (e.g. 12345 TX). Livery vehicles have livery plates, with numbers ending in LV. State and local governments have their own plate types, as do some utilities. So, the same series of digits can appear on a large number of plates; other plate information must be used to distinguish among them. If the other information does not make it into the computer, for whatever reason, the ticket will be charged to the wrong plate; if the other information is garbled, the same will happen. I've had the misfortune to examine a number of parking tickets over the years; from what I've seen, the quality of the input documents (written in ink by an officer standing by the car, possibly in high winds and freezing rain) makes errors in transcription rather likely. 3) This is not the first time this has happened. Last time, back in about 1985, the city switched over to a ticket tracking system that didn't allow for a distinction among plate types. When the data from the old system was transferred to the new, information was lost; all Taxi, RV, Livery, etc. tickets were charged to the passenger plates with the same number. (The firm that got the contract was not based in Illinois; they had no idea what our license plates look like. If this sounds to the reader as though the contract should not have gone to this particular company, you are not alone; the FBI and several federal courts have agreed with you, if I recall correctly.) The details above are from memory; corrections and amplifications are most welcome. The opinions are mine; they do not necessarily correspond to those held by my employer or by any organization who might happen to forward my email. - Andrew E. Birner, Zenith Electronics Corp -- - ------------------------------ Date: Tue, 1 May 90 18:17:03 -0400 From: twright@ATHENA.MIT.EDU Subject: (Apparently) widespread problem with census 800 number The recent postings about the woman in Florida and the (possibly malicious) problems involved with her phones reminded me of problems of a decidedly non-malicious problem I had involving the Census Bureau's toll free system. Each census form sent by the Bureau of the Census was contained in an envelope on which was printed a toll-free number to call in case of any questions (800-999-1990). I had a relatively simple question, and found that one of two things happened on the 100 or so times I tried the number: either (1) a busy signal (the usual result); or (2) a few rings, a few rings (pitched slightly higher), then a click, and finally a connection, to another person with a question! The second case happened twice: both the other party and myself were rather confused for half a minute or so. I finally did get through to an actual Census employee, and I relayed my problems with the phone system to her. She replied that other callers had relayed similar problems. I wonder if the Bureau of the Census will fix its phone system in the next ten years. --timothy m wright--gradual student, political science, MIT ------------------------------ Date: Tue, 1 May 1990 16:21:09 -0400 From: clewis%eci386@uunet.UU.NET (Chris Lewis) Subject: Re: You think YOU have problems with your telephone company? One particular scenario which is worth considering is that of intentional sabotage by active insiders. A few years back a new large telephone switch was installed in a very high profile site to serve as a demonstration of technological achievement and to garner additional sales. The switch was plagued for many months with severe problems, most along the line of partial or complete service failure, and occasionally bizarre behaviour. Made the papers many times... Rather embarassing to say the least. Naturally, the service provider was concerned, and involved the switch manufacturer who spent many months (and millions of dollars) analysing the hardware and software, involving both the original R&D organization and outside consultants to try to establish a cause. All to no avail. It wasn't until the manufacturer slipped in one of their own personnel into the on-site maintenance crew (the provider was refusing to permit this) that the problem was resolved: one of the service provider's onsite people was intentionally shorting out signals (amongst other things reasonably difficult to pinpoint after the fact). Sorry to be so cagey. I understand that most of this has been documented in the press, but I'm not absolutely certain of the precise details, nor wish to subject the companies involved with further embarrassment. Especially since I don't know whether or not the person was charged, what with, nor whether it was successful, nor why he was doing it in the first place. You may wish to treat this story as totally apocryphal, that's up to you, but a scenario of active inside sabotage is certainly possible and should be investigated by your contact's phone service. Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis ------------------------------ Date: Mon, 30 Apr 90 12:20:58 EST From: webber@psych.toronto.edu Subject: Telephone switch problems My recollection of this is fuzzy, but the recent discussion of telephone switch problems eventually reminded me of some major problems experienced in Ottawa at an early Bell Northern installation. Large numbers of telephone misfunctions developed at this showcase operation, but I believe they were eventually traced to the actions of a disgruntled former employee. I believe he was entering the equipment room and shorting conductors together. I'm sure that some Bell Northern folk who read RISKS are better informed than I on this matter; perhaps some of them could comment? ------------------------------ Date: Tue, 01 May 90 19:22:29 PDT From: davy@itstd.sri.com Subject: White paper available: "Improving the Security of Your UNIX System" A new white paper from SRI International's Information and Telecommunication Sciences and Technology Division is now available. The paper, "Improving the Security of Your UNIX System," describes measures that you as a system administrator can take to make your UNIX system(s) more secure. Oriented primarily at SunOS 4.x, most of the information covered applies equally well to any Berkeley UNIX system with or without NFS and/or Yellow Pages (NIS). Some of the information can also be applied to System V, although this is not a primary focus of the paper. An abbreviated Table of Contents: 1. INTRODUCTION The Internet Worm, the Wily Hacker, other break-ins 2. IMPROVING SECURITY 2.1 Account Security Passwords, expiration dates, guest accounts, group accounts, Yellow Pages 2.2 Network Security Trusted hosts, secure terminals, NFS, FTP, TFTP, mail, finger, modems and terminal servers, firewalls 2.3 File System Security Setuid shell scripts, sticky bit on directories, setgid bit on directories, umask values, encrypting files, devices 3. MONITORING SECURITY 3.1 Account Security lastlog, utmp, wtmp, acct 3.2 Network Security syslog, showmount 3.3 File System Security find, checklists, backups 3.4 Know Your System ps, who, w, ls 4. SOFTWARE FOR IMPROVING SECURITY 4.1 Obtaining Fixes and New Versions Sun fixes on UUNET, Berkeley fixes, SIMTEL-20 and UUNET, vendors 4.2 The npasswd Command 4.3 The COPS Package 4.4 Sun C2 Security Features 4.5 Kerberos 5. KEEPING ABREAST OF THE BUGS 5.1 CERT 5.2 DDN Management Bulletins 5.3 Security-related mailing lists 6. SUGGESTED READING 7. CONCLUSIONS REFERENCES APPENDIX A - SECURITY CHECKLIST In order to format the paper, the "troff" text formatter and the "-ms" macro package (available with any Sun or Berkeley UNIX system) are required. You *do not* need a PostScript printer, unless you want to print the cover page with the SRI logo on it. The paper is available via anonymous FTP from the host SPAM.ITSTD.SRI.COM (128.18.4.3) as the file "pub/security-doc.tar.Z". Be sure to remember to set "image" mode on the transfer. Sorry, UUCP access is not available - if you don't have Internet access, find a friend who does. Enjoy. Dave Curry SRI International Information and Telecommunications Sciences and Technology Division 333 Ravenswood Avenue Menlo Park, CA 94025 (415) 859-2508 davy@itstd.sri.com [Many thanks, Davy. This is a goody. PGN] ------------------------------ Date: Wed, 2 May 90 22:26:08+0900 From: Yoshio Oyanagi Subject: Virus found in a game software on the market VIRUS FOUND IN A JAPANESE GAME SOFTWARE ON THE MARKET Yoshio Oyanagi University of Tsukuba, Japan Newspapers reported on April 24 that a virus was found in a simulation game software "FAR SIDE MOON" (9500 yen) for Sharp personal computer X68000. It has been sold by Artdink Inc. since April 13 in Japan. The virus was detected by Computer Virus Institute (Takao Yamamoto, director) of Federation of Japanese Computer Clubs. According to Yamamoto, this virus is programmed so that it keeps inactive until July and after that data on floppy or in the computer will automatically be erased whenever one switches on the computer. So far 3000 sets have been sold, among which half are contaminated. It is conjectured that the computers in Artdink Inc. are invaded by the virus while developping the game software. Today (May 2) Asahi Shinbun (one of the major daily newspaper in Japan) disclosed that it succeeded in making contact with one of the virus makers. According to the report, the maker is a high school boy of age 17, who lives in Kagawa prefecture. Forty people collaborated in making the virus and got several tens of thousand yen (several hundred dollars) for each from the client, who ordered through PC network for hackers. The virus program was completed in three months and distributed secretly since last September. Federation of Japanese Computer Clubs told that there have been two viruses (viri?) for X68000, named "Namba I" and "Namba II". "Namba I" becomes active on July 4 this year and it deletes data on the computer or foppy disks. If the computer is contaminated with both "Namba I" and "Namba II", some X68000 do not accept any floppy after 0:00 May 2. The federation has developped a vaccine and distributing it among PC shops and users. If, however, a computer is contaminated with both viruses, it does not even accept the floppy disk of the vaccine. In this case, user should bring the computer to the maker and ask to change the parts. (crossposted to comp.risks and comp.virus) ------------------------------ Date: Tue, 1 May 90 10:24:59 PDT From: bandy@capmkt.com Subject: Re: Computers and names with special characters (Hoffman, RISKS-9.85) >... Univac/Sperry/Unisys computers, I ought to change my name to @FIN Or perhaps @@term ? If I remember correctly the double master space character can appear anywhere in a line... ------------------------------ End of RISKS-FORUM Digest 9.88 ************************