Text File

RISKS-LIST: RISKS-FORUM Digest Monday, 8 February 1988 Volume 6 : Issue 22

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

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

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. > > > > > > > > > PLEASE LIST SUBJECT in SUBJECT: LINE. < < < < < < < < < For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

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

Date: Mon 8 Feb 88 14:04:14-PST From: Peter G. Neumann <NEUMANN@csl.sri.com> Subject: Software theft

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 often.

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

Date: Mon, 8 Feb 88 00:31:42 EST From: David HM Spector <spector@vx2.GBA.NYU.EDU> Subject: Macintosh Virus Hits CompuServe (long)

Thie following is a notice posted to Compu'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 (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

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: 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:

============================ Welcome to HYPERCARD FORUM!! ============================

========= !!ALERT!! =========

DO NOT USE THE STACK "NEWAPP.STK" WHICH WAS ONLINE HERE FOR ABOUT 24 HOURS. IT WILL MESS YOUR SYSTEM WITH UNKNOWN RESULTS. DO NOT USE ANY OTHER SYTEM FROM ANY OTHER DISK THAT WAS RUN WHILE THE NEWAPP.STK'S MODIFIED SYSTEM WAS ONLINE.

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 COURSE OF ACTION IS TO TRASH ANY SYSTEM FILE THAT HAS COME IN CONTACT WITH THIS STACK.

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 | *****************************************************************

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

From: decvax!bunker!wtm@ucbvax.Berkeley.EDU (Bill McGarry) Date: Fri, 5 Feb 88 23:43:44 EDT Subject: King Tut, call home!

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]

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

From: jon@june.cs.washington.edu (Jon Jacky) Subject: Big article on whistle-blowers in new TECHNOLOGY REVIEW Date: 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

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

Subject: Re: Whistle-blowing Date: Sat, 06 Feb 88 17:32:31 -0800 From: Nancy Leveson <nancy@commerce.UCI.EDU> Reply-To: nancy@ICS.UCI.EDU

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

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

Date: Sun, 7 Feb 88 17:52:58 est From: munnari!stcns3.stc.oz.au!dave@uunet.UU.NET (Dave Horsfall) Subject: Even little computers aren't immune from RISKs

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: dave@stcns3.stc.OZ.AU Alcatel-STC Australia ARPA: dave%stcns3.stc.OZ.AU@uunet.UU.NET 11th Floor, 5 Blue St UUCP: {enea,hplabs,mcvax,uunet,ukc}!\ North Sydney NSW 2060 AUSTRALIA munnari!stcns3.stc.OZ.AU!dave

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

Date: Fri, 5 Feb 88 13:06:56 EST From: Luke Visser <munnari!tasis.utas.oz.au!luke@uunet.UU.NET> Subject: Final results not necessarily correct -- blame the database

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: luke%tasis.utas.oz@uunet.uu.net UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!luke

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

Date: Sun, 7 Feb 88 01:09:25 pst From: uw-beaver!ssc-vax!wanttaja@rutgers.edu (Ronald J Wanttaja) Subject: "Early Warning Vulnerability (Was Re: US Fears Satellites Damaged)

>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)

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

Subject: Software Warranties Date: Sat, 06 Feb 88 18:53:37 -0800 From: Nancy Leveson <nancy@commerce.UCI.EDU>

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

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

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