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 6 Issue 22

Monday, 8 February 1988


o Software theft
o Macintosh Virus Hits CompuServe
David HM Spector
o King Tut, call home!
Bill McGarry
o Whistle-blowers
Jon Jacky
Nancy Leveson
o Even little computers aren't immune from RISKs
Dave Horsfall
o Final results not necessarily correct -- blame the database
Luke Visser
o Early Warning Vulnerability
Ronald J Wanttaja
o Software Warranties
Nancy Leveson
o Info on RISKS (comp.risks)

Software theft

Peter G. Neumann <>
Mon 8 Feb 88 14:04:14-PST
Ming Jyh Hsieh, 38, a computer product support engineer who had been fired
for ``nonperformance'' by the Wollongong Group in Palo Alto CA in November
1987, was caught in the act while downloading Wollongong-proprietary
software to her PC.  She used the ``secret password'' and privileges that
were still valid two months later, and spent 18 hours over several nights
copying software.  Police placed a ``trap and trace'' device on Wollongong's
computer phone lines to identify her phone line.  [Source: Palo Alto Times
Tribune, 7 February 1988]

A few comments are in order.

(1) A password is not secret when it is known to more than one person; in
this case, it was shared among at least 5 people.  (Shared passwords are
generally a bad idea.)

(2) A password is not necessarily secret even if it is kept private by
one person.  Exposures (stored unencrypted, transmitted unencrypted,
derivable, guessable, etc.) are often very easy to obtain.

(3) It is extraordinarily bad practice to fire someone and then not change
all relevant passwords, revoke their privileges, etc.

(4) This kind of problem of nonrevoked privileges seems to happen amazingly

Macintosh Virus Hits CompuServe (long)

David HM Spector <spector@vx2.GBA.NYU.EDU>
Mon, 8 Feb 88 00:31:42 EST
Thie following is a notice posted to Compu$erve's HyperCard forum in the
last 24Hrs...  I think this is the first occurance of a live (as opposed to the
sources I mentioned in my last note) virus on the Macintosh (in North America):

I might mention, that based on the sources that were posted to Compu$erve 
(please don't send mail asking for copies, requests will be politely, but 
firmly, rejected), and the description of the virus below, it is possible that 
the posting of the sources directly contributed to this (new?) virus...

Pretty Scary....

David HM Spector                New York University
Senior Systems Programmer           Graduate School of Business
Arpa: SPECTOR@GBA.NYU.EDU           Academic Computing Center
UUCP:...!{allegra,rocky,harvard}!cmcl2!spector  90 Trinity Place, Rm C-4
MCIMail: DSpector/Compu$erve: 71260,1410    New York, New York 10006
AppleLink: D1161

 =  =  =  =  =  = F r o m  --  C o m p u S e r v e  =  =  =  =  =  =

CompuServe              APPHYPER

One moment please...

Welcome to MAUG(tm):HyperForum, V. 4C(232)

Hello, David HM Spector
Last visit:  06-Feb-88  22:31:04

Forum messages:   1489 to   2516
Last message you've read:   2409

Subtopic(s) Selected:
 All Accessible
No members are in conference.

Short bulletin:




The above stack contains code which modifies your System and other Systems it
comes into contact with. It is a "computer virus." If you run NEWAPP.STK it
will modify the System on the disk it is on so that the System's INITs contain
an INIT labeled "DR." Then, if you use another System with the DR-infected
System as your boot System the new System will also contain the
self-propagating "DR" INIT Resource. While it is possible to, apparently, "cut"
this Resource from infected Systems with the Resource Editor THE ONLY SURE

I apologize for this having happened. Obviously, whoever programmed this
qualifies as being less than pond scum (if it was done purposefully). The
uploader has been locked off the network (not just the Forums) and he will be
contacted by CompuServe and/or myself. Please keep in mind, as always, that
although Sysops do check uploads it is impossible for us to do such things as
examine every file with the Resource Editor. As I have always recommended, keep
downloads away from your hard disk until you are sure they are OK.

