Text File

precedence: bulk Subject: Risks Digest 20.21

RISKS-LIST: Risks-Forum Digest Friday 12 February 1999 Volume 20 : Issue 21

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.21.html> and at ftp.sri.com/risks/ .

Contents: [Oops! on the month of the last issue. Fixed in archive copy.] Memo on Y2K (via Dave Stringer-Calvert) Y2K "fix" dates traffic offenses to 2097 (Christopher Neufeld) Computer fraud as another kind of Y2K risk? (Bruce Martin) Judge moves to ban sale of self-help legal software in Texas (Doneel Edelson) Risks of using power wiring for data traffic (Dan Pritts) Hacking Web/FTP Servers (Ian Cargill) CERT Advisory CA-99.03 - FTP-Buffer-Overflows (CERT) Dangers of being the lowest price (Eytan Adar) "Secure" fax (Steve Bellovin) Our New Time Machine (Michael F. Hogsett) Re: The NT Blue Screen of Death (Michael F. Hogsett) Re: The risks of "standard" software? (Michael F. Hogsett) Re: Programming Errors (Thomas J Gilg) REVIEW: "Fighting Computer Crime", Donn B. Parker (Rob Slade) REVIEW: "Intrusion Detection", Terry Escamilla (Rob Slade) SEPG `99 - 11th Software Engineering Process Group (SEPG) Conference (Carol Biesecker) Abridged info on RISKS (comp.risks)

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

Date: Thu, 11 Feb 1999 11:46:49 -0800 From: Dave Stringer-Calvert <dave_sc@csl.sri.com> Subject: Memo on Y2K (source unidentified)

Dear Boss:

I hope that I haven't misunderstood your instructions. Because to be honest, none of this Y to K problem makes any sense to me. At any rate I have finished the conversion of all of the months on all the company calendars for next year (year 2000). The calendars have returned from the printer and are ready to be distributed with the following new months:

Januark Februark Mak Julk

I've also changed the following days:

Mondak Tuesdak Wednesdak Thursdak Fridak Saturdak Sundak

In general, all references to "Day" were changed to "Dak" (e.g. "President's Dak"). And all references to "Birthday" were changed to "Birthdak" (e.g. "Washington's Birthdak").

I had a hard time deciding about "New Year's Day", "Martin Luther King, Jr. Day", "Yom Kippur", and "Hanukkah", but I finally changed them to "New Kear's Dak", "Martin Luther Ying, Jr. Dak", "Kom Yippur", and "Hanuyyah".

[1 April is still 1.5 months away, but it is never too early. However, I wish I could attribute this to its (unknown) author. The pun on common parlance of using "i2j" for naming a transform from i to j is really delightful. PGN]

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

Date: Fri, 12 Feb 1999 10:09:05 -0500 (EST) From: Christopher Neufeld <neufeld@physics.utoronto.ca> Subject: Y2K "fix" dates traffic offenses to 2097

In the Ottawa Citizen daily newspaper for Feb 12, 1999, an article appears about some Y2K silliness sending out notices of fines for traffic infractions. Notices of tickets issued in summer of 2097 went out, with warnings to pay before another date late in the twenty-first century. Estimates on the number of incorrect notices vary, from 207 across the province to 300 issued from a single court office.

Ministry of Attorney General spokesman Brendan Crawley is quoted as saying, "It occurred on a production run while the company was working on making itself Y2K compatible." Further down in the article he is quoted as saying, "It was just a matter of transposing every number 19 with the number 20, even when it wasn't right, and we've solved that problem."

One wonders how many companies are trying this particular windowing fix, in which no dates prior to Jan 1, 2000 can be represented. Putting the window in the year 2000 results in a rather severe discontinuity in the behaviour of the program, as it goes from being unable to represent any future dates to being unable to represent any past dates. I'm also led to wonder how many other companies are making and testing partial fixes on production equipment. I am not particularly comforted by the assurance that the particular problem leading to these erroneous notices has been solved.

Christopher Neufeld <neufeld@physics.utoronto.ca> http://caliban.physics.utoronto.ca/neufeld/Intro.html

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

Date: Thu, 11 Feb 1999 12:35:44 -0500 From: Bruce_Martin@manulife.com Subject: Computer fraud as another kind of Y2K risk?

Perhaps I've been reading too many Bruce Sterling novels, but it occurs to me as I listen to various Y2K scenarios that no one has addressed the very real possibility of computer fraud timed to coincide with the Year 2000.

Consider: The great majority of physical thefts are perpetrated under circumstances that favour the anonymity of the thief. The morning of 1 Jan 2000 is widely predicted to be chaotic. Random losses of wealth are not only possible but actually expected by many. (Certainly few insurance companies would be willing to underwrite such losses.)

Consider also: In preparation for Y2K, virtually all major wealth-bearing organizations are hiring vast teams of consultants to write and re-write the billions of lines of code their wealth depends on. Most of these consultants have never worked for their respective clients before, and many cannot expect to do so again once the Y2K crisis has passed.

It should not be difficult for a lone, less-than-scrupulous consultant to salt this sea of new and re-written code with just a few extra lines ...and as a result redirect a significant fraction of an organization's wealth to a blind account in the Cayman Islands at the stroke of midnight on 31 Dec 1999.

Who can prevent this? Likely not corporate auditors, too occupied with the question of their systems' integrity to consider their consultants' integrity. The possibility of recovering the missing funds will also be greatly diminished in post-Y2K confusion ("Hey, we were *expecting* losses, weren't we?"). In any event, the world is full of countries willing to protect the anonymity of a new multi-millionaire immigrant.

And so we have motive, opportunity and a diminished likelihood of retribution. It seems to me that the countdown to this sort of crime is already underway.

Bruce Martin, Toronto

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

Date: Wed, 3 Feb 1999 17:09:10 -0500 From: "Edelson, Doneel" <doneeledelson@aciins.com> Subject: Judge moves to ban sale of self-help legal software in Texas

Judge moves to ban sale of self-help legal software in Texas; Use of software is called unlicensed practice of law [AP item, 2 Feb 1999]

U.S. District Judge Barefoot Sanders is moving to ban the sale of self-help legal software such as Quicken Family Lawyer. Ralph Warner of Nolo Press said he considered this a step 20 years back into the past. [PGN Very Stark Abstracting]

[Judge the Quicken the Dead? PGN]

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

Date: Thu, 11 Feb 1999 13:57:45 -0500 From: Dan Pritts <danno@ans.net> Subject: Risks of using power wiring for data traffic

http://cgi.sjmercury.com/premium/front/docs/devilphone11.htm

Summary: cable TV decoder that calls in every night to record pay-per-view, combined with "wireless jacks" that send phone traffic across house power wiring, seem to have given San Jose family a $500 phone bill for calls made by someone else.

dan pritts, ans systems engineering, ann arbor, MI uunet worldcom 734-214-7409

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

Date: Fri, 12 Feb 1999 16:45:18 +0000 From: Ian Cargill <ian@soliton.demon.co.uk> Subject: Hacking Web/FTP Servers

There have been many press items recently about FTP and Web servers being hacked. Indeed, RISKS-20.18 had a couple of submissions about hacked software with Trojans/Trapdoors being placed on servers. This is *so* common, that I find it strange that there doesn't seem to be much demand for what I would see as a good - though not complete - solution; write-protectable hard drives.

Surely it would be very easy for HD manufacturers to produce drives with a *physical* 'off' switch which made it impossible to write to a drive unless you had physical access to the server. You would prepare updates 'off-line', switch the server drive to 'writable', update all the necessary files, then switch the drive back to 'write protected'. A second, 'normal' drive could be used to dynamically created pages.

I would have thought this easy, practical and going a long way to solving the problem. The seeming absence of any such drives suggests to me that I must be wrong. Can anyone explain to me why such a scheme would be impractical or unworkable?

Ian Cargill CEng MIEE, Soliton Software Ltd.

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

Date: Thu, 11 Feb 1999 18:11:43 -0500 From: CERT Advisory <cert-advisory@cert.org> Subject: CERT Advisory CA-99.03 - FTP-Buffer-Overflows

[RISKS does not generally include CERT Advisories, because we assume those needing to know are already receiving them. This one is excerpted, in light of Steve Bellovin's comments at several recent meetings to the effect that 8 out of the 13 CERT Advisories issued during 1998 involved security vulnerabilities caused by buffer overflows. That alarming ratio deserves greater attention. Here is one for 1999, affecting many different platforms. PGN]

CERT Advisory CA-99-03-FTP-Buffer-Overflows

Original issue date: February 11, 1999

Topic: Remote buffer overflows in various FTP servers leads to potential root compromise. Source: Netect, Inc.

To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Netect, Inc. Netect, Inc. urges you to act on this information as soon as possible. See Appendix C for Netect, Inc. contact information. Please contact them if you have any questions or need further information. [... <http://www.netect.com/>]

[The entire advisory is available from: http://www.cert.org/advisories/CA-99-03-FTP-Buffer-Overflows.html ]

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

Date: Mon, 8 Feb 1999 17:31:12 PST From: Eytan Adar <adar@parc.xerox.com> Subject: Dangers of being the lowest price

An interesting article appeared today on Wired's on-line site (http://www.wired.com/news/news/business/story/17803.html). Apparently, Buy.com made a mistake in its pricing of a Hitachi monitor and listed it as $164.50. This monitor was in fact $588.

So 48 hours later, and with 1600 monitors purchased, Buy.com has a public relations nightmare on its hands. The cost of this "typo" will be around $320,000 if Buy.com actually fulfills the order.

Aside from the obvious questions like, why they didn't notice a sudden blow up in orders for this monitor?, there is an interesting issue regarding Buy.com's policy of being the lowest price on the net.

My understanding, and I could be wrong about this, is that Buy.com actually has (ro)bots (automated agents) roving the net looking for cheaper prices. If they find a cheaper price the price automatically gets dropped on their site. Even if the process isn't driven by a bot but by a human I think the risk is still valid...

Now I can't say for sure that this is what happened, but you can see the obvious danger here. A retailer (that Buy.com competes with) somewhere on the net may have made its own mistake. The bot, not knowing any better, would have carried that price back to Buy.com. The other alternative, of course, is that someone could maliciously have set the price low. Either way, the "price virus" gets transmitted by an ignorant bot back to parent site, and we're back to our public relations nightmare.

e-commerce... gotta love it...

Eytan Adar

[If you are not careful, you just bot the farm. PGN]

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

Date: Thu, 11 Feb 1999 12:03:55 -0500 From: Steve Bellovin <smb@research.att.com> Subject: "Secure" fax

The 15 Feb 1999 issue of *Newsweek* describes an Internet-based fax product. You sign up with them and get a 10-digit phone number; faxes to that number are emailed to you. This is described by *Newsweek* as good for confidential faxes, since it bypasses the company fax machine. There's no mention about the risks of sending confidential information through a third party.

Trying to learn how this company protects your information is itself a bit amusing, since *Newsweek* may have gotten the name wrong. In the on-line version at least, it's listed as www.e-fax.com, a site that is apparently under construction. Did *Newsweek* mean www.efax.com, which offers a similar service? Its pages demand a careful read-through on the subject of security. Among other things, one learns that faxes are "protected" by a password -- they seem to avoid the word "encrypted", which may be a clue. And even that level of protection is only available if you use their viewer on a (of course) Windows platform; users of other systems (whose existence they at least acknowledge the existence of!) are sent unprotected TIFF files. There's noo mention of anything like PGP.

I should note that at least in the press releases accessible via the e-fax Web site, they make no claims about the superiority of their product for confidential material. That seems to be *Newsweek*'s spin. Efax does promise to be careful with your data, though.

One more risk -- it takes a lot of wading through the fine print of the privacy policy to realize that you're signing up to receive electronic junk mail. This is apparently an advertising-supported service, which is not in itself wrong or evil -- they should just say so in a more upfront fashion.

Steve Bellovin

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

Date: Thu, 11 Feb 1999 12:26:06 -0800 From: "Michael F. Hogsett" <hogsett@csl.sri.com> Subject: Our New Time Machine

It appears as though our new switch / router doubles as a time machine.

I was performing a few tests, one of which was a flood ping. The minimum round-trip time has been consistently negative...

It is either sending ICMP replies from the future or anticipating them...

# ping -f 192.168.1.10 PING 192.168.1.1 (192.168.1.10): 56 data bytes ................ --- 192.168.1.10 ping statistics --- 2583 packets transmitted, 2568 packets received, 0% packet loss round-trip min/avg/max = -8.0/1.9/7.1 ms

(Well, OK, the most likely thing is that there is a bug in the ping program under Linux... )

Mike

[Note: The IP address has been altered to protect the innocent. PGN]

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

Date: Thu, 11 Feb 1999 09:48:27 -0800 From: "Michael F. Hogsett" <hogsett@csl.sri.com> Subject: Re: The NT Blue Screen of Death (RISKS-20.20)

> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\CrashControl\AutoReboot to 1. > Once you've changed this value, NT will reboot after writing the crash log > file.

Assuming of course that the crash did not corrupt the data structure storing the 1, replacing it with an invalid value.

Michael Hogsett

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

Date: Thu, 11 Feb 1999 09:52:15 -0800 From: "Michael F. Hogsett" <hogsett@csl.sri.com> Subject: Re: The risks of "standard" software? (RISKS-20.20)

> Nobody uses that size anymore, because Word doesn't use it. Therefore it is > no longer a standard size, and no longer a standard stock item.

So assume that if Word no longer prints onto 8.5 x 11" paper that the entire industry will stop producing it.

Michael Hogsett

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

Date: Mon, 8 Feb 1999 13:46:49 -0800 From: "GILG,THOMAS J (HP-Corvallis,ex1)" <Thomas_Gilg@ex.cv.hp.com> Subject: Re: Programming Errors (Gilham, RISKS-20.18)

> [...] In two days he has reports three > instances of the following common C error: > if (x = y) instead of if (x == y)

Sorry, but another common C error is to assume the above. Consider if the intent of the expression was:

if ( pChar = pMyString ) { // increment pChar through my string looking for tokens ..... }

Granted the more visually obvious coding style would have been:

if (pMyString) { pChar = pMyString // increment pChar through the string looking for tokens ..... }

Thomas Gilg <tomg@cv.hp.com>

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

Date: Wed, 10 Feb 1999 12:19:41 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Fighting Computer Crime", Donn B. Parker

BKFICMCR.RVW 981106

"Fighting Computer Crime", Donn B. Parker, 1998, 0-471-16378-3, U$34.99/C$49.50 %A Donn B. Parker dparker@sric.sri.com %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1998 %G 0-471-16378-3 %I John Wiley & Sons, Inc. %O U$34.99/C$49.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com %P 512 p. %T "Fighting Computer Crime: A New Framework for Protecting Information"

Parker feels that too much of the data security field concentrates on technical answers to the problems of reliability, integrity, and availability of data, and doesn't pay sufficient attention to those people who are deliberately out to read, steal, or ruin your information and systems. Personally, I find it rather ironic that he defines "crimoids," in chapter one, as minor events promoted to much higher significance by the media, and public misperceptions. In the non-specialist realm, more people spend more time worrying about "hackers" than ever back up their drives. (I am reminded of a friend; an intelligent and educated person who started his career programming large and sophisticated information systems and who has now risen to the executive ranks; who has for years refused to get a modem for his home computer. In spite of his frequently expressed desire for access to the Internet, and my repeated assurances that with his current computer and operating system there is no hidden danger, he remains convinced that the mere attachment of a modem to his machine will allow someone to break into his computer and damage it.)

Who, then, is this book written for? The author does not say, but what he does say in the preface seems to indicate that he is not writing for those whose business cards make reference to security. (I have neither argument nor inclination to dispute Parker's assertion that security "professionals" do not really deserve the designation.) But if this text is aimed at the general public, chapter one's emphasis on the dangers and lack of protection would seem more inclined to incite further panic, rather than a realistic and measured response.

Chapter two is an interesting and useful examination of an often unasked question in the field: what is the nature of the information we are supposedly securing? There are valuable side points, such as both the danger and the opportunity in the security arena presented by the Year 2000 problem. At the same time, I have to note that an erroneous description of the Cascade virus is an example of Parker's asserting points that are just beyond the available facts, and, for me anyway, has an unfortunate effect on the trustworthiness of the work as a whole. The review of cybercrime, in chapter three, has more reference to journalism and other forms of fiction than to reality, but I have to agree with everything said there. Computer misuse and abuse is discussed in chapter four. (As if to make up for chapter two, the section on viruses is very good.) Network misuse is covered in chapter five, and although I still have trouble believing in the reality of salami attacks (Parker's sole example is said to have resulted in a conviction, but no citation is given) I am a bit more willing to accept his broader definition. Chapter six is extremely strong in portraying a realistic and broadly based analysis of characteristics of computer criminals. A similarly informed and balanced approach distinguishes chapter seven, regarding hacker culture, but there is also a universally condemnatory tone that is not wholly justified by the facts as presented. Chapter eight is a very helpful first step for those wanting to deal in the art of computer security.

Chapter nine reviews the deficiencies in most current security practices, noting overprotection in some areas while ignoring loopholes in others, and a flowery jargon that serves mostly to hide the fact that security people just don't feel very comfortable with what is going on. However, Parker's new model of security, in chapter ten, while it is very clear and useful, does not extend recent work in, say, electronic commerce. On the one hand, this congruence does support the model, but on the other, one can't really say it is too novel. The popular, but demonstrably incomplete, risk assessment study is de-emphasized in favour of a more difficult, but more realistic, baseline security standard in chapter eleven. Details on how to conduct such a study are very helpfully given in chapter twelve, although the benchmark chart is going to be much harder to come by than is made clear in the text. Chapter thirteen provides a practical and useful set of criteria for determining control objectives. A number of security tactics are detailed in chapter fourteen. Chapter fifteen takes the larger strategic view. (I was delighted to see the inclusion of a section on corporate ethics in this chapter. Recently I contracted to produce a security document for an educational institution, and was told to take the section on ethics out.) Management of security, in chapter sixteen, includes provisions for training, policy, and other factors. Chapter seventeen finishes off with a look to the future. The material, while thought- provoking, is possibly more likely to generate arguments than solutions.

Parker's stance on security in general definitely puts him in the camp of the professional paranoids. However, absent the first and last chapters, there is a lot of good, solid knowledge here to help educate any security practitioner. The material in the second half of the book is just as valuable to the security process as the more technical works such as "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW) by Spafford and Garfinkel, albeit in quite a different way. An informed security policy is every bit as important as a good set of "access" controls.

copyright Robert M. Slade, 1998 BKFICMCR.RVW 981106 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com

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

Date: Fri, 12 Feb 1999 08:33:14 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Intrusion Detection", Terry Escamilla

BKINTRDT.RVW 990108

"Intrusion Detection", Terry Escamilla, 1998, 0-471-29000-9, U$39.99/C$56.50 %A Terry Escamilla %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 1998 %G 0-471-29000-9 %I John Wiley & Sons, Inc. %O U$39.99/C$56.50 416-236-4433 fax: 416-236-4448 rlangloi@wiley.com %P 348 p. %T "Intrusion Detection: Network Security Beyond the Firewall"

Maybe my perception is skewed from having been involved with physical security as well as the computer kind, but I see intrusion detection as being part of security. There is no security system that cannot be penetrated or bypassed, and so detection is, in my view, simply a fact of security life. Isn't that what auditing, one of the main pillars of data security, all about? So I find the attempt to sell the idea of intrusion detection somewhat redundant. Then there is the emphasis on reviewing commercial Intrusion Detection Systems (IDS).

Part one looks at what happens before intrusion detection: the traditional role and model of computer security. Chapter one provides a brief, but reasonably sound, overview of this classic paradigm, concentrating on defining most of the theoretical terms used. Some identification and authentication details from both UNIX and Windows NT start our chapter two, which then meanders through a few examples of password cracking, and finally ends with a look at ticket granting systems and other authentication improvements. A similar look at access control is provided by chapter three. Given the complexity of networking and network security, the number of topics covered in chapter four is unsurprising.

Part two looks at intrusion detection by extending the traditional security design. Chapter five is fairly pivotal, as evidenced by the title "Intrusion Detection and Why You Need It." The "why" part comes first, with a rather weak example showing that security systems can have loopholes if you don't configure or program everything properly. Intrusion detection then seems to be defined as the usual game of find vulnerability-fix-repeat, only in automated form. A number of possible attacks are mentioned in chapter six, and then a promotion of the addition of an IDS layer to a system, without a corresponding reiteration of the warning, from chapter four, that layers in a system increase the possibility of loopholes. I was rather astonished that SATAN [Security Administrator's Tool for Analyzing Networks] was not included with the vulnerability scanners mentioned in chapter seven. Two more sophisticated products are reviewed in chapter eight. Chapter nine looks at the possibility of catching intruders by traffic analysis, although "catch" seems to be too strong a term to use here. Since most of the foregoing deals with UNIX, chapter ten looks at similar products for NT, although most of the material seems to concentrate on NT's own audit logs.

Part three looks at dealing with an intrusion once you have detected it. Chapter eleven recommends being prepared well, detecting early, analyzing thoroughly, and deciding judiciously. In one useful piece of advice, it recommends against an attack on a system you may think is hitting on yours. Chapter twelve is a quick summary of the book.

As the author admits, in the final chapter, that intrusion detection systems are not the final word in computer security, I am inescapably reminded of the battles in the antiviral field over the relative strengths of scanners, activity monitors, and change detection systems. What works best? A combination approach, of course. The price of a secure system is more budget for administration time and tools. This book does not present any radically new approach or technique for system security. In fact, with the emphasis on proprietary commercial products, the work will date quite quickly. For those who are looking to add an automated IDS to their current network, the volume could act as a kind of incomplete buyer's guide.

copyright Robert M. Slade, 1999 BKINTRDT.RVW 990108 rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com

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

Date: 10 Feb 1999 20:14:55 GMT From: cb@SEI.CMU.EDU (Carol Biesecker) Subject: SEPG `99 - 11th Software Engineering Process Group (SEPG) Conference

SEPG `99 - The 11th Software Engineering Process Group (SEPG) Conference Theme: Software Process Improvement (SPI) Investments Today for a Changing Tomorrow March 8-11, 1999 Hyatt Regency Atlanta, Atlanta, Georgia

For complete details, including the preliminary program, and registration information, visit the SEI Web site at: http://www.sei.cmu.edu/products/events/sepg/

Customer Relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone, Voicemail, and On-Demand FAX: 412 / 268-5800 E-mail: customer-relations@sei.cmu.edu World Wide Web: http://www.sei.cmu.edu/products/events/sepg/

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

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