Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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
... 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
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
| 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.
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.
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
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
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.
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
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)
>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
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.
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
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
>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
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