In eight years of operation this is the only such occurrence. While I, of
course, cannot say it will be the last I still have just as much confidenc as
always in the fact that 99.99999999% of the Mac Community are quite trustworthy
and that there is no real need to "fear" downloads. Thanks,
-- Neil Shapiro (Chief Sysop)

   |MAUG(tm)(Micronetworked Apple Users Group is a trademark owned |
   | by MCU Inc. (PO Box 520, Bethpage, NY 11714). Voice help line |
   |  available at 516/735-6924 daily _only_ from 10am to 5pm EST  |

King Tut, call home!

Bill McGarry <decvax!bunker!wtm@ucbvax.Berkeley.EDU>
Fri, 5 Feb 88 23:43:44 EDT
Rochester Telephone Corporation (New York) erroneously billed 4,800
customers for phone calls to Egypt.  The company blamed the error
on a computer which "...misread the number dialed and determined
that they were coming from Egypt".

(From the February, 1988 issue of Online.)

Bill McGarry,  Bunker Ramo, Shelton, CT 
                                    {philabs, decvax, fortune, yale}!bunker!wtm

        [Sounds as if they did not know whether they were coming or going! PGN]

Big article on whistle-blowers in new TECHNOLOGY REVIEW

Jon Jacky <>
Mon, 08 Feb 88 08:56:28 PST
Many RISKS readers who have been following the recent discussion of
whistle-blowing will be interested in "Making the world safe for whistle-
blowers," by Rosemary Chalk, TECHNOLOGY REVIEW 91(1):48 - 57, Jan 1988.
Now on newstands.  Several case histories, a bibliography, and a review
of legal status and protection.

- Jon Jacky, University of Washington

Re: Whistle-blowing

Nancy Leveson <nancy@commerce.UCI.EDU>
Sat, 06 Feb 88 17:32:31 -0800
In Risks 6.1 Bob Ayers writes:

   >Is it better to have a computerized system -- knowing that it is not 
   >perfect -- or to have a non-computerized system -- which also will not 
   >be perfect, though its faults will be different?
   >Would you use a computer system if, on each use, it had a one in 10^9 
   >chance of killing you?  You use such [non-computer] systems every day.  
   >I recommend the book (also mentioned before) On Acceptable Risk.

The difference is that in non-computerized systems there are techniques to
measure or assess risk so one knows whether the risk is acceptable or not.
These do not exist for software.  So the question is whether it is better
to have a non-computerized system with known, acceptable risk or to have
a computerized system with unknown (and perhaps unacceptable risk).
Would you use a computer OR non-computer system in which you were unsure 
whether the risk was 10^-9 or 10^-3 or 10^-1 chance of killing you?

How many complex, real-time software systems do you know of that have 
demonstrated anything close to a 10^-9 chance of erroneous behavior
(i.e., virtual perfection) over its entire lifetime?  Even if you might
somehow name one or two, does this occur in all software systems so
that one can count on it?

Another difference is that interlocks and other devices are used to protect
against expected failures (non-perfection) in non-computer systems.  How many 
software systems do you know of that contain such protective features?  How
many software engineers know how to build in such protection?  How many
government agencies have guidelines that require safety analysis of computer
systems as they do for non-computer systems?
                                                    Nancy Leveson

Even little computers aren't immune from RISKs

Dave Horsfall <munnari!!dave@uunet.UU.NET>
Sun, 7 Feb 88 17:52:58 est
An extract from "Practical Wireless" February 1988 shows that even
the sort of computer found in homes aren't immune from RISKs.  Most
amateur radio enthusiasts using amateur satellites use a computer to
derive their predictions, and PW has this to say:

  "Those using some satellite computer programs may find that with the
  coming of the new year, their predictions may go astray.  It is possible
  that the new sidereal time values, usually as lines stating "IF Y2 = '87'
  LET G2 = 0.2753606" may not automatically update in some of the older
  programs.  Whilst this can be overcome by calling January 1 1988 "December
  32 1987" and January 2 "December 33" etc, is is better to update your program
  with the new values following: [numbers deleted]"

Yet another "new-year-bug"?  The work-around really tickled my fancy!

Dave Horsfall (VK2KFU)      ACS:
Alcatel-STC Australia       ARPA:
11th Floor, 5 Blue St       UUCP: {enea,hplabs,mcvax,uunet,ukc}!\
North Sydney NSW 2060 AUSTRALIA    munnari!!dave

Final results not necessarily correct -- blame the database

Luke Visser <munnari!!luke@uunet.UU.NET>
Fri, 5 Feb 88 13:06:56 EST
On reading Dave Horsfall's contribution from "The Australian" about incorrect
results being sent out to students I remembered a similar situation that
happened here in one of Australia's other states - Tasmania.

One of my friends doesn't like her final results being published in the
state's main newspaper (it's standard practice to print them).  So, she rang 
up the newspaper's office and asked for them not to print her results.
No problems they said except we are having a few problems with our database, 
but we'll see what we can do.

So, sure enough when the results came out in the paper it was evident that
they had some problems with their database.  Her name was printed along with
4 lower passes (not good enough to count towards her Higher School
Certificate).  However, these results were incorrect and she had in fact 
higher passed 3 subjects and passed 2.

It seems to me that they must have really had some big problems with their
database if they couldn't just flag someone's results not to be printed, and
whatever flag they used corrupts the results that are printed.
                                                                   Luke Visser

Snail: Uni of Tasmania, Box 252C GPO, Hobart 7001, Tasmania, Australia.
ACSnet: luke@tasis.utas.oz  ARPA:
UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!luke

