Text File

precedence: bulk Subject: Risks Digest 20.16

RISKS-LIST: Risks-Forum Digest Friday 15 January 1999 Volume 20 : Issue 16

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, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.16.html> and at ftp.sri.com/risks/ .

Contents: Another premature data release (PGN) NSA says Furby is a national security risk (Bruce Martin) Man crashes car as 50 pagers ring simultaneously (Geoffrey Leeming) 16-yr-old Irish girl's crypto system (PGN) Over-reliance on technology (Pat Place) The risks of a first failure (Bertrand Meyer) If at first you don't succeed, breaking-in's no crime in Norway (Edupage) Viruses and Rocket Science (Henry Spencer via Tom Evans) Smurf denial-of-service attack on OZEMAIL (Mich Kabay) Y2K in Swiss hospitals (Debora Weber-Wulff) 1 Apr 2001 flaw in Windows (PGN) Quicken 1999 bug (James S. Vera) A good Y2K bug (Lenny Foner) Utilities and Y2K: not to worry (Ken Knowlton) Y2K testing tools (Craig Raskin) Java Security (Gary McGraw) REVIEW: "Maximum Security", Anonymous (Rob Slade) REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Tue, 13 Jan 1999 08:12:17 -0800 PST From: "Peter G. Neumann" <Neumann@csl.sri.com> Subject: Another premature data release

The Department of Labor Statistics has once again accidentally released data a day early, this time with the Producer Price Index. Whereas last time (RISKS-20.05) it was "a human failure", this time it was attributed to a ``software programming error''. As usual, the problem has been corrected, and won't happen again. [Source: *San Francisco Chronicle*, 13 Jan 1999, front page of the business section, PGN Abstr.]

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

Date: Wed, 13 Jan 1999 13:15:00 -0500 From: Bruce_Martin@manulife.com Subject: NSA says Furby is a national security risk

On 13 Jan 1999, CNews (www.canoe.ca) carried the AP news story about a U.S. national security risk posed by the stuffed toy sold under the name of Furby. For the uninitiated, Furby was the hottest-selling toy of the Xmas '98 season. Resembling furry gremlins [and apparently being sued therefor], Furbies are bristling with audio, infrared, and touch sensors, allowing them to interact with people and with others of their kind.

Detailed information on the capabilities (intended or not) of the average Furby can be found at: www.homestead.com/hackfurby. Among their repertoire of tricks, these toys have the apparent ability to mimic human speech in parrot-like fashion, and therein lies the risk.

According to no lesser authority than the National Security Agency, these toys were being brought into top-secret areas at Fort Meade by government employees, where the little devils (the toys, not the employees) could easily be exposed to classified information which they might later repeat to foreign agents.

Furby is now "machina non grata" at Fort Meade, and transgressors are to report to their Staff Security Office for guidance on this matter. A Capitol Hill source is quoted in the Washington Post of 13 Jan 1999 as saying they feared "that people would take them home and they'd start talking classified."

The risk of U.S. national security resting in the hands of adults who play with children's toys during office hours is left as an exercise to the reader.

Bruce Martin, Toronto

[The manufacturer insists that the memory cannot be altered, and that the furbies cannot learn from their environments. However, because Furbies are programmed to react to responses, there is always the question of whether there might be a preprogrammed Trojan horse recording their choices, and providing a nifty covert channel. Until recently, if you brought viewgraph transparencies into the agency to give a talk, it was nontrivial to get them out again -- because they were photographic media. Presumably, similar thinking goes into NSA's Furby policy. PGN]

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

Date: Fri, 15 Jan 1999 11:27:39 -0100 From: geoffrey.leeming@henderson.com Subject: Man crashes car as 50 pagers ring simultaneously

A man in the Ukraine bought 50 pagers as presents for his staff. While driving home, they all rang at the same time. He was so distracted that he crashed into a lamp post, within 100 meters of his office. Of course, each one said simply, ``Congratulations on a successful purchase!'' [Source: Yahoo News via Reuters, 15 Jan 1999; PGN Abstr.]

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

Date: Wed, 13 Jan 1999 08:20:21 -0800 PST From: "Peter G. Neumann" <Neumann@csl.sri.com> Subject: 16-yr-old Irish girl's crypto system

Sarah Flannery, 16, in Blarney, County Cork, Ireland, has designed a crypto system (called Cayley-Purser). ``She is considering publishing her findings rather than patenting as she does not want people to pay for her discovery.'' Source: Audrey Magee, *The Times*, London, 13 Jan 1999; Edupage, 14 January 1999, PGN Stark Abstr. TNX to Lindsay Marshall]

According to some technical discussions on the net, the scheme is based on 2x2 matrices, and appears to be 10 times faster than RSA, but with much longer keys, and apparently with security comparable to RSA for comparable modulus sizes.

I'm not sure from the articles I've seen whether the reporters are more surprised by Sarah's age or her gender. But there seems to be general astonishment that she could come up with a crypto algorithm. On the other hand, RISKS readers know that lots of people have come up with crypto algorithms. If this one is really good, that *is* special. That she wants to keep it open is even more special. PGN

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

Date: Tue, 12 Jan 1999 09:07:19 -0500 From: prp@SEI.CMU.EDU (Pat Place) Subject: Over-reliance on technology

In answer to Jordin Kare's TROFF problems (RISKS-20.14), Glen Turner (RISKS-20.15) suggests the use of a text editor displying different syntactic components using different textual properties (colour, font, and size being the common variables).

I'm sure that XEmacs and other editors of that sort do their best, however, with a language such as TROFF, where everything can be changed including the escape character and the control line characters (.ec, .cc, and .c2), unless the editor contains a TROFF interpreter sooner or later it will be confused.

Although, XEmacs' best attempt may be good - we shouldn't rely on it for accuracy - the best solutions to Jordin Kare's problems are 1) understand the tool you are using (the nroff/troff user manual is invaluable here) 2) proof-read carefully everything you produce.

Pat Place prp@sei.cmu.edu

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

Date: Wed, 13 Jan 99 11:14:53 PST From: Bertrand.Meyer@eiffel.com Subject: The risks of a first failure

A cute little bug on http://www.dejanews.com (but please don't try this except possibly on a test group):

Successfully post an article through DejaNews (after registering as a user) You get an article number <nnnn> to be used if you want to cancel Change your mind (L'uomo e` mobile) Go to the cancellation page, include nnnn as the article number (You are not only fickle but careless, and didn't notice that you are supposed to put in the angle brackets too.) It finds your article Confirm cancellation by clicking the appropriate button You get a message stating that this is not a valid article number Realize your mistake (the forgotten angle brackets) Try cancellation again, this time including the brackets It finds your article Confirm cancellation You get a message to the effect that this article appears to have been cancelled already!

