Subject: RISKS DIGEST 13.13

Subject: RISKS DIGEST 13.13
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Saturday 8 February 1992 Volume 13 : Issue 13

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
What next - pizza over UUCP? (Peter J. Scott)
Re: New Caltrans AVI spec (Chris Hibbert)
Re: Dutch police arrest hackers (Martin Minow)
Re: Confusing Telephone System Overload Message (David Shepherd)
Re: Radiation underdosages (Nancy Leveson)
Re: Another Radiotherapy Error (Don Tyzuk)
Re: Le Canard Enchaine (Bertrand Meyer, Charlie Mingo)
VIRUS WARNING - DaVinci Discovers Michelangelo (PC) (Kenneth R. van Wyk)
CERT Advisory - Michelangelo PC Virus Warning (CERT)
Michelangelo & the "Fix" Utilities (A. Padgett Peterson)

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 domain 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: Fri, 7 Feb 92 17:15:30 -0800
From: [email protected] (Peter J. Scott)
Subject: What next - pizza over UUCP? [UUCPizza?]

A colleague just gave me this juicy tidbit. Seems that his brother-in-law was
with the 82nd Airborne and, upon assignment to Fort Bragg, was given an office
that had never been used. He plugged a phone into the jack and the phone
immediately rang. No, it wasn't telemarketers; he was greeted with a modem
tone instead. Hung up. Phone immediately rang again. This repeated 24 hours
a day until the Army put a trace on the call. The trace led to, get this, a
Coca-Cola machine. The manufacturer had built into these vending machines the
capability to call the bottling company when they were getting low on supplies
and order more.

Unfortunately for my friend's brother-in-law, the bottling company that owned
this machine in particular wasn't interested in this option, so they didn't
change the default telephone number that was programmed into the machine, and
which was happened to be set to, you guessed it, the office at Fort Bragg.

The Army cut the telephone cable on the Coke machine. (I guess they weren't
armed at the time.) This brand of vending machine also has the capability of
signalling via modem that it was out of change, full up on money, or had been
broken into ("Help, I've fallen over and I can't get up...").
[Not high enough on Coke? PGN]

I suppose modern machines just use FDDI. Maybe PGN could add a few candy
machines to the RISKS distribution?

Peter J. Scott, Member of Technical Staff | [email protected]
Jet Propulsion Laboratory, NASA/Caltech | SPAN: GROUCH::PJS

[The RISKS archives remind us of an earlier episode with Coke machines,
reported 15 Jan 1985 in the Washington Post, describing a business
from which hundreds of phone calls were billed mysteriously nights and
weekends even though no one was in the building. Yes, their Coke machine
was trying to phone home. See ACM Software Engineering Notes, vol, 10, no
2, April 1985, p.8, four months before we started the on-line RISKS! By the
way, the latest SEN RISKS index is in the January 1992 SEN issue, just out.
The New Orleans SIGSOFT '91 Proceedings are in the December issue. PGN]

------------------------------

Date: Fri, 7 Feb 92 18:21:44 PST
From: [email protected]
Subject: Re: New Caltrans AVI spec (Agre, RISKS-13.09)

I also received a revision of the specification for Automatic Vehicle
Identification (AVI) equipment that Phil Agre talked about in Risks 13.09, and
that I've talked about here before. I'm much happier than Phil was with the
new draft. It still has lots of problems, not the least of them the lack of
attention to security. However, they've done just what I wanted on the subject
of privacy.

I testified before a CalTrans hearing in October on the spec, and a state
Senate Judiciary Committee hearing on Privacy in December, and it appears that
my message got through. The new draft doesn't leave room for an identifier of
the vehicle or the driver in the communication packets. At the hearing in
December, Senator Bill Lockyer, the chair of the committee, made it clear to
the head of CalTrans and to Les Kubel, who is responsible for collecting
comments, that they were going to support anonymity in their system. That's a
major victory.

On to the rest of the spec. First, it won't be easy to forward a copy of the
spec via EMail. The current draft is presented as a marked-up copy of the
previous ones, even though it has changed massively. All deletions are
presented with strike-through, insertions have double-underline, and all
unchanged text has a single underline. Besides making it very difficult to
read, this also means that a scanner isn't going to be able to figure it out.
Oh well.

Phil misinterpreted some of the spec in his message, and asked some questions
that I can answer.

From: [email protected] (Phil Agre)

the state envisages attaching [the box] to your car that
broadcasts your car's vehicle identification number (VIN)
when pinged by a roadsite transmitter.

They aren't going to use VIN. The spec mentions a Reader ID number which is a
32 bit field that would identify the reader unit. This is as opposed to the
first version, which said VIN, and the second that said "Character-based ID,
identifying the vehicle.

would it be necessary for every car on the road to have one of these
transmitters.

All the CalTrans folk and vendors I've talked to say that there's no need for
every car to have one in order to collect tolls. Some are willing to say that
they expect "other forces" (maybe DEA or INS?) to try to make this kind of
equipment usable for tracing people's movements. There may have been attempts
to make this be standard equipment on new cars. Lockyer appeared to say that
the California AVI spec had better not support this "feature".

Caltrans has generalized the proposal; the "AVI" equipment
is no longer specifically aimed at toll collection but is
now intended to support a much wider range of applications.

I'll have to look at the old spec, to figure out why, but I always
understood this to be the intent. I specifically remember that the
previous version said that more packet types could be added later to
serve other purposes.

I cannot understand how automatic toll collection could
work unless every car has a transponder.

The spec doesn't talk about it because it's not part of the technology being
designed. The following is my guess, based on how I'd build such a system.
For corroboration, we should ask someone who uses the existing systems in
Dallas, New Orleans, or elsewhere what their systems do. I would expect any
such (toll-collection) system to be prepared for vehicles without a
transponder. Some vehicles will be from out of state, some batteries will die.
So, you just have cash lanes. This also allows you to take care of the cars
with boxes that have run out of credit: As you approach the toll point, a
sensor queries your box to find out how your balance stands. If your account
is low, you see an overhead sign directing you to use the cash lane.

This doesn't make it possible to collect tolls every half-mile, but it's fully
capable of supporting toll roads like the ones we currently have, or private
toll roads, which could be limited to vehicles which had the units.

Phil is right, however that there are lots of other issues which are left
unaddressed by the spec. The folks at CalTrans aren't interested in listening
to these, so you might as well address them to your state congresscritter.
There's a new draft with a new deadline of February 28, so if you want a copy
or to comment on the spec itself, write to:

Les Kubel, Chief
Office of Electrical and Electronics Engineering
Department of New Technology, Materials and Research
PO Box 19128
Sacramento, California 95819-0128

Chris

------------------------------

Date: Fri, 7 Feb 92 17:54:12 PST
From: Martin Minow <[email protected]>
Subject: Re: Dutch police arrest hackers (RISKS-13.11)

I must strongly disagree with the following comment in the discussion
of the damages caused by the Dutch hacker's break-ins:

>If restoring back-ups costs tens of thousands of guilders, something is
>terribly wrong at the VU. Every system manager that uses a legal copy of the
>operating system has a distribution version within easy reach.

Rebuilding the operating system for a small workstation takes at least
a half-day. Re-editing all site-specific files, such as pasword files,
network host tables, mail aliases, and all site-specific privileged
files will certainly take several more days. For a large site with
networked disks and distributed resources, the cleanup must extend to
all other systems that the transgressors may have reached. This is
a difficult and non-trivial task.

Please do not assume that I agree with other statements in the article.

Martin Minow [email protected]

------------------------------

Date: Fri, 7 Feb 92 10:51:30 GMT
From: David Shepherd <[email protected]>
Subject: Re: Confusing Telephone System Overload Message (McCulley, RISKS-13.09)

Here in the UK the BBC had a quiz on a Saturday night show - during the show
they asked a simple question and you phoned in the answer and a randomly
selected person with the correct answer was phoned back at the end and told
what prize a "celebrity" had won for then (the quotes are due to the fact the
the first "celebrity" was Eddie the Eagle - the UK's famously bad ski-jumper).
The next week British Telecom announced that during the show 1.25 million calls
had been attempted on the line, but only 7,000 had been answered by the BBC!

In the past the BBC have had phone polls e.g. on capital punishment
when that was being debated in parliament, and people complained that
the 50-50 result was due to the capacity of the phone system and not
public opinion as both lines seem to have become overloaded.

david shepherd: [email protected] or [email protected] tel: 0454-616616 x 625
inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq

------------------------------

Date: Sat, 08 Feb 92 16:03:53 -0800
From: [email protected]
Subject: Radiation underdosages

Does anyone have any other information about this than the newspaper article?
The account in the Independent doesn't make it sound like it was a computer
error although the article appears to blame the computer.

The following article about faulty computer control of radiotherapy
treatment is reprinted in its entirety ...

A computer programming error meant that ...

But it later says that:

The physicist who made the mistake by introducing an unnecessary
correction factor when a new planning computer was installed in 1982 ...

Medical physicists compute the dosage to be given to the patient (using
physicians instructions about desired treatment). If the physicist did not
know how to compute a proper dosage, it does not matter whether the computation
was done by hand, on a calculator, or by a computer. It seems strange to blame
this on a programming error. Did the physicist really do the programming? Was
there treatment planning software already installed on the computer and the
physicist just entered some factors (i.e., data)? If the programmer was told
by an expert to implement a particular formula that is incorrect, how could
this error ever be found by testing or any other method that involved software
engineering techniques? If a person drives a car into a fence, is it reasonable
to blame the car?

This is not at all related to what happened with the Therac-25.
nancy

------------------------------

Date: Sat, 8 Feb 1992 13:54:18 GMT
From: [email protected] (Don Tyzuk)
Subject: Re: Another Radiotherapy Error

With regard to computer risks in general:

I think it is time to establish licensing of software engineers, and that there
should be an independant review body for such critical software of the sort
that we literally place our lives directly in its care.

Many programmers of such systems have no knowledge whatsoever of the techniques
of reliable programming. They were the scientist, or expert, or whatever on the
object under software control, and were chosen to write the program because
they could hack out something that worked.

Consequently, they turn out spaghetti. Do you want your child to be the next
Therac victim?

The moniker "software engineer" is used a little loosley, for my mind. I think
there is a place for real software enginners, with the education in applied
science that it implies.

A program (5 years in Nova Scotia) of
2 years of applied science
3 years of software science
professional experience.
comprehensive examinations.
membership in a professional society of engineers.
a provincial license.
a review committee.

No, I am not an engineer.

Donald Tyzuk Wolfville, Nova Scotia [email protected]

------------------------------

Date: Sat, 8 Feb 92 12:55:21 PST
From: [email protected] (Bertrand Meyer @ Interactive Software Engineering Inc.)
Subject: Le Canard Enchaine

> By coincidence, it was written by a certain Jerome Canard (and no jokes about
> his brother Donald, please! :-). <It's an old canard, anyway. PGN>

Of course not a coincidence. As every reader of Le Canard
knows, ``Jerome Canard'' is a pseudonym. The choice of pseudonym
indicates that articles with this signature are probably written by
the editor-in-chief, or at least a quite senior editor.

> [Anyone know exactly which region the "Hexagon" is?]

Please think for half a second, or look at a map. ``The Hexagon'' means
France. It's a term favored by bureaucrats and journalists. (``Today, at the
four corners of the Hexagon, ...'' is a famous parody of technocratic style.)

``Le Point'' is one the four major weekly news magazines. (The others are Le
Nouvel Observateur, L'Express and L'Evenement du Jeudi.)
Bertrand Meyer
[Also noted by Martin Minow <[email protected]>]

------------------------------

Date: 08 Feb 92 13:01:31
From: [email protected] (Charlie Mingo)
Subject: Re: Strasbourg A320: Duck Writes in Duck

[...] The term came into use in the 1960's after the loss of Algeria had
blurred the French sense of where their borders lay. (Not too long ago, France
included much of Africa and the Middle East, along with bits of the Caribbean,
Latin America and Pacific Oceana.)

The term is the French equivalent of "the lower 48" in the US.

------------------------------

Date: Tue, 4 Feb 1992 09:40:50 EST
Reply-To: [email protected]
Sender: Virus Discussion List <[email protected]>
From: "The Moderator Kenneth R. van Wyk" <[email protected]>
Subject: VIRUS WARNING - DaVinci Discovers Michelangelo (PC) [VIRUS-L V5 #21]

VIRUS-L Digest Tuesday, 4 Feb 1992 Volume 5 : Issue 21

Date: Tue, 04 Feb 92 08:22:01 -0500
From: "Kenneth R. van Wyk" <[email protected]>
Subject: VIRUS WARNING - DaVinci Discovers Michelangelo (PC)

[Moderator's note: I received the following press release by FAX. Any typos
are no doubt mine, not DaVinci's. krvw]

News Release

DaVinci Systems Corporation, P.O. Box 17449, Raleigh, North Carolina 27619
Tel: (919) 881-4320 Fax: (919) 787-3550

Contact: Chris Evans, Vice President of Marketing, DaVinci Systems Corporation,
(919) 881-4320

DaVinci Discovers Michelangelo Virus
Warns users of possible infection

RALEIGH, North Carolina, February 1, 1992 - DaVinci Systems announced today
that a recent shipment of eMAIL 2.0 demonstration disks and 30-day kits may be
infected with a computer virus known as Michelangelo. Approximately 900
customers and potential customers were sent the infected disks. Of these, over
600 were DaVinci resellers.

DaVinci Systems immediately notified its resellers of the problem via
electronic mail and will mail a new set of disks to all recipients of the
infected disks by February 6th. DaVinci Systems also advises anyone who has
received a DaVinci eMAIL 2.0 demo disk or 30-day kit between January 20, 1992
and January 31st, 1992 not to use the disks they received.

According to Bill Nussey, President of DaVinci Systems, "While there is only a
slim chance of one of our customers contracting the Michelangelo virus from
these disks, we wanted to take every possible precaution."

The Michelangelo virus sits passively on infected machines until March 6th
(Michelangelo's Birthday) when it corrupts data on a user's hard disk.
FORTUNATELY, THE VIRUS CAN ONLY BE CONTRACTED BY BOOTING UP AN INFECTED FLOPPY.
Because the infected disks are not bootable, most users who have received these
diskettes will not contract the virus on their machine even if they run the
demo or install the software on their hard disks. The only way users could
catch the virus from an infected disk is if they inadvertently boot up their
computers with the infected floppy in driver A while the drive door is closed.

DaVinci officials are still investigating the source of the virus. Although
DaVinci's master disks are routinely checked for viruses, the virus software
used apparently did not detect Michelangelo. "We are now using multiple
virus-detection products and insisting that our duplicating contractors also
check for viruses", said Nussey.

The Michelangelo virus can be detected by Microcom's Virex version 2.l1 or later
or by McAfee Associates shareware program VIRUSCAN version 7.9v84 or later.
DaVinci users and resellers can download VIRUSCAN from DaVinci's BBS at (919)
881-4342.

Based in Raleigh, North Carolina, DaVinci Systems Corporation is the leading
independent supplier of LAN-based electronic mail applications. The company's
products run under acknowledged personal computer network and operating system
standards such as MS-DOS, Microsoft Windows, and Novell Netware. DaVinci
Systems is at P.O. Box 17449, Raleigh NC 27619. Telephone (919) 881-4320,
(800) DAVINCI. FAX: (919) 787-3550.

The product names and trademarks referenced are the trademarks or
registered trademarks of their respective companies.

------------------------------

Date: Thu, 6 Feb 92 15:57:37 EST
From: CERT Advisory <[email protected]>
Subject: CERT Advisory - Michelangelo PC Virus Warning

CA-92:02 CERT Advisory
February 6, 1992
Michelangelo PC Virus Warning

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a personal computer virus known as
Michelangelo. The virus affects IBM PCs and compatibles. A description
of the virus, along with suggested countermeasures, is presented below.

I. Description

The Michelangelo virus is a computer virus that affects PCs
running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and
higher. Note, however, that although the virus can only execute
on PCs running these versions of DOS, it can infect and damage PC
hard disks containing other PC operating systems including UNIX,
OS/2, and Novell. Thus, booting an infected DOS floppy disk on
a PC that has, for example, UNIX on the hard disk would infect
the hard disk and would probably prevent the UNIX disk from
booting. The virus infects floppy disk boot sectors and hard
disk master boot records (MBRs). When the user boots from an
infected floppy disk, the virus installs itself in memory and
infects the partition table of the first hard disk (if found).
Once the virus is installed, it will infect any floppy disk that
the user accesses.

Some possible, though not conclusive, symptoms of the
Michelangelo virus include a reduction in free/total memory by
2048 bytes, and some floppy disks that become unusable or display
"odd" graphic characters during "DIR" commands. Additionally,
integrity management products should report that the MBR has been
altered.

Note that the Michelangelo virus does not display any messages on
the PC screen at any time.

II. Impact

The Michelangelo virus triggers on any March 6. On that date,
the virus overwrites critical system data, including boot and
file allocation table (FAT) records, on the boot disk (floppy or
hard), rendering the disk unusable. Recovering user data from a
disk damaged by the Michelangelo virus will be very difficult.

III. Solution

Many versions of anti-virus software released after approximately
October 1991 will detect and/or remove the Michelangelo virus.
This includes numerous commercial, shareware, and freeware
software packages. Since this virus was first detected around
the middle of 1991 (after March 6, 1991), it is crucial to use
current versions of these products, particularly those products
that search systems for known viruses.

The CERT/CC has not formally reviewed, evaluated, or endorsed any
of the anti-virus products. While some older anti-virus products
may detect this virus, the CERT/CC strongly suggests that sites
verify with their anti-virus product vendors that their product
will detect and eradicate the Michelangelo virus.

The CERT/CC advises that all sites test for the presence of this
virus before March 6, which is the trigger date. If an infection
is discovered, it is essential that the user examine all floppy
disks that may have come in contact with an infected machine.

As always, the CERT/CC strongly urges all sites to maintain good
backup procedures.

The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the
Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center
(Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at
Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson
Research Center.

If you believe that your system has been compromised, contact CERT/CC or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: [email protected]
Telephone: 412-268-7090 (24-hour hotline)
CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC), Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).

------------------------------

Date: Fri, 7 Feb 92 09:37:29 -0500
From: padgett%[email protected] (A. Padgett Peterson)
Subject: Michelangelo & the "Fix" Utilities - free through March 6th

This virus has really surprised me. When I first say it, my thought was
"yet another STONED" (and not as well written), but it seems to be spreading &
spreading & spreading... If Rob Slade's estimate is right, for every report we
see, there are at least three other infected computers that we don't. March 6th
may just be interesting.

Some time ago I did a number of experiments concerning boot sectors in
general since we seemed to have good protection from DOS viruses but few people
were working at the BIOS level before DOS ever starts. IMHO, since over 50% of
the reported infections begin at the BIOS level, then that is where the
checking should start. The first experiments (written in 1988) were a set of
integrity checking programs, two of which were CHKMEM and CHKBOOT (now
FREEWARE) that could be used to detect all "common" viruses - I presented a
paper on this at last year's Virus & Security Conference in New York (March 12
& 13 this year call (800)835- 2246 x190 for info - plug).

These operate from the DOS level. About two years ago, I began studying a
BIOS level approach - at this point the Intel PC is a fully functioning
computer with access to all peripherals, it is just not yet a DOS (or Unix or
OS/2 or...) computer.

The first result was the DISKSECURE program that was designed as a
technology demonstrator & performed BIOS level integrity checking and
protection of the MBR, hidden sectors, and DOS boot record. Many researchers
seem to like it as an additional layer of protection.

DISKSECURE's biggest limitation was that it could do nothing about a
floppy boot (only hardware can prevent this) and I was and am convinced that a
global solution had to be software based - not for technical reasons but for
logistical and economic ones.

The next effort was SafeMBR - a BIOS level Master Boot Record replacement
that performed integrity checking on the system and which would halt a boot if
"something" was wrong and used lessons learned in DISKSECURE to avoid conflicts
with the incredible array of disk controllers, BIOSes, and DOS variants that
exist. SafeMBR is FREEWARE.

Late in 1991, I extended the SafeMBR concepts to a similar floppy disk
replacement SafeFBR to provide a generic floppy disk boot record replacement
with warning messages.

Concurrently with SafeMBR, I addressed the "floppy boot" problem as far as
possible with software, a TSR (512 bytes needed & can be loaded "high") was
written to intercept the Ctrl-Alt-Del sequence and test for a floppy in drive
A. If one is found, the reboot is denied. This taught me more about the inner
workings of the BIOS and the Interrupt Controller. NoFBoot was the result and
is also FREEWARE.

The final parts FixMBR and FixFBR were extensions of this concept used to
install SafeFBR and SafeMBR. FixMBR came from hours spent disinfecting machines
infected by MBR viruses and was designed to automate the repair based on the
fact that ALL leave an intact partition table SOMEWHERE. Given an intact
partition table, all that is usually necessary is to replace the MBR program.
Generally I use the SafeMBR code to do this.

For some time, I was hesitant to release these techniques but then along
came the Azusa virus...

FixFBR works essentially the same way except that only four Boot Parameter
Blocks are needed (does not work with 2.88 Mb floppies yet). Since it also
incorporates the CHKBOOT techniques, it will also flag potentially infected
disks.

This last is the key to the concept. None of these programs (well maybe
NoFBoot) will prevent a virus infection. What they will do is to detect
viruses almost immediately. Flag the "anomaly" in a way the user cannot
ignore, and provide a recovery mechanism. They do not "identify 1000 viruses"
but will tell you that "something" has happened at the BIOS level without going
resident. They are designed as one layer in a layered protection (I use four
layers myself).

Similarly, either CHKBOOT or FixFBR will detect the Michelangelo virus on
floppy disks and report them as "suspect". FixFBR will then remove the
problem.

To me this is a vital element in fighting malicious software, knowing
early on that "something" has happened and isolating the abnormality to as
narrow range. I personally believe that if these techniques were used
globally, those viruses responsible for over half of reported infections:
Stoned, Azusa, Aircop, Brain, Joshi, & Michelangelo would quickly disappear.

But today there appears to be a very real threat: Michelangelo that needs
to be addressed. I have never seen so many reports of a virus in so short a
time before and am particularly disturbed about the number of "shrink-wrapped"
reports. Consequentially, while normally I "suggest" a nominal SHAREWARE fee
($1.00) for the two "FIX" utilities, from now until 7 March, 1992, payment
requirements are suspended and they may be freely used, posted, & transmitted
without limitation so long as they are not modified.
Padgett
padgett%[email protected]

PS: I know that the current version of these programs is in FIXUTIL2.ZIP and
may be found in directory msdos.antivirus at urvax.urich.edu (141.166.1.6 -
thanks Claude).

Note: this is my hobby, my employer has nothing to do with this.

Programs in FIXUTIL2.ZIP

Length CRC-32 Name
------ ------ ----
1331 449b4371 CHKMEM.COM
2189 2753290a FIXFBR.EXE
368 72b99d29 SUMFBOOT.COM
1357 77936de4 CHKBOOT.EXE
2219 332bf466 FIXMBR.EXE
4885 3e04a29b FIXFBR1A.DOC
749 3f347828 CHKSMBR.EXE
368 cccf71a5 NOFBOOT.COM
2602 63f3d358 NOFBOOT.DOC
4461 a1408395 CHK.DOC
366 4c0e9c20 VALIDATE.24
26118 8138037e FIXMBR24.DOC
------ -------
47013 12 files

------------------------------

End of RISKS-FORUM Digest 13.13
************************