"Early Warning Vulnerability (Was Re: US Fears Satellites Damaged)

Ronald J Wanttaja <uw-beaver!ssc-vax!>
Sun, 7 Feb 88 01:09:25 pst
>Consider, too, that such a concerted attack on satellite sensors is precisely
>analogous to, say, saboteurs simultaneously blowing up all the BMEWS missile-
>warning radars:  it is itself an act of war, and an extremely ominous one,
>pointless except as a prelude to a nuclear attack.  It in fact IS a strong
>warning of imminent attack, although not quite an actual launch warning.

True, very true.  But the US does not have a "launch on suspicion" policy.

Consider this scenario:  The Soviets blind most of the US Early Warning
satellites.  Please note, there are NOT of lot of birds tasked for EW; they
wouldn't have to take a lot out.  Assume some small capability remains, as
well as limited functioning among the cripples.

The U.S. immediately goes to high DEFCON.  SAC places the bombers on air
alert, the missile crews batten down the hatches, the President dives into
the airborne command post.

The Soviets do *nothing*.  Maybe issue a public apology.  Maybe raise their
eyebrows and say, "are you sure it wasn't another gas well fire?  Where's
your proof?"  They do not launch their missiles.

Meanwhile, the US is left with limited missile warning capability.  SAC
stays in the air/in the holes, the president lands occasionally, and NORAD
crews work 24 hours a day trying to keep cripples working.

We can't keep it up forever.  Spacecraft are expensive, launch costs are
high.  It doesn't make sense to the bean counters to have replacement birds
on any sort of alert.  We CAN NOT regain capability quickly.  Nor can
we remain at elevated DEFCON levels indefinitely.  

Two months of this type of operation, and the BUFFs (SAC B-52s) are down
for maintenance, the missile crew's morale is at rock bottom, and the
cripples are falling by the wayside.  The President is back in DC, working
on the budget.  *Then* would be a good time for a major attack...

Ron Wanttaja  ex-NORAD Satellite Systems Engineer  (ssc-vax!wanttaja)

Software Warranties

Nancy Leveson <nancy@commerce.UCI.EDU>
Sat, 06 Feb 88 18:53:37 -0800
Jim Horning once suggested that we need the equivalent of an Underwriter's
Lab for software.  It appears that such a thing now exists, at least for one
professional group.  Three years ago the ABA (American Bar Association)
created the Legal Technology Advisory Council (LTAC) staffed by software
technicians and scores of volunteers (both lawyers and software experts).
The LTAC establishes performance standards for law office software, tests
products against those standards, and gives an official "ABA Mark of
Approval" to products that pass their tests.  To become an ABA-Approved
product, it must have the features that will meet the needs of the law
office, it must do what the vendor claims it will, and it must not have
serious errors in manuals, training, or the software itself.

More than 1500 products have been tested and they have found errors in 
EVERY ONE.  About 50 products in time-and-billing, word processing,
docket and diary, real estate, litigation support, and other areas have
eventually been able to get the stamp of approval after making required
corrections.   Errors that they found include systems that:
    -- would not print a bill
    -- did not identify which key to press to retrieve a document
    -- added dollars to hours (instead of multiplying hours times a
       billing rate to yield dollars)
    -- in a docketing system, automatically erased entries, including
       future court dates, once its capacity was reached
    -- would not show an item as billed, making it likely that the item
       would be inadvertently billed twice
    -- had non-functional security systems
    -- multiplied rate by hours incorrectly
    -- printed the wrong billing name and address on a bill
    -- tallied different totals across and down headings
    -- had instruction manuals that provided incomplete or incorrect
       information and omitted crucial steps.

The LTAC publishes detailed information for each approved product on
product features and results from the testing process.  There are also
guidelines for various types of software that specify features that must 
be offered for ABA approval and preferred features (not required but very 
desirable).  Besides performance features, the guidelines also require that 
systems be free of bugs, that advertising claims conform exactly to system
capabilities, and that printed or on-line training and help instructions
be clear and easy to understand.  That is, they claim that ABA approval
will assure that a product is free of bugs and will perform as advertised.

The most fascinating part to me is that they recommend that if lawyers must
consider a product that is not approved, they should ask the vendor to
WARRANT that their product meets the ABA standards: that it has ALL the
features you need AND that it is free of errors and bugs.  The booklet
I read says to "either prepare a formal, written warranty for the vendor
to sign or prepare a formal RFP that lists the LTAC guidelines for the
specifications."  Considering the standard disclaimers that usually come with
commercial software, I wonder how successful lawyers have been at getting
vendors to sign such warranties.

This seems like an interesting model for other professional groups to follow.

Nancy Leveson

Please report problems with the web pages to the maintainer