As far as I know there is no way after that to cancel the article (but I haven't contacted Dejanews about it).

The reason I mention this small apparent bug is that it is representative of an interactive system risk that one encounters all too frequently. It arises for a kind of "transaction", in the broad sense of the term, that a system accepts to carry out at most once. If, however, an attempt fails and is rejected by the system, it may have been registered in the same way as a successful attempt, so that later on the system may believe that the transaction has already taken place, and reject any further attempt, resulting for the user in a Catch-22 situation.

The more general design principle is: if you reject an operation after it may already have affected the information in your system, make sure that the rejection process brings the information back to a consistent state.

(I am not writing: "... that it restores the information to its original state", because that may be impossible; even if possible it may be undesirable, e.g. we may want to keep a record of failed attempts. What we don't want is partial success leading to an inconsistent database. Obviously the use of invariants and other Design by Contract principles helps in defining and enforcing "consistent" states.)

People designing transaction processing systems in the strict, conventional sense are well aware of the risk and the principle, but I think we would all benefit if it were known and applied much more broadly.

Bertrand Meyer, Interactive Software Engineering, Santa Barbara <Bertrand.Meyer@eiffel.com>, http://eiffel.com

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

Date: Thu, 14 Jan 1999 11:52:05 -0500 From: Edupage Editors <edupage@franklin.oit.unc.edu> Subject: If at first you don't succeed, breaking-in's no crime in Norway

The Supreme Court in Norway has ruled that it's not a crime to try to break into someone else's computer system, because people should expect others to try to invade their systems, and take measures to protect themselves. There is a crime, ruled the court, only if the system is actually breached. The case developed out of an attempt by a computer security company to break into the University of Oslo's computers through the Internet, to contribute to a feature story by the Norwegian state broadcasting network. Apparently the security company mapped holes in the university's computer security, but did not break in, tamper with, or steal any information. (*USA Today*, 13 Jan 1999; Edupage, 14 January 1999)

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

Date: Fri, 15 Jan 1999 19:03:18 +1100 From: Tom Evans <TEvans@tennyson.com.au> Subject: Viruses and Rocket Science

The following is lifted directly from Henry Spencer's summary of AW&ST posted to sci.space.news:

Date: 1999/01/06 >From: Henry Spencer <henry@spsystems.net> Subject: space news from Nov 16 AW&ST

As if Sea Launch didn't have trouble enough, now its computers (as well as those of some other Boeing projects) have come down with a massive virus infection. The viruses apparently spread via documents about Sea Launch export compliance, which were widely distributed to staff in the wake of the project's recent government problems. Boeing had few defences in place, and was slow to act because the viruses initially seemed harmless.

Full article available as:

http://x7.dejanews.com/getdoc.xp?AN=429551406.1&CONTEXT=916023969.559415504& hitnum=1

Tom Evans <TEvans@tennyson.com.au>

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

Date: Thu, 14 Jan 1999 09:47:48 -0500 From: Mich Kabay <mkabay@compuserve.com> Subject: Smurf denial-of-service attack on OZEMAIL

According to an article by Tim Barlass in the Daily Telegraph of Australia (12 Jan 1999, p. 9), someone has launched a sustained smurf denial-of-service attack on Ozemail, an important Australian Internet service provider. E-mail service has been disrupted for users in Sydney. A company spokesperson said they were trying to track down the perpetrator and were considering installing filtering software to prevent future attacks.

[Note from MK: a "smurf" attack uses widely-available software written by criminal hackers to send ping packets with forged origination in the headers to a (usually major) corporate network's broadcast address. Every device -- perhaps hundreds or thousands -- sends a reply packet to the forged originator address. That system thus receives a flood of packets, often overloading its TCP/IP stacks and resulting in denial of service. See the article by Michael Dillon in ASK THE INFRA EXPERT (Internet World: Apr 20, 1998) for a more detailed explanation.]

M. E. Kabay, PhD, CISSP / Director of Education ICSA, Inc. <http://www.icsa.net>

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

Date: Thu, 14 Jan 1999 14:22:58 +0100 From: Debora Weber-Wulff <weberwu@tfh-berlin.de> Subject: Y2K in Swiss hospitals

I heard about this from an informant, took quite some searching to find the little notice hiding on the pages in the NZZ (Neue Zuercher Zeitung, 7 Jan 1999) usually reserved for reporting celebrity divorces, plane crashes and natural disasters. An on-the-fly translation:

The hospitals in the canton Waadt spent the 1st and 2nd of January 1999 fighting with the computer problems that are expected for the year 2000. Except for the University Hospital in Lausanne, the computer systems for admitting patients in all of the hospitals of the canton were down for 36 hours. Specialists were able to fix the problem, according to a spokeswomen for the hospitals in the newspaper "24 Heures" (24 hours) on Wednesday. The reason for the system crash is the fact that it was programmed to compare something with the date a year in the future. This was programmed in 6 digits as "01.01.00". The system interpreted this as 1 Jan 1900. Source: Year-2000 computer problem in Waadtlaender hospitals Lausanne, http://archiv.nzz.ch/books/nzzmonat/0/8466081T.html]

Prof. Dr. Debora Weber-Wulff, Technische Fachhochschule Berlin FB Informatik, 13353 Berlin, Germany http://www.tfh-berlin.de/~weberwu/

[Waadt's New? PGN]

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

Date: Thu, 14 Jan 1999 18:12:12 -0800 PST From: "Peter G. Neumann" <Neumann@csl.sri.com> Subject: 1 Apr 2001 flaw in Windows

Windows (95,98,NT) systems apparently suffer from an off-by-one-week glitch on the daylight savings time cutover in 2001, shifting on 1 Apr rather than 8 Apr. An updated library program will solve the problem. [Source: John Markoff, *The New York Times*, 14 Jan 1999; PGN Abstr, via Dave Farber and others.]

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

Date: Tue, 12 Jan 1999 16:44:39 -0800 From: "James S. Vera" <vera@anna.stanford.edu> Subject: Quicken 1999 bug

Another 1999 bug, Intuit's Quicken'99 fails with a "divide by zero" message when a transaction dated in January 1999 is recorded in the Auto category and its "Home and Car Center" is opened. See http://www.intuit.com/support/quicken/faqs/win2/1913.html

James S. Vera | Internet | Voice: +1.415.725.0256 Stanford University | vera@anna.stanford.edu | FAX: +1.415.725.7398

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

Date: Wed, 13 Jan 1999 01:59:00 -0500 From: Lenny Foner <foner@media.mit.edu> Subject: A good Y2K bug

> January 1, 2000 > Re: Vacation Pay

> Dear Valued Employee:

> Our records indicate that you have not used any vacation time over the > past 100 year(s). As I'm sure you are aware, employees are granted 3 > weeks of paid leave per year or pay in lieu of time off. One additional > week is granted for every 5 years of service.

> Please either take 9,400 days off work or notify our office and your next > pay cheque will reflect payment of $8,277,432.22 which will include all > pay and interest for the past 1,200 months.

> Sincerely, Automated Payroll Processing

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

Date: Mon, 11 Jan 1999 20:49:06 EST From: KCKnowlton@aol.com (Ken Knowlton) Subject: Utilities and Y2K: not to worry

I quote from a 10 Jan 1999 article in *The Boston Globe* on utilities' Y2K readiness:

Typical is one filing from Notheast Utilities: "NU has found nothing that cannot be repaired or replaced and be made Year 2000 ready in time," it states.

They don't get it: the devil is in the gotchas not found.

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

Date: Wed, 13 Jan 1999 14:58:28 -0500 (EST) From: Craig Raskin <raskin@compusec.org> Subject: Y2K testing tools

I am currently involved with doing y2k testing at a client site. I have spent numerous hours looking for tools which can be used for building test suites. Unfortunately, I have not been able to find very many tools which are worthwhile.

A lot of the available tools appear to have been built by individuals who do not fully grasp the underlying concept of the machines and operating systems which they are trying to test.

I have written some c code which should cause alerts with testing software that checks for possible y2k problems. When compiled and checked under microsoft based platforms, these binaries easily slip by testing programs. When compiled and checked by Sun's own y2k testing tools, these binaries also slip by.

Since Sun's tools are based on shell scripts, I was able to go in and find the problem. The script works fine under the Sparc editions of the operating system but returns false information when run under the Intel x86 version. This is due to the 'dump' command having differing output between the OS versions. This slipped by the engineers at Sun.

Out of necessity, a lot of people are now doing system testing for the first time in their careers. The risks are obvious. How many systems have been checked and certified with buggy tools? Have individuals involved with testing first checked that their test suites will actually work? Do they even know how? We will find out soon enough.

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

Date: Wed, 13 Jan 1999 22:35:54 -0500 (EST) From: Gary McGraw <gem@rstcorp.com> Subject: Java Security

Ed Felten and I are pleased to announce the publication of a completely revised and expanded new book, a follow-on to our original 1996 book "Java Security: Hostile Applets, Holes, and Antidotes" (better known as Java Security HA HA among readers in the know). The new book "Securing Java: Getting down to business with mobile code" is published by John Wiley & Sons (1999). Physical copies are available now. In addition to the physical book, Ed and I decided to make the entire text available for free and unlimited Web access. The URL is:

http://www.securingjava.com

The risk here is that nobody will buy the physical edition ;-)! Help us mitigate that risk, making the Web experiment a success. Ah publishing in the 90s.

The book covers the risks presented by mobile code systems including Java 2 and ActiveX and is an in depth treatment of these complex issues. RISKS readers will probably appreciate the tone.

Enjoy!

Dr. Gary McGraw, Vice President, Reliable Software Technologies http://www.rstcorp.com

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

Date: Mon, 11 Jan 1999 09:59:59 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca> Subject: REVIEW: "Maximum Security", Anonymous

BKMAXSEC.RVW 981025

"Maximum Security", Anonymous, 1998, 0-672-31341-3, U$49.99/C$70.95/UK#46.95 %A Anonymous %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 1998 %E Mark Taber newtech_mgr@sams.mcp.com %G 0-672-31341-3 %I Macmillan Computer Publishing (MCP) %O U$49.99/C$70.95/UK#46.95 800-858-7674 http://www.mcp.com %P 829 p. + CD-ROM %T "Maximum Security, second edition"

Rather loudly promoted on the net these days, the major selling point of this book is that it was written "by an experienced hacker." Supposedly one who spent some time as a guest of Uncle Sam for fiddling bank machines. (Some of what we are told about the author does not fit with the contents of the book, but then, as an old professional paranoid, I may be unduly suspicious.) Leaving aside questions of morality and definitions of the term "hacker," let us merely observe that these people are the gnostics. They are the devotees of the hidden, esoteric, and arcane knowledge. Such knowledge, of course, is cheapened and weakened by being revealed. Which may explain a certain reticence on a number of points in the first edition of the book. The introduction to that edition made it fairly clear: Anonymous assumed that if you did not work diligently at his direction you did not deserve to secure your system. One could almost feel his glee at the expectation that thousands of sysadmins around the world were wracking their brains and flooding Usenet with discussions of the significance of his clues to the vital encrypted message he had hidden on the CD-ROM.

The riddle, and that attitude, seem to have been removed from this second edition. The author tacitly admits that the first was a bit of a kludge: he says that it was written in haste. He also states that the second edition is more "solution oriented." It could hardly have been less. Be that as it may, the book is, as the author states, essentially completely rewritten. It has been much improved in the process, moving up from truly awful to merely mediocre. The new version provides a good deal of reference information, although assessing the quality of that information is left as an exercise to the reader.

The section on viruses is an overview of the book in miniature. The hype has been toned down, and the explanation of how viruses work is much more reasonable. However, it still insists that "destruction" is the major characteristic of a virus. (There is, later, an admission that "[m]ost viruses do not actually destroy data.") We are treated to the old myth that virus researchers write viruses as a kind of job security. While a general background to viruses is provided, there is no discussion of protection options. However, there are more listings of antiviral programs and resource sites than there are for virus creation programs. Many topics within the text have lists of books and Web sites for further study, and there is one for viruses that includes three of the four tomes recommended by the VIRUS-L FAQ. Unfortunately, it also contains some lesser works, and there are no annotations to the bibliography.

Part one is simply two chapters of introduction to the book. A somewhat limited overview to security concepts is given in part two, concentrating on the Internet. Chapters look at the Internet, TCP/IP basics, hackers and crackers, targets, possibilities of fights over the net, and very brief data security primer. Various types of security and attack software are outlined in part three. There is consideration of malicious software, security weakness scanners, password crackers, trojans, network packet sniffers, firewalls, and audit software. Part four looks at specific operating systems: Windows, UNIX, Novell, VMS, and Macintosh. Two chapters look at very basic security requirements in part five. Network based attacks are discussed in part six, reviewing levels of attack, spoofing, telnet, scripting languages and extensions, and hiding of identity. Different types of resources and references are contained in appendices. (I was disappointed in the loss of a chapter on laws in various countries until I found it had been moved back here.)

If you don't know security, this book is probably not going to teach it to you. On the other hand, if you work with security, you may find that some of the resources listed here are things that you want to explore. For the novice it isn't altogether reliable, but for the professional it is at least worth looking at.

copyright Robert M. Slade, 1998 BKMAXSEC.RVW 981025 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com Robert Slade's Guide to Computer Viruses, 0-387-94663-2 (800-SPRINGER)

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

Date: Fri, 15 Jan 1999 08:18:30 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca> Subject: REVIEW: "Year 2000 in a Nutshell", Norman Shakespeare

BKY2KNSH.RVW 981030

"Year 2000 in a Nutshell", Norman Shakespeare, 1998, 1-56592-421-5, U$19.95/C$29.95 %A Norman Shakespeare %C 103 Morris Street, Suite A, Sebastopol, CA 95472 %D 1998 %G 1-56592-421-5 %I O'Reilly & Associates, Inc. %O U$19.95/C$29.95 800-998-9938 707-829-0515 nuts@ora.com %P 336 p. %T "Year 2000 in a Nutshell: A Desktop Quick Reference"

*Can* the Year 2000 problem be put in a nutshell? (Please?)

And isn't it just a tad late to be starting this? (On the other hand, Nutshell books *are* generally worth waiting for.)

Part one is a general overview of the situation. Chapter one starts with a rather exaggerated doomsday scenario, including concerns that have already been seen, and thus have been addressed. At the same time, it ignores the "upstream" multiplier effect of supplier and infrastructure failures. However, it does go on to note needs and concerns for management of the potential failures. Management and budgeting considerations are expanded in chapter two. Legal questions are addressed in chapter three, in a somewhat generic fashion. Some standard planning models and assumptions are given in chapter four. A little technical information in chapter five may help with calculations for dates and windowing or packing solutions. Chapter six looks at the desktop PC; which is interesting in view of a very heavy COBOL and IBM mainframe and mid-range emphasis elsewhere (as well as a few PC related goofs in the doomsday scenario). Unfortunately, some of the information is missing and some is wrong in regard to the desktop. There is no mention of a "cold rollover" test for the CMOS/system date, and the statement about Excel's date interpretation is incorrect. (I have confirmed this in my own testing.) On the other hand, the warning about internally developed applications is quite important.

Part two provides some forms and checklists to help organize a Year 2000 project, including triage, inventory, and a project template. There are about a hundred pages of COBOL references and tutorial in part three. Date functions get extensive listings in part four with attention to general types, COBOL, PL/1, MVS LE, Visual Basic, and C. There is a conceptual look at code scanners in chapters eighteen and nineteen. An appendix lists Web sites for Y2K vendors, tools, and other resources.

Was it worth waiting for this? I'm not sure. There is little wrong with the information, but neither is this a cut and dried quick fix that you might expect from the Nutshell series. An unrealistic expectation in the case of the disaster of the century, admittedly, but there you are. Still, with the big iron emphasis, and the big project orientation, the material is this work seems to be coming later than it would have been necessary to start these kinds of projects. There is relatively little in the volume for small businesses depending upon desktop machines, and almost nothing on fallback plans for non-compliance in the supply chain. The material is fine as far as it goes, but it doesn't go as far as it needs to at this late date.

On the other hand, it's no worse than any of the others.

copyright Robert M. Slade, 1998 BKY2KNSH.RVW 981030 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com Find virus, book info http://victoria.tc.ca/int-grps/techrev/rms.html

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

Date: 23 Sep 1998 (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) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

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