Subject: RISKS DIGEST 13.27 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Saturday 7 March 1992 Volume 13 : Issue 27 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Re: Michelangelo reports (Robert Slade, Bill Murray, David Leslie, Brandon S. Allbery) (Mis)perceptions of RISKS (Steve Strassmann) Re: Lap Mice (Steven Wilson, Bill Murray, Robert L. Smith) RISKS in the news -- recharging portables (Stephen C. Woods) Re: A RISK architecture? (DEC's Alpha, IBM 360/91) (Andrew Klossner, John R. Levine, Melvin Klassen) Electronic privacy in California (Phil Agre) Re: 1-900 spelling game (David C. Martin) Re: A320 (Paul Wallich) Re: 7-character PO key (Jonathan Griffitts) 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. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Sat, 7 Mar 1992 22:49:30 GMT From: rslade@sfu.ca (Robert Slade) Subject: Initial Michelangelo reports (first cut) To all who sent in reports, many thanks. A brief report on today (and recent past) sightings: New Zealand - our two best contacts evidently did their job well, and had clean shops. Other areas reported a "detection rate" (in advance of the deadline) of 10% in some areas. Japan - MITI had stated earlier in the week that Japan would not be hit as it didn't use MS-DOS much. MITI, and seven other companies, reported hits today. (MITI only reported one.) China - announced hits in spite of official claims of "about 10" reported occurrences. Poland - earlier in the week was reporting detection rates of as high as 25% Germany - reported heavily hit by CBC, conspicuous by the absence of reports from Vesselin. Too busy? :-) South Africa - reported by CBC to have had 1300 hits. US - New Jersey Institute of Technology reported to have cleaned 2400 of 3000 computers earlier this week (est. cost = $60,000, mine) - largest oil company in Houston, and 200 small to mid sized businesses (est. cost for recovery of computers, assuming backup, $2M, mine) - eastern university reporting a couple of hits Canada - major metal supplier "tested" for the virus by playing "Michelangelo roulette" (setting date ahead to Mar. 6) late last night, lost that machine and cleaned up the rest. Two Baptist churches reported hit in the Vancouver area. Local school board found a copy on one machine, tested on old machine, did not trigger, figured Mikey was a hoax. (Any bets the test machine was a really old XT? Wonder if they got hit and are now lying low.) UofA reports one hit (good work, Tim), NRC reports four disks cleaned. In other news: McAfee is quoted as saying clocks on machines that triggered on Thursday (a fair number of reports of that) were set ahead by "accident". No one is reporting the significance of the leap year. A number of reports of users playing Michelangelo roulette, including one that lost a full 170M hard disk (170 "shelf feet" of printout, gone). Another found the virus, tried to disassemble it with DEBUG, and triggered it. A number of reports of CLEAN and the NAV Special Edition "damaging" disks and partitions. No report of the fact that NAV Special does not check for any other virus. (CPAVSE checks for some "Friday the 13th" families, at least.) Very few reports of the upcoming Thursday the 12th, Friday the 13th, Saturday the 14th, Maltese Amoeba next week. Story of the year: One user supplied a copy of a detection program to his sister, who found the virus at the radio station where she worked (in Quebec). He called the corresponding station nearby, and offered to scan their computers. They turned him down, stating they were sure they did not have the virus. This morning, they powered up and lost the hard drive. Sorry for typos and terse style, trying to keep up and get reports out at the same time. Vancouver Institute for Research into User Security Canada V7K 2G6 rslade@cue.bc.ca Robert_Slade@sfu.ca CyberStore Dpac 85301030 PS - latest reports, John M. estimating 10,000 hits world wide, one newswire carrying estimate of 400,000 in US. Shall we start the Mikey ------------------------------ Date: Sat, 7 Mar 92 09:44 EST From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Measuring Michelangelo ... I suspect that we will detect and eliminate far more copies of other viruses than of Michelangelo. The sense of urgency generated by Michelangelo's trigger date (I received calls right up to midnight on the 5th) has resulted in the purchase, use, and, I hope, permanent installation of a great deal of anti-virus software. How many more copies might we have eliminated if our advice had focused on infected diskettes as much as it did on infected machines. Unfortunately, we have not stamped out viruses. We will have such an opportunity again. I suggest that the next time we have the public's attention, we focus on diskettes. It is diskettes that hold the majority of the copies of viruses and it is on dikettes that they are most persistent. Later in his posting, Joe Abernathy asks for reports of Michelangelo. I expect those to be sparse. (Joe, add Hoyt Limousine of New Canaan to your list (I got that report as a customer, not as a consultant)). I think that the estimates of the number of copies that Michelangelo achieved in a year were generally exaggerated, and the purge more effective than I would have hoped. I do not begrudge the bold and brave entrepreneurs that gave us the software their sales. I think that the press coverage was at least partially motivated by a spirit of public service. But by any count, the security costs of Michelangelo will be much higher than the cleanup, and mammoth by any measure. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769 ------------------------------ Date: Sat, 7 Mar 92 15:24:00 PST From: dleslie@phakt.usc.edu (David Leslie) Subject: MichelAngelo virus less a risk than Norton As the hype surrounding the MichelAngelo virus reached a peak, Norton released a 'special' version of its virus utility (free of charge) to the public. This special version was limited to check and remove the MichelAngelo virus. Unfortunatly for myself and many others who received this software, it turns out to be more dangerous than the virus. If you use the norton utility to remove the virus from a harddrive with more than 1 partition, you may very well lose all but the first partition. I believe this may have something to do with using alternate filing systems. We lost 3 40 meg partions(d:,e:,f:). I have heard as many reports of people losing partitions due to Norton as to MichelAngelo. Beware of the undocumented 'features' of the Norton virus utility :( David Leslie dleslie@girtab.usc.edu ------------------------------ Date: Sat, 7 Mar 92 14:24:33 -0500 From: allbery@ncoast.org (Brandon S. Allbery KF8NH) Subject: Re: Michelangelo (Mainwaring, RISKS-13.26) | Even worse, will people assume that once they have scanned their disks | for Michelangelo, that the threat is over? After all, the fuss has | quieted down. Why should it be necessary to do it again? Worse, the media blitz left out information that caused companies to lose time due to unnecessary fear of the virus. One of our customers refused to bring up his computer on Friday out of fear of the virus; he knew enough to know it was an Intel 386-based computer, therefore it "must" be vulnerable. The computer in question was an Altos Computer Systems, Inc. 386/2000. It is completely incompatible with MS-DOS and does not possess a BIOS --- it has a bootstrap loader/monitor and self-test facility in ROM, and nothing else. If someone were to attempt to boot an MS-DOS diskette in it, it would read track 0, not find the information required by the 386/2000, and reject the boot attempt without executing any code off the floppy. And even if someone managed to fake a 386/2000 signature, the first attempted BIOS call would cause an immediate dump into the monitor with an undefined interrupt. And an attempt to access the disk controller directly would find nothing whatsoever, as the disk controller is accessed entirely differently. For all that it's the right processor, the Micheelangelo virus ad as good a chance of infecting a Macintosh as it did this system. Other customers on 386-based Series 1000 and 2000 machines were also worried, although none took it to quite the lengths that that one customer did (a phone call was sufficient to reassure the others, although some of them waited until noon to call). I didn't hear about any calls from users of Altos 8086 or 80286 machines, which are also incompatible. So how many other companies needlessly lost the use of their computers? The RISKs of a computer virus are not limited to the systems it infects. Brandon S. Allbery, KF8NH [44.70.4.88] Senior Programmer, Telotech, Inc. ------------------------------ Date: Fri, 6 Mar 1992 20:34:12 -0500 From: Steve Strassmann Subject: (mis)perceptions of RISKS (Mainwaring, RISKS-13.26) 2. Macintosh users have such a frightening virus problem already that there are very few left who don't routinely disinfect their machines. I can't imagine where you got this idea. While perhaps 1000 or more viruses affect DOS, there are exactly 10 known viruses affecting Macs (plus one that affects only Ataris in Mac emulation mode), No known Mac viruses are explicitly malicious like Michelangelo. While new DOS virus strains appear at a rate of several per week, the last new Mac virus appeared after a hiatus of almost two years. To say that Mac users have a "frightening virus problem" is utterly irresponsible. The popular press, in giving the impression that all computers are susceptible to DOS viruses, is not much better. Perhaps Macintosh users do take better care of their machines, but I imagine it's because it's easier to do so. Steve Strassmann, PhD straz@apple.com Apple Computer Avanced Technology Group Cambridge, Mass. ------------------------------ Date: Sat, 7 Mar 92 09:43:52 PST From: stevew@netcom.com (Steven Wilson) Subject: Re: Lap Mice (Bartlett, RISKS-13.26 [sic]) This is in response to John Bartlett's post concerning mice employed on a Lap Top during a flight. John is mistaken in saying that there is no difference between an internal mouse and one connected via cord. Depending on whether the cord is shielded properly and how the connection is made to the PC the unit can act just like an external antenna for all the RF noise that the computer is capable of generating. The computers themselves have probably been qualified with specific I/O devices to comply with FCC class B standards concerning RF radiation. Further, American probably has determined that flight instrumentation can safely handle that level. It has also probably been determined that some mice on some systems do indeed result in radiation from the unit above Class B levels that could be harmful thus the flat-out ban. They don't do it by manufacturer type(to hard to enforce). Does anyone know if this is an FAA ban or an American Airlines Policy? Steve Wilson ------------------------------ Date: Sat, 7 Mar 92 11:15 EST From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Mice with Cords on Planes, Would God that there were no difference. (I will keep my mouse concealed.) Of course, there is: the mouse cord may act as an antenna, effectively broadcasting any RF from the computer. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769 ------------------------------ Date: Sat, 7 Mar 1992 16:02:59 GMT From: rls@tip.wedge.nt.com (Robert L. Smith) Subject: Re: Mouse restrictions on American Airlines John Bartlett is mistaken if he thinks that "there wasn't any difference between a mouse connected with a cord and one that is internal." Mouse cords do something besides pass signals along: they RADIATE electromagnetic energy at the frequency of the microprocessor clock which, being essentially a square wave, can include powerful harmonics well into the UHF bands. This is still a concern even if the mouse cable is shielded because the laptop's ground is not common with the airplane's. As an apprehensive passenger, I'm pleased that American identified this hazard before it caused damage. Fortunately my old Toshiba doesn't have a mouse. ------------------------------ Date: Fri, 6 Mar 92 17:56:43 -0800 From: scw@ollie.SEAS.UCLA.EDU (Stephen C. Woods) Subject: RISKS in the news -- recharging portables Today while I was driving home, listening to the news/traffic station in LA (KNX 1070 KC). What should I hear but a reference to the comp.risks `bulletin board'. KNX has a fellow that does a bit about computers. He referenced the recent issue with the report about long lines for the heads on Aircraft with lots of folks using portables as near as I can remember he quoted verbatim from the article. He also mentioned another article from that issue, but the which one has slipped through my parity errors. He did credit the authors, but not our moderator, sorry 'bout that Peter. Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (310)-825-8614 UUCP: ...{ibmsupt,ncar!cepu}!ollie}!scw Internet:scw@SEAS.UCLA.EDU ------------------------------ Date: Fri, 6 Mar 92 16:50:36 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: A RISK architecture? (DEC's Alpha) Alpha arithmetic traps (overflow, underflow, etc.) are imprecise... Nothing new here. This is standard practice in high-performance computer designs, going back as far as the IBM 360/91 of the early 1970s. It's not a RISK because any trap is guaranteed to happen before the first use is made of the result of the arithmetic operation. (In this case, that means the first use of the register that was the destination of the instruction in question.) The only practical difference between imprecise and precise exception is that you can't report the PC of the offending instruction when imprecise. -=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) ------------------------------ Date: 7 Mar 92 15:12:14 EST (Sat) From: johnl@iecc.cambridge.ma.us (John R. Levine) Subject: Re: A RISK architecture? (DEC's Alpha) (Randell, RISKS-13.25) >Alpha arithmetic traps (overflow, underflow, etc.) are imprecise -- they can >be delivered an arbitrary number of instructions [late] Imprecise interrupts have been around for a long time. I wrestled with them on a 360/91 in about 1970. The /91 could execute instructions out of order if there weren't interferences among them, but didn't keep enough state to unscramble the mess if one of them failed. There were barrier instructions but they slowed the machine down so much that they were almost never used except at statement boundaries in some debugging compilers. In practice when you got an imprecise interrupt, your job aborted with a code of S0C0, pronounced "Socko!" You could catch the interrupt, but it was so hard to arrange to repair an overflow (even if you used barriers, the interrupt would usually give you the address of the barrier instruction, not the one that failed) that nobody did. Instead, they inserted tests and prescaling to make sure that interrupts would not occur. I opine that if anything, imprecise interrupts encourage more correct software since you know that you can't recover from errors. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl ------------------------------ Date: Sat, 7 Mar 92 12:43:52 PST From: klassen@sol.UVic.CA (Melvin Klassen) Subject: Imprecise Interrupts on IBM 360/91 (Blinn, Sosman, RISKS-13.26) Actually, the 360-91 used 'BCR mask,0' where the 4-bit value in "mask" **had** to be non-zero to drain the pipeline. ^^^^^^^^ If requested, IBM's PL/I compiler inserted 'BCR 15,0' as the first instruction generated for each PL/I statement, thus limiting any imprecise interrupt to a single PL/I statement. ------------------------------ Date: Fri, 6 Mar 92 19:18:10 -0800 From: pagre@weber.UCSD.EDU (Phil Agre) Subject: Electronic privacy in California California Assembly member Gwen Moore has introduced AB 2674 which requires any state or local agency to notify you when it gives out information about you through an electronic medium. The contact person in Assembly member Moore's office is Bill Julian at (916) 445-8800. Phil Agre, UCSD ------------------------------ Date: Fri, 6 Mar 1992 20:20:43 GMT From: dcmartin@fascet.msi.com (David C. Martin) Subject: Re: 1-900 spelling game (Tannenbaum, RISKS-13.24) Andrew Tannenbaum posted a message about the risks of using a computer to generate tones which would help a person to spell twenty (20) words correctly in two (2) minutes. I have a friend who utilized his Sharp Wizard hand-held computer/calendar/etc.. to win at various sports trivia lines. He used this technique to win a substantial prize from one of these trivia lines which then ended up in litigation. One of the points brought up by the lawyers for the 1-900 operator was (erroneously) that he had done exactly what Andrew discussed -- using a computer connected to the phone to generate the tones of the correct response. The lawyers contended that such a technique removed some of the element of skill from the contest and invalidated the prize. It becomes interesting to me when you attempt to discern where the utility of either a electronic or paper resource ends (supposedly at least a paper reference of sports trivia in the case above is allowed) and the use of automation for "beating the system" begins. If on-line repositories of information are used to augment a persons ability to perform some task, then is the "skill" of the person performing the task any less? dcm Molecular Simulations, Inc., 796 N. Pastoria Avenue, Sunnyvale, CA 94086 mail: dcmartin@msi.com uucp: uunet!dcmartin 408/522-9236 ------------------------------ Date: Fri, 6 Mar 1992 20:45:32 GMT From: pw@panix.com (Paul Wallich) Subject: Re: A320 (Spencer, RISKS-13.24) >One must remember that COINCIDENCES DO HAPPEN. ... I believe that this is fuzzy thinking. Airplane crashes in general are the result of multiple failures; only if _everything_ goes wrong do you lose a plane. Thus you can argue that any single crash samples a large number of things going wrong. To wit, when the first DC-10 crashed with a dropped engine, airworthiness inspectors found potentially lethal cracks in the engine mounting of something like 70 other aircraft. In two cases no one could quite figure out why the engine hadn't fallen off already. (And note, btw, that if not for a) the pilot being untrained in this particular kind of disaster and b) the design flaw of misrouted hydraulic lines, dropping an engine wouldn't have been a big deal.) Air crashes are the tail of a wide distribution in failures, nonetheless when you start getting _any_ numbers up in that tail, it should lead you to worry a great deal about where the median may be drifting. This raises an interesting point for designers of both hardware and software: when you get into very-high-reliability systems, how many of the failures are due to problems whose rates have been specified and characterized, and how many are do to completely unanticipated, unanalyzed features of the design? paul ------------------------------ Date: Sat, 7 Mar 92 00:08:05 GMT From: jgriffit@isis.cs.du.edu (Jonathan Griffitts) Subject: Re: 7-character PO key My sister also encountered a variation on this problem. While a grad student, she lived in a house with several other students. As is common for students, the residents of this house move very frequently. When she moved away from this place herself, NONE of her mail was correctly forwarded. When whe enquired about this, she found that a former resident of the house had a similar last name (Griffin as compared to Griffitts), and that there was a forwarding notice still in effect for this other unknown person. The post office's hashing function was completely unable to distinguish between the two forwarding orders. When my sister finally managed to get her own forwarding implemented, she began receiving Ms. Griffin's mail. She was repeatedly told by post office employees that this problem was absolutely unfixable within their procedures. --JCG, AnyWare Engineering, Boulder CO 303 442-0556 ------------------------------ End of RISKS-FORUM Digest 13.27 ************************