The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 13 Issue 27

Saturday 7 March 1992

Contents

o Re: Michelangelo reports
Robert Slade
Bill Murray
David Leslie
Brandon S. Allbery
o (Mis)perceptions of RISKS
Steve Strassmann
o Re: Lap Mice
Steven Wilson
Bill Murray
Robert L. Smith
o RISKS in the news -- recharging portables
Stephen C. Woods
o Re: A RISK architecture? (DEC's Alpha, IBM 360/91)
Andrew Klossner
John R. Levine
Melvin Klassen
o Electronic privacy in California
Phil Agre
o Re: 1-900 spelling game
David C. Martin
o Re: A320
Paul Wallich
o Re: 7-character PO key
Jonathan Griffitts
o Info on RISKS (comp.risks)

Initial Michelangelo reports (first cut)

Robert Slade <rslade@sfu.ca>
Sat, 7 Mar 1992 22:49:30 GMT
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


Measuring Michelangelo

<WHMurray@DOCKMASTER.NCSC.MIL>
Sat, 7 Mar 92 09:44 EST
... 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


MichelAngelo virus less a risk than Norton

David Leslie <dleslie@phakt.usc.edu>
Sat, 7 Mar 92 15:24:00 PST
    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


Re: Michelangelo (Mainwaring, RISKS-13.26)

Brandon S. Allbery KF8NH <allbery@ncoast.org>
Sat, 7 Mar 92 14:24:33 -0500
| 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.


(mis)perceptions of RISKS (Mainwaring, RISKS-13.26)

Steve Strassmann <straz@cambridge.apple.com>
Fri, 6 Mar 1992 20:34:12 -0500
   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.


Re: Lap Mice (Bartlett, RISKS-13.26 [sic])

Steven Wilson <stevew@netcom.com>
Sat, 7 Mar 92 09:43:52 PST
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


Mice with Cords on Planes,

<WHMurray@DOCKMASTER.NCSC.MIL>
Sat, 7 Mar 92 11:15 EST
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


Re: Mouse restrictions on American Airlines

Robert L. Smith <rls@tip.wedge.nt.com>
Sat, 7 Mar 1992 16:02:59 GMT
    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.


RISKS in the news -- recharging portables

Stephen C. Woods <scw@ollie.SEAS.UCLA.EDU>
Fri, 6 Mar 92 17:56:43 -0800
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


Re: A RISK architecture? (DEC's Alpha)

Andrew Klossner <andrew@frip.wv.tek.com>
Fri, 6 Mar 92 16:50:36 PST
   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)


Re: A RISK architecture? (DEC's Alpha) (Randell, RISKS-13.25)

John R. Levine <johnl@iecc.cambridge.ma.us>
7 Mar 92 15:12:14 EST (Sat)
>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


Imprecise Interrupts on IBM 360/91 (Blinn, Sosman, RISKS-13.26)

Melvin Klassen <klassen@sol.UVic.CA>
Sat, 7 Mar 92 12:43:52 PST
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.


Electronic privacy in California

Phil Agre <pagre@weber.UCSD.EDU>
Fri, 6 Mar 92 19:18:10 -0800
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


Re: 1-900 spelling game (Tannenbaum, RISKS-13.24)

David C. Martin <dcmartin@fascet.msi.com>
Fri, 6 Mar 1992 20:20:43 GMT
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


Re: A320 (Spencer, RISKS-13.24)

Paul Wallich <pw@panix.com>
Fri, 6 Mar 1992 20:45:32 GMT
>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


Re: 7-character PO key

Jonathan Griffitts <jgriffit@isis.cs.du.edu>
Sat, 7 Mar 92 00:08:05 GMT
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

Please report problems with the web pages to the maintainer

Top