Subject: RISKS DIGEST 13.27
REPLY-TO:
[email protected]
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
[email protected], 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
[email protected].
Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=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:
[email protected] (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
[email protected] [email protected] 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:
[email protected]
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:
[email protected] (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
[email protected]
------------------------------
Date: Sat, 7 Mar 92 14:24:33 -0500
From:
[email protected] (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 <
[email protected]>
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
[email protected]
Apple Computer Avanced Technology Group Cambridge, Mass.
------------------------------
Date: Sat, 7 Mar 92 09:43:52 PST
From:
[email protected] (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:
[email protected]
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:
[email protected] (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:
[email protected] (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:
[email protected]
------------------------------
Date: Fri, 6 Mar 92 16:50:36 PST
From:
[email protected] (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:
[email protected] (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,
[email protected], {spdcc|ima|world}!iecc!johnl
------------------------------
Date: Sat, 7 Mar 92 12:43:52 PST
From:
[email protected] (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:
[email protected] (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:
[email protected] (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:
[email protected] uucp: uunet!dcmartin 408/522-9236
------------------------------
Date: Fri, 6 Mar 1992 20:45:32 GMT
From:
[email protected] (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:
[email protected] (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
************************
