Subject: RISKS DIGEST 17.49 RISKS-LIST: Risks-Forum Digest Weds 29 November 1995 Volume 17 : Issue 49 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Spelling Correctors Self-Applied? Not in Microsoft Word (PGN) Another Oakland airport radar outage (PGN) "Black Baron" gets 18-month sentence for virus activities (PGN) Denial-of-service attack (James Burns) New software that is just too clever (Jeffrey D. Sherman) Alarm and alarm-silencing risks in medical equipment (John R. Strohm) Re: Can you have enough backups? (Pete Mellor) Re: A well-managed risk (Tom Zmudzinski) Is chip theft high-tech crime? (Harlan Rosenthal) Network Security Moves to Front Burner (Edupage) CERT Summary CS-95:03 (CERT Advisory) 11th ACSAC Advanced Program (Vince L. Reed) AMAST'96 Call for Systems Demonstrations (Pippo Scollo) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 29 Nov 95 12:10:33 PST From: "Peter G. Neumann" Subject: Spelling Correctors Self-Applied? Not in Microsoft Word A cute article by Joan E. Rigdon in the *San Francisco Sunday Examiner and Chronicle* Computers & Technology section (``How do you spell dated? MS Word hasn't brought dictionary into cyber-age'' -- 26 Nov 1995, B-5) points out that the Word spellchecker makes the following suggestions for words that putatively would seem important to Microsoft: Internet --> interment Internet's --> internee's e-mail --> emboli (blood clots) cybershoppers --> [no suggestions] Netscape --> [no suggestions, although pretending that your competitors don't exist is a nasty strategy. Ms. Rigdon also notes that Microsoft should have received adequate warning last December when the *Dallas Morning News* ran a garbled story resulting from an editor accidentally accepting all of the alternative spellings, including the following conversions: Intel --> Until Microsoft --> Microvolts As noted in RISKS on numerous occasions, our archives are full of such transgressions (most recently, see RISKS-17.32). [Transgreshams Law, I suppose.] Similar to MS ignoring Netscape was Scott Siege's item in RISKS-15.72 that the Apple MacIntosh spellchecker suggested changing "Laserwriter" to "Laserjet" (not surprisingly, an Apple product). ------------------------------ Date: Wed, 29 Nov 95 08:01:32 PST From: "Peter G. Neumann" Subject: Another Oakland airport radar outage The Oakland airport radar failed again on 28 Nov 1995 for about two hours, beginning at 9:44am. ("The cause ... was not known.") Backup radar at Moffett Field was used; however, it covers a smaller area, and delays were incurred on 17 takeoffs at SFO. There had also been a brief failure on 27 Nov 1995, but it caused no disruption. Usual statements were made about how safety was not impaired and no one should be concerned. FAA spokesman Mitch Barker said, "We don't let it operate if it's not safe." He was also quoted in a made-for-RISKS statement: "Things are going to go wrong from time to time, especially with a system as complicated as this." [Source: *San Francisco Chronicle*, 29 Nov 1995, A13. For further background, the August 1995 Fremont (Oakland) ATC outage is discussed beginning in RISKS-17.24 to 28. Another Fremont outage earlier this month required the backup system to be used for two days, but was not reported in RISKS at the time. Other ATC problems are also noted in recent RISKS -- in Chicago (17.35) and Las Vegas (17.41). The system may be safe, but it does not seem sound.] [Dates have been corrected in this version, fixing an off-by-one error.] ------------------------------ Date: Wed, 29 Nov 95 08:07:51 PST From: "Peter G. Neumann" Subject: "Black Baron" gets 18-month sentence for virus activities Christopher Pile, 26, the first person in Britain to be convicted of creating computer viruses, was jailed for 18 months. His creations (Pathogen and Queeg) were apparently rather sophisticated stealth viruses that used an encryption program (Smeg) to hide their presence. ------------------------------ Date: 29 Nov 95 17:49:16 From: burns@bellcore.com (James Burns) Subject: Denial-of-service attack According to a front-page story by James W. Roberts in the 29 Nov 1995 _Asbury Park Press_ (NJ), a student at Monmouth University has been charged with disrupting the school's electronic mail system for five hours by bombarding two adminstrators with 24,000 e-mail messages. The student's computer access had been terminated on 9 Nov 1995 because of posting advertising and business venture solicitations to "inappropriate sections of the Internet" (presumably, Usenet groups). It took 44 hours to trace the source of the attack through a service provider in Atlanta, GA and back to an account based in Red Bank, NJ, shared by the student. The student is being charge with a federal crime because of using interstate communication to deny service. Carl Stern of the Justice Department is said to have remarked that this is the first time the federal computer fraud act has been used for an act of this type. James E. Burns, Bellcore, NVC-3X114, 331 Newman Springs Road Red Bank, NJ 07701-5699 1-908-758-2819 burns@nova.bellcore.com ------------------------------ Date: Wed, 22 Nov 95 03:18:03 -0500 From: Jeffrey D. Sherman Subject: New software that is just too clever Ray Panko's story of being outsmarted by Excel trying to be clever in dealing with percentages reminded me of my recent struggles with WordPerfect 6.1. I recently started using WordPerfect 6.1, upgrading from 5.2. It has some nice features, but several strange things happened: - I couldn't leave two spaces between a chapter number and the chapter name: I would type two spaces but one would mysteriously disappear - typing (c) in a list (as in (a), (b), (c)), resulted in the copyright symbol appearing. There was no warning - in fact a document converted from WP5.2 had to be recalled and reprinted when we noticed this change. - I could not select part of a word with the mouse: only all of it or none of it. After a lot of aggravation, and buying a couple of books, I found that the strange behaviour resulted from "enhancements" in WP6.1. I've now disabled the enhancements, so the software will do what _I_ want. ------------------------------ Date: Wed, 22 Nov 1995 09:11:21 -0500 (EST) From: john.r.strohm@BIX.com Subject: Alarm and alarm-silencing risks in medical equipment I recently underwent total hip replacement surgery. As part of the procedure, for pain control, the doctors fitted me with an intravenous infusion system that gave me a continuous morphine feed in fluids at a constant rate. The system used two intravenous infusion (IV) pumps, one to feed the morphine into the carrier fluids (a potassium salt solution, I think), and the other to feed the carrier fluids into me. Both pumps were capable of operation from AC line or from internal rechargeable batteries; this allows the patient to be transferred from the surgical suite to the various other wards of the hospital without worrying about extension cords on the way. The pumps have an audible alarm, and there are several illuminated icons on the front panel to indicate the reason for the alarm. Morphine is a controlled narcotic, and IV pumps for morphine have a number of special features. The morphine is carried in a large syringe that is mounted inside the pump, behind a locking panel cover. The programming controls for the pump are behind the locking panel as well; the pump cannot be set up or reset without the key. There is a patient-operated demand switch, with an associated programmable lockout time, that allows the patient to get an extra boost on demand, but no more often than the certain interval. The patient is expected to use the switch if he anticipates a need for more pain control than the baseline; this happens for example when the patient is transferred between beds, or when the physical therapists enter the room. (The physical therapists do a very necessary job that is unfortunately not a whole lot of fun for the patient.) Additionally, the physician will generally allow the patient to request an additional booster dose from the nurse, at longer intervals. Because of other medical concerns, I spent the first 24 hours or so post-op in intensive care, rather than going immediately to the orthopedic floor. When we transferred me up to orthopedic, the ICU nurses rearranged everything, loaded the pumps onto a conventional IV tree, switched them over to battery operation, and we were on our way. Transferring a patient from an ICU bed/gurney to a standard hospital bed is something of a production, requiring several nurses to lift and a patient not to scream. Then all the various hoses coming out of the patient have to be arranged, the IV pumps situated, power cords plugged in, and etc. etc. About an hour after the transfer to orthopedic was completed, one of the IV pumps alarmed. I called the nurse's station and told them "alarm on the IV pump". I couldn't see the pump face to see which alarm indicator was on. A nurse, not the one assigned to me, came in, said, "Oh, that is just the battery alarm; you don't have to listen to that; I'll silence it." She did something on the front panel of the morphine pump, and the alarm stopped. I asked whether the pumps were in fact plugged in; she glanced at the power cords and said they were. A few minutes later, the assigned nurse came in, just as I was starting to notice discomfort building up. She asked about the alarm; I explained; she checked the morphine pump, and discovered that it had just shut down from battery exhaustion. She had to go get the patient chart and the safety key and reprogram the pump, after plugging it into the wall. The risks in the above design should be evident. 1) There should be an unequivocal indication, continuously present, that the pump is running on batteries. 2) There should be no operator procedure, other than getting the pump running on AC line power, or shutting it off completely, to silence a low-battery alarm. 3) Personnel have to be trained to think about WHY a particular alarm is sounding, and the implications of the alarm, BEFORE they reach for a "Silence" key. ------------------------------ Date: Wed, 29 Nov 95 20:56:34 GMT From: Pete Mellor Subject: Re: Can you have enough backups? (Cushman, RISKS-17.48) The story from about multiple failures of back-ups in RISKS-17.48 reminded me of a somewhat similar incident which I perpetrated many years ago while working in the Service Programming Department at ICL in Stevenage. The main programming effort was concentrated in the Executive Programming Department. (The basic operating system on the ICL 1900 series was referred to as an "executive". There was a more powerful operating system known as GEORGE 3, but this ran on the larger machines in the range. Stevenage was responsible for medium range machines which ran executives. I still think that if ICL had played its cards right, GEORGE 3 could now have been a serious rival to UNIX, but that is a separate story! :-) Anyway, one task of Service Programming (as well as writing and maintaining editors, assemblers and various utility programs) was to keep back-ups of the source programs. The "executive masters", which were sources from which a compiled executive for any hardware configuration could be derived, were big beasts. The back-up involved running a disk-to-tape copy program, using a grandparent-parent-child cycle of three pairs of tapes. If a pair of tapes became full, the administrator (me) had literally to go from desk to desk and persuade people to delete their out-of-date sources to make room for the latest ones. My job included reading the printed operator's log every morning to check that the previous overnight back-up run was OK, and in particular that it had not overflowed the two tapes. Came the day when I had neglected to do this check for a while, and discovered that three nights previously, the back-up had overflowed. All three generations of back-up MT had been overwritten with a truncated copy! Worse, the stuff that had dropped off the end included executive masters that had not been changed for years. (They were still very live, however, just not under active development.) The on-line medium was exchangeable disk store (EDS). In those days, the largest EDS pack held 8 megabytes, and the department had three drives. Only active sources were kept on-line. The *only* copies of the masters I had lost resided on those back-up tapes. Ouch! I confessed. The most polite and least personal comment was from the programming manager: "Oh my God! What are we going to do?" *Fortunately*, on the day after the overflow, some of my colleagues had deleted several large files. The result was that Monday night's back-up (for the sake of illustration) had resulted in tape overflow and a truncated copy of the back-up. On Tuesday night and Wednesday night, the actual size of the entire back-up had been reduced, so that the second tape of the pair was nowhere near full. (The back-up procedure was driven by a set of parameter cards which specified which files were to be added and which deleted. The back-up program worked by first copying any new files from disk, then copying the child tapes to the grandparent tapes (overwriting them in the process) omitting files which were declared as "deleted" by its parameters.) Eureka! The "lost" data might still be there on the end of the second of one of the pairs of tapes. So I took a program which would do a hardware block-by-block read of a magnetic tape, patched into it a modification (in 1900 object code) so that instead of stopping at the "end of tape" (EOT) mark, it halted with a suitable display and could then be restarted to copy what lay beyond EOT, and so copied the tail-end of one of the less than full back-ups. Sure enough, there were all the files I had "lost"! My annual salary increment began to look healthier! For some reason, when I told my colleagues how I had saved the day, they were less than impressed by my ingenuity, and unfortunately their responses were couched in language which cannot be repeated in a polite forum such as RISKS! :-) Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB +44 (171) 477-8422 p.mellor@csr.city.ac.uk ------------------------------ Date: Wed, 22 Nov 95 09:27:07 EST From: "Tom Zmudzinski" Subject: Re: A well-managed risk (Whittle, RISKS-17.47) >> As an aircraft mechanic who once witnessed a returning aircraft run out of fuel on the taxiway with 5,000 pounds of fuel showing on the gauges, I tend to disagree. This triggers an old memory: In April 1971, my then boss bought a new Pontiac Bonneville wagon. He thought he was getting GREAT gas mileage. He was driving all over Northern Virginia and the gauge hadn't moved since leaving the dealership. The gauge was still registering 3/4ths of a tank when the car ran out gas. What had happened was that the float arm had been spot welded (accidentally? bored autoworker?) in place. [Permission granted ... to redistribute ... electronically or otherwise as long as the entire file is printed without substantive modification.] ------------------------------ Date: Wed, 22 Nov 95 11:33:00 -0500 From: "Rosenthal, Harlan" Subject: Is chip theft high-tech crime? I differ from the current practice of grouping online activity, information theft, and component theft into "high tech" crimes. While I feel strongly that most malintentioned online activity is covered as an instantiation of existing law and practice, it is a different kind of activity from stealing chips. In my mind, hijacking a truckload of RAM chips is just like hijacking a truckload of flavorings destined for a food plant, or grabbing a package out of the hands of someone just leaving a jewelry store: simple theft of valuable material with low traceability. True "Internet crime" might be using a hole in security to gather information about another system; and that's no different in intent from using an insecurely-locked door to breach the physical security of the building to get at the same system. Reductio ad absurdum: If someone breaks into my house and steals my silverware, that's low tech crime; if they steal my computer, it's high-tech crime; and if they take the stereo, it's medium-tech crime. We should educate the press and public on this matter, before we find carjacking considered a "high-tech" crime because of the engine computers. -Harlan Rosenthal ------------------------------ Date: Tue, 28 Nov 1995 20:09:05 -0500 (EST) From: Educom Subject: Network Security Moves to Front Burner (Edupage, 28 Nov 1995) Corporate America is emerging from a lengthy state of denial, and beginning to take measures to protect its electronic assets. Nearly half of the respondents to an Information Week/Ernst & Young poll reported having lost valuable information during the past two years, with at least 20 saying they'd lost information worth more than $1 million. Nearly 70% said security risks had worsened in the last five years, and nearly 80% now have a full-time information security director. As one analyst noted, "As organizational structures are flattened, corporate reliance on the availability and integrity of information systems is becoming painfully obvious." (*Information Week*, 27 Nov 1995, p32) ------------------------------ Date: Tue, 28 Nov 1995 10:43:44 -0500 From: CERT Advisory Subject: CERT Summary CS-95:03 CERT Summary CS-95:03, November 28, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries * * * * * RECENT ACTIVITY Since the September CERT Summary, we have seen these continuing trends in incidents reported to us. The majority of reported incidents fit into four categories: 1. Packet Sniffers We continue to see daily incident reports about intruders who have installed sniffers on compromised systems. These sniffers, used to collect account names and passwords, are frequently installed with a kit that includes Trojan horse binaries. The Trojan horse binaries hide the sniffer activity on the systems on which they are installed. For further information and methods for detecting packet sniffers and Trojan horses, see the following files: ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksum ftp://info.cert.org/pub/cert_advisories/CA-94:05.README 2. Exploitation of SGI lp Vulnerability The vulnerability described in CERT advisory, CA:95:15 "SGI lp Vulnerability" continues to be exploited, though we have seen a decline in the number of reports since the advisory was released on November 8. Intruders gain unauthorized access to Silicon Graphics, Inc. (SGI) IRIX systems through a passwordless lp account; they use this initial access to leverage additional privileges on the compromised system. As distributed by SGI, the lp account (as well as other accounts), has no password on a newly installed system. This fact is addressed in the documentation that SGI distributes with their systems: "IRIX Advanced Site and Server Administrative Guide" (see the chapter on System Security). More information on this vulnerability and how it can be addressed can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-95:15.SGI.lp.vul 3. Network Scanning We continue to receive several reports each week of intruders using the Internet Security Scanner (ISS) to scan both individual hosts and large IP address ranges. The ISS tool, which is described in CERT advisory CA-93:14 "Internet Security Scanner", interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders use the information gathered from such scans to gain unauthorized access to the scanned sites. As part of a defensive strategy, you may want to consider running ISS against your own site (in accordance with your organization's policies and procedures) to identify any possible system weaknesses or vulnerabilities, taking steps to implement security fixes that may be necessary. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar More information about the ISS tool and steps for protecting your site are outlined in the following documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 4. Sendmail Attacks New reports of intruders attacking sites through sendmail vulnerabilities are continuing to arrive daily, although most reports indicate the attacks have failed. The types of attacks are varied, but most are aimed at gaining privileged access to the victim machine. We encourage sites to combat these threats by taking the appropriate steps, described in the following documents: ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-95:05.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README * * * * * WHAT'S NEW in the CERT FTP Archive We have made the following changes since the last CERT Summary (September 26, 1995). * New Additions ftp://info.cert.org/pub/cert_advisories/ CA-95:12.sun.loadmodule.vul CA-95:13.syslog.vul CA-95:14.Telnetd_Environment_Vulnerability CA-95:15.SGI.lp.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:07.abell (lsof) VB-95-08.X_Authentication_Vul ftp://info.cert.org/pub/tools/sendmail sendmail/sendmail.8.7.1.tar sendmail/sendmail.8.7.1.tar.Z * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:16a.README (sendmail - note to use smrsh with all versions) CA-95:05.README (sendmail - date of Digital Equipment's patch) CA-95:08.README (sendmail - note to use smrsh with all versions) CA-95:10.README (ghostscript - patches and explanations) CA-95:13.README (syslog - information from vendors) CA-95:14.README (telnetd - information from vendors; correction to compilation example) ftp://info.cert.org/pub/tools/cops README (more recent email address for COPS author Dan Farmer) * * * * * HOW TO Contact the CERT Coordination Center Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key * * * * * Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University. ------------------------------ Date: Wed, 15 Nov 1995 22:39:27 -0600 From: vreed@mitre.org (Vince L. Reed) Subject: 11th ACSAC Advanced Program The conference committee for the 11th Annual Computer Security Applications Conference (ACSAC) is proud to announce the conference home page. It is available on the world wide web at: http://www.isse.gmu.edu/~csis/acsac/acsac95.html Vince Reed, CISSP 11th ACSAC Publicity Cochair 1500 Perimeter Pkwy., Suite 310, Huntsville, AL 35806 Phone-205.890.3323, FAX-205.830.2608 [The next conference is 11-15 Dec 1995. Joe Bob says check it out. PGN] ------------------------------ Date: Wed, 29 Nov 1995 00:54:42 +0100 From: scollo@cs.utwente.nl (Pippo Scollo) Subject: AMAST'96 Call for Systems Demonstrations [A Postscript version of the full announcement is available on the AMAST'96 WWW page, at URL: http://www.pst.informatik.uni-muenchen.de/amast96/ -- this version is starkly reduced by PGN.] [To subscribe to the AMAST'96 mailing list: amast96-request@informatik.uni-muenchen.de] AMAST '96, July 1-5, 1996 Fifth International Conference on Algebraic Methodology and Software Technology Ludwig-Maximilians-Universitaet, Munich, Germany Call for Systems Demonstrations The major goal of the AMAST Conferences is to put software development technology on a firm, mathematical foundation. Particular emphasis is given to algebraic and logical foundations of software technology. An eventual goal is to establish algebraic and logical methodology as a practically viable and attractive alternative to the prevailing ad-hoc approaches to software engineering. We invite submissions of system demonstrations showing the improved effectiveness of software developed on a mathematical basis. The topics of interest include, but not limited to, the following: SOFTWARE DEVELOPMENT ENVIRONMENTS SUPPORT FOR CORRECT SOFTWARE DEVELOPMENT SYSTEM SUPPORT FOR REUSE TOOLS FOR PROTOTYPING, VALIDATION AND VERIFICATION THEOREM PROVING SYSTEMS We invite prospective authors to submit 6 copies of system demo proposals (4 double spaced pages maximum) in an area relevant to the conference theme. Papers should provide adequate information for the reviewers to assess the significance and anticipated impact of the system on software technology. All submissions must be sent to the program chair at the address below; the proposals must be received by January 15, 1996 (new extended deadline). Martin Wirsing, AMAST'96 Program Chair Institut fur Informatik, Universitaet Munchen Leopoldstr. 11B D-80802 Munchen, Germany Phone: ++49/89/ 2180-6317 Fax: ++49/89/ 2180-6310 e-mail: amast96-info@informatik.uni-muenchen.de General Chair: Maurice Nivat (France) Program Chair: Martin Wirsing (Germany) [Excellent program committee omitted for space reasons. PGN] Invited Speakers include Manfred Broy (Programming Methodology), Jose Fiadeiro (Algebraic and Logical Foundations), Rick Hehner (Programming Methodology), Doug Smith (Software Development). Proceedings will be published by Springer-Verlag. For bulletins on current status of the conference: http://www.pst.informatik.uni-muenchen.de/konferenzen amast96-info@informatik.uni-muenchen.de Tools and Demos: cbaur@informatik.uni-muenchen.de Registration: hennicke@informatik.uni-muenchen.de Local Arrangements: diem@informatik.uni-muenchen.de ------------------------------ Date: 6 September 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] 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. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.49 ************************