precedence: bulk Subject: RISKS DIGEST 19.47 RISKS-LIST: Risks-Forum Digest Weds 26 November 1997 Volume 19 : Issue 47 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. ***** Contents: *Happy Thanksgiving* today to Outlook 97! California's Deadbeat Dads Database (PGN) Forbes blames sabotage on hacker (Stevan Milunovic) With autopilots, who needs a dog to keep an eye on the pilot? (Robert Dorsett) Hacking cost businesses $800 million worldwide (Stevan Milunovic) Encryption of electronic mail in the European Community (Mike Ellims) Y2K and canned-goods expiration dates (Fernando Pereira) Ottawa firm registers "Y2K" as trademark (Yves Bellefeuille) Perils of grammar checkers (Azeem Azhar) Re: Major security flaw in CyberCash 2.1.2 (Steve Crocker) Another AOL meltdown (Ed Fischer) Problems with AOL (Simson L. Garfinkel) Risks of changed URLs (Arthur Flatau) Risks of blind acceptance (David Lesher) Re: Outlook for Thanksgiving (Guy J Sherr, Chris Adams) "Halting the Hacker" by Pipkin (Rob Slade) Re: Workaround for the new Pentium flaw (Roland Roberts) Pentium halting -- who needs DEBUG? (David G. Bell) Re: New Pentium flaw (Leonard Erickson, Robert Stanley, Nick Rothwell) Re: Pentium Fix? (Pekka Pietik{inen) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 24 Nov 97 14:08:02 PST From: "Peter G. Neumann" Subject: California's Deadbeat Dads Database (RISKS-19.12, 19.43) We noted in RISKS-19.12 and 19.43 that there have been serious development difficulties in connection with SACSS, the California Statewide Automated Child Support System. Finally, California Health and Welfare Agency announced on 20 Nov 1997 that the contract with Lockheed-Martin IMS has been cancelled altogether. [Source: Robert B. Gunnison, *San Francisco Chronicle*, 21 Nov 1997, A30. The article also notes that a new Cal DMV system was abandoned in 1994 after spending $50 million, and that problems with the Cal lottery system cost the state many millions.] ------------------------------ Date: Tue, 25 Nov 1997 09:01:00 -0800 From: stevan@netscape.com (Stevan Milunovic) Subject: Forbes blames sabotage on hacker Federal prosecutors in New York City have charged a former Forbes employee George Parente with breaking into Forbes' computers after he was dismissed 21 April 1997, sabotaging the systems, and causing what the company estimated was more than $100,000 in damage. The computer outages caused employee inconvenience and necessitated significant effort in restoring programs and lost data. Parente faces up to five years in prison, but has denied the charges. Evidence includes a 55-minute phone call to a Forbes computer line made that evening. The crash occurred the next morning. [Source: *The New York Times*, 25 Nov 1997. PGN Abstracting] [In an unrelated case, Senal Arabaci, 31, a Manhattan computer programmer, was charged Monday with sabotaging a computer system at Art Assets LLC by deleting and modifying files after a billing dispute with the company. He was released on a $50,000 bond. [Excerpt from an AP item, 25 Nov 1997, on the Forbes case, noted by Don_Rosenberg@compuserve.com. PGN] ------------------------------ Date: Mon, 24 Nov 1997 07:18:40 -0800 (PST) From: Robert Dorsett Subject: With autopilots, who needs a dog to keep an eye on the pilot? On 23 Nov 1997, Paul Sirks got out of his plane in an attempt to restart the engine by cranking the propeller. The plane took off on its own without him, reached 12,000 feet, and flew for two hours before running out of gas and crashing into an unoccupied bean field northwest of Columbus, Ohio. [UPI item, 24 Nov 1997, PGN abstracting] ------------------------------ Date: Nov 1997 [exact date clobbered, source lost in original posting] From: Stevan Milunovic Subject: Hacking cost businesses $800 million worldwide Worldwide, hackers cost businesses an estimated $800 million in 1995 through break-ins to computer systems at banks, hospitals, and other large businesses, according to investigators of the Senate's Permanent Investigations Subcommittee. Despite the staggering losses, few businesses report the security breaches for fear of negative publicity that could scare off customers, officials say. Also, most losses incurred by banks do not appear in required federal reports. The subcommittee's eight-month investigation showed that security problems seem to be worse in the private sector than in government. More than $400 million of the calculated losses were attributed to U.S. businesses. Fear of hacker attacks has prompted many corporate users to boost budgets for security spending. A study conducted by http://www.yankeegroup.com/ . The Yankee Group, a Boston-based consulting firm, and *Infosecurity News* showed that corporate security budgets have already increased by 25 percent, with more increases expected this year. The study also concluded that nearly half of all break-ins are committed by internal users. [Source (added in Archive copy): Mike Ricciuti, 6 Jun 1996. NEWS.COM at http://www.novell.com ] ------------------------------ Date: Thu, 20 Nov 1997 17:33:37 -0000 From: Mike Ellims Subject: Encryption of electronic mail in the European Community The *Guardian* has recently (actually I'm rather tardy) published two articles on the use of encryption to protect communications. The first dealt with the (possible) reasons that the US and UK governments wanted to control the use of encryption. The second (published 16 October 1997) dealt with the an EC report, Ensuring Security and Trust in Electronic Communications (on the web, according to the article at www.ispo.cec.bei/eif/policy/97503.ntml I looked but couldn't connect). ["html" typo fixed in ARCHIVE copy. PGN] The first paragraph reads "US and British intelligence agencies received a major blow last week, when the EC urged governments to introduce uniform and effective encryption standards to protect communications on the Internet, writes Duncan Campbell. In a landmark report, the EC asserted that legal recognition and standards for digital signatures, which depend on effective cryptography, should be put in place across the EU by 2000 "at the latest"." Other interesting comments include the following. "Although the EU concedes that individual governments can, in principle, make their own national security arrangements, member states are now being warned that restrictions on importing or exporting cryptographic products may be unlawful under sections of the European treaty, as well as contrary to existing community directives". The article goes on to say, "The Commission says it found no evidence that regulation could or would stop criminals from using effective encryption." Full text of both articles is at http://online.guardian.co.uk/archive.html, limiting the search year to 1997 and use the search string "crypto*" to bring up two articles from 17 Sep and 15 Oct. Mike Ellims Pi Technology +44 (0)1223 441 256 [DISCLAIMERS] ------------------------------ Date: Wed, 26 Nov 1997 09:49:58 -0500 From: Fernando Pereira Subject: Y2K and canned-goods expiration dates A friend who manages one of the Y2K compliance projects at a major US-based multinational corporation reports the following (some light editing to protect sources and to consolidate several messages): Just heard this one from one of our expat Brits in Zurich. Apparently [a large food retail chain in Britain] has these highly automated regional distribution centers. They are starting to receive canned goods with expiration dates running past 2000. So, at the same time as they were receiving shipments of tinned tomatoes with shelf lives until '05 (which were being shuffled into storage bins by their automated pallet system), their automated "expired goods" system was scanning the new stuff, thinking they had gone bad 92 years ago, pulling them, and putting them on to lorries which then took them to the dump. [...] after trashing the "expired" tins, the automated system placed an order to the supplier to replace them. Apparently some guy at the warehouse noticed this but didn't want to say anything [...] It was only when the tomato company's sales rep said something like, "Jeez, you guys are selling a lot of our tinned tomatoes lately," that they caught on. Besides the usual Y2K issues, two other risks are worth noting: 1. Either the system has no autoamted tripwire mechanism to alert operators about major deviations from suitable running averages, or its thresholds are not set properly. 2. The usual organizational risk of people being afraid of rocking the boat. Caveat: I trust my direct source, but this is a "friend of a friend" kind of story, so there's a slight chance that this could be a Y2K urban legend, if nothing else because it's so exemplary. ------------------------------ Date: Wed, 19 Nov 1997 02:43:41 -0500 From: Yves Bellefeuille Subject: Ottawa firm registers "Y2K" as trademark According to the _Ottawa Citizen_, 17 November 1997, p. C1, an Ottawa consulting firm has registered the term Y2K as a trademark, "making it illegal for others to use the term". Main points: - I-T Net Consultants began looking into getting a trademark in 1995. "'Lo and behold, no one had registered it'". - "Two months ago, I-T Net received a letter giving it official rights to the Y2K term". - "'We're not going to get litigious', said Mr. Beraskow. Instead, as the company notices Y2K being used, it will send a letter informing the organization that Y2K is a trademarked term". - "I-T Net will probably let its own clients use Y2K for 'a nominal fee'... However, Mr. Beraskow said the company would take organizations to court if they continue to refuse to stop using the term." There's no mention as to whether I-T Net claims the trademark is valid in other countries. Yves Bellefeuille, Ottawa, Canada [Does that cover "y2k" also? PGN] ------------------------------ Date: 24 Nov 1997 11:03:45 GMT From: "Azeem Azhar" Subject: Perils of grammar checkers A friend of of mine recently ran into this problem with the Word 97 grammar checker: > Word 97 grammar checker wants me to change > "we will not be issuing a credit note" to > "we will be issuing a credit note" Who checks the grammar checker? Azeem (az ! at ! pobox ! dot ! com) BBC ------------------------------ Date: Fri, 21 Nov 1997 20:26:57 -0500 From: Steve Crocker Subject: Re: Major security flaw in CyberCash 2.1.2 The following message appeared on the net. > From: Anonymous > Subject: Major security flaw in CyberCash 2.1.2 > To: BUGTRAQ@NETSPACE.ORG > > CyberCash v. 2.1.2 has a major security flaw that causes all credit card > information processed by the server to be logged in a file with > world-readable permissions. This security flaw exists in the default > CyberCash installation and configuration. > > The flaw is a result of not being able to turn off debugging. Setting the > "DEBUG" flag to "0" in the configuration files simply has no effect on the > operation of the server. > > In CyberCash's server, when the "DEBUG" flag is on, the contents of all > credit card transactions are written to a log file (named "Debug.log" by > default). > > The easiest workaround I've found is to simply delete the existing Debug.log > file. In my experience with the Solaris release, the CyberCash software > does not create this file at start time when the DEBUG flag is set to 0. > > The inability to turn off debugging is noted on CyberCash's web site under > "Known Limitations". The fact that credit card numbers are stored in the > clear, in a world readable file, is not. We have taken this quite seriously and have put through a full release of our software which will be available Monday 24 Nov for three platforms and others shortly thereafter. The flaw was in the debug logging function, not in the protocols or core implementation. Nonetheless, the effect was an unnecessary exposure of potentially sensitive information, and it shouldn't have gone out the door that way. We're tightening our internal processes to avoid this in the future. That said, here's the actual exposure. The credit card information that's in the clear in the log comes from "merchant-initiated" transactions, which means the merchant obtains the credit card number from somewhere -- phone, mail, fax, SSL-protected Internet interaction, or unprotected Internet interaction. The merchant thus has the same info in the clear already. If the card number was provided via a wallet, then the card number is blinded at the consumer's end. It is therefore not in the clear as it passes through the merchant's machine and the reported exposure does not apply.. In order for the unprotected log to pose a risk of exposure, someone has to be able to gain access to the merchant's machine. If the machine is well protected, viz behind a firewall and/or carefully configured, presumably an outsider won't be able to gain access. And in terms of the *additional* exposure the open log represents over existing risks, if the same information is accessible in the clear elsewhere on the machine, eliminating from the log or encrypting the log provides little or no real protection. We continue to advise merchants to take strong steps to protect their machines. To our knowledge, the exposure documented above has not resulted in the actual loss of any customer data or other security incident. Dr. Stephen D. Crocker, Chief Technology Officer, CyberCash, Inc. 2100 Reston Parkway, Reston, VA 20191 crocker@cybercash.com +1 703 716 5214 ------------------------------ Date: Tue, 18 Nov 1997 14:06:05 -0500 (EST) From: EdFischer@aol.com Subject: Another AOL meltdown On Tuesday, 18 November 1997, America Online suffered a variety of breakdowns that left users without service. Starting sometime before 8 a.m. ET, AOL responded at various times with "Unable to send mail at this time." "Unable to receive mail at this time." "There has been a temporary delay in the connection process." and "The system is temporarily unavailable." Some users could retrieve their mail by about 12:45 p.m. ET, but it was impossible to send mail until shortly before the time stamp on this message, which is when I was finally able to send it to you via AOL. One Risk, often repeated: The bigger and more complex systems get, the more prone to problems. Edward Fischer, Director, Information Systems, Post Newsweek Stations, Inc. 3 Constitution Plaza, Hartford, Connecticut 06103 Voice: (860) 493 2522 ------------------------------ Date: Wed, 26 Nov 1997 10:20:46 -0500 From: "Simson L. Garfinkel" Subject: Problems with AOL Since Wednesday, 19 Nov 1997, AOL seems to have had significant Internet connectivity problems. Many customers who use local ISPs to telephone AOL (using AOL's TCP/IP connection option) have been unable to get through. Other ISP customers have been unable to reach the AOL website. And there are reports that mail between AOL and MSN is not properly function. Complicating the diagnosing of this problem is the fact that AOL seems to be blocking some IP services (such as PING) put allowing others to pass (such as HTTP) to various hosts. Further complicating the problem is that AOL's standard response, when people call the company's technical support hotlines, is to say that the fault lies with the customer's local ISP, and not with AOL itself. I have verified that connectivity problems between AOL and the rest of the Internet exist from at least two locations: * Vineyard.NET (204.17.195.100) * MIT Media Lab (18.85.0.2) I have also spoken with people in California who have reported similar connection problems. I have personally called America Online on several occasions. Each problem they say that the problem is with my Internet Service Provider, and not with their Internet connection. This seems unlikely. Speaking with my upstream Internet provider, I am told that the problem may be with the Routing Arbiter database (www.ra.net), which apparently crashed several times in November. What this is showing is the problems of an open network in dealing with quality-of-service problems. It shows the ease of finger-pointing on the Internet today, and the difficulty of accountability. It also shows the real problems when there are large, national networks which fundamentally nobody is in charge of. I do not know when, if ever, this problem is going to be resolved. In the meantime, many, many people cannot reach AOL. Not that this is necessarily a bad thing, mind you. ------------------------------ Date: Tue, 25 Nov 1997 15:53:57 -0600 From: Arthur Flatau Subject: Risks of changed URLs This is not a new risk, but I thought it was interesting nonetheless. I subscribe to a mailing list about bone marrow transplants. Recently one of the other subscribers complained about "A"'s web site. "A" was trying to raise money to pay for a bone marrow transplant (BMT) for herself and had a web site that announced this. She also had links to other web site's including one to "B"'s site. To confuse matters further "A" and "B" have the same first name. The complaint was that the link to "B" site, instead brought up a porn site. The complaint was whether "A" was in fact legitimately raising for a BMT or just another scam. The other alternative was that someone had hijacked "B" site. The true explanation was much more mundane. In fact "B" site had moved several months ago and "A" had not updated her link. It appears that the old ISP had been bought by "Free XXXPics Unlimited" and were recycling the URL. This is not really a new risk as phone numbers have always been recycled, perhaps less frequently then they are now. It does seem like something that will become more frequent in the future. My attempt at hiding the identities of the innocent ("A" and "B") is probably futile as the identities are probably easy to determine by starting with my home page or using a net search. Art Flatau Austin, Texas http://www.acor.org/diseases/hematology/Leukemia/leukemia.html ------------------------------ Date: Mon, 17 Nov 1997 18:53:35 -0500 (EST) From: David Lesher Subject: Risks of blind acceptance *Marketplace* Radio just reported that Scott Adams posed as a "management consultant" at Logitech, Inc [with the help of its president and a wig...] and managed to get the working group to rewrite the mission statement from a simple, straightforward page to an obfuscated jargon-filled morass. No one person questioned the sanity of the input data. The RISK? Is this the human form of "Of course it's correct, the computer says so..." perhaps? Sigh... "Clothes Make the Man, Babble makes the Expert." ------------------------------ Date: Mon, 17 Nov 1997 16:24:46 -0500 From: Guy J Sherr Subject: Re: Outlook for Thanksgiving (Minow, RISKS-19.46) Robert X. Cringely's article is at: [TYPO FIXED IN ARCHIVE] I did a little research with Outlook 97, and have divined the following schedule. Wednesday, 26 November 1997 Wednesday, 25 November 1998 Tuesday, 23 November 1999 Wednesday, 22 November 2000 Wednesday, 28 November 2001 Wednesday, 27 November 2002 Tuesday, 25 November 2003 Wednesday, 24 November 2004 Wednesday, 23 November 2005 Beyond this date, there is Thanksgiving no more. The last holiday of 2006 appears to be Election Day. That seems to be it. No more holidays after Election Day, 2006. The implication of Election Day is truly horrifying. ------------------------------ Date: Tue, 25 Nov 1997 12:40:26 -0800 From: Chris Adams Subject: Re: Outlook for Thanksgiving (Minow, RISKS-19.46) [...] Although Microsoft tends to let dates slide, this is the first one I've heard them advance... Chris Adams ------------------------------ Date: Fri, 21 Nov 1997 11:21:37 EST From: "Rob Slade" Subject: "Halting the Hacker" by Pipkin BKHLTHCK.RVW 970706 "Halting the Hacker", Donald L. Pipkin, 1997, 0-13-243718-X, U$44.95/C$62.95 %A Donald L. Pipkin %C One Lake St., Upper Saddle River, NJ 07458 %D 1997 %G 0-13-243718-X %I Prentice Hall %O U$44.95/C$62.95 201-236-7139 fax: 201-236-7131 betsy_carey@prenhall.com %P 193 %T "Halting the Hacker: A Practical Guide to Computer Security" This book is a compilation of observations on computer security, particularly on network connected computers, and particularly in regard to outside intruders. What specific system information is included relates to UNIX. Most of the advice is generic. The information is "practical" in that it relates to common, rather than theoretical, attacks. However, the text does not provide practical answers: the defenses are left as an exercise to the reader. There is nothing really wrong with the information provided in the book. (I wasn't too thrilled with the section on viruses, but we'll let that go.) It has all, though, been said before, notably by works such as Spafford and Garfinkel's "Practical UNIX and Internet Security" (cf. BKPRUISC.RVW). In fact, there were passages that I'm quite sure I could have traced as to origin and author. Normally, I don't comment on CD-ROMs unless something unique is available. As with most such disks, this one provides information that is available elsewhere, mostly from COAST. Overall, though, in this case I think the CD-ROM does add some value, holding information such as the "Rainbow series" of security standards, and a list of machine address codes for Internet addressing as assigned to vendors. copyright Robert M. Slade, 1997 BKHLTHCK.RVW 970706 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca ------------------------------ Date: 17 Nov 1997 15:43:51 -0500 From: Roland Roberts Subject: Re: Workaround for the new Pentium flaw Microsoft has subsequently posted an official statement as to what they are doing. What I find most interesting is their temporary "work-around": ...Since this erratum can only be exploited by a program that was developed with malicious intent and deliberately uses this illegal instruction, following common-sense computing practices, such as not downloading or running executables from unknown sources, can protect a user from this problem. Since Microsoft Active-X is essential "downloading or running executables from [possibly untrusted] sources", Microsoft is inviting everyone not to use Internet Explorer. Of course, I don't expect them to actually say that nor do I expect most people to realize that merely "browsing" may constitute "downloading and running". Roland B Roberts, PhD, Muller Data Corp, 395 Hudson Avenue, New York, NY 10014 USA 1-212-807-5143 rroberts@muller.com ------------------------------ Date: Mon, 17 Nov 97 20:12:55 GMT From: dbell@zhochaka.demon.co.uk ("David G. Bell") Subject: Pentium halting -- who needs DEBUG? Using DEBUG? You don't need to do that... The decimal versions of the bytes can be entered on a PC using + and all you need to start is the command: copy con kill.com And finish with ctrl-z to close the file and return to the command prompt. Or how about a batch file, using a line of the form: echo > kill.com And if you tell programmers that today they don't believe you. People often forget what can be done with batch files that use only standard shell commands, and I wouldn't be surprised if the same can be done with Unix-like operating systems. David G. Bell -- Farmer, SF Fan, Filker, Furry, and Punslinger.. ------------------------------ Date: Mon, 17 Nov 1997 22:50:30 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Re: New Pentium flaw (someguy, RISKS-19.46) someguy@somethingorother.com writes: > Here is how to use DEBUG to create a DOS executable that exercises the new > flaw. DEBUG is available on DOS, Windows 3.x/95/NT and OS/2, and maybe > others. No need to use DEBUG. Every single one of the 4 bytes required can be entered directly from the keyboard! Get to a DOS prompt and type this: copy con kill.com And then hit return. Hold down the alt key and type 240 using the numeric pad. Release the alt key. Hold down the alt key and type 15 using the numeric pad. Release the alt key. Hold down the alt key and type 199 using the numeric pad. Release the alt key. Hold down the alt key and type 200 using the numeric pad. Release the alt key. Press the F6 key. Press enter. You now have the KILL.COM file... Run at your own risk. As an old sig file says: Real programmers use COPY CON FILE.EXE Leonard Erickson (aka Shadow) shadow@krypton.rain.com ------------------------------ Date: 18 Nov 1997 14:47:39 GMT From: Stanley@@nr1.ottawa.istar.net (Robert Stanley) Subject: Re: New Pentium flaw (someguy, RISKS-19.46) I was amused, and pleased, to note that running this in the DOS box of an OS/2 Warp system resulted in an OS/2 exception, which is a recoverable situation, and not a halt-and-catch-fire of the Pentium. Robert Stanley -- Stanley@Simware.COM ------------------------------ Date: 18 Nov 1997 11:15:21 -0000 From: Nick Rothwell Subject: Re: New Pentium flaw (Strayer, RISKS-19.46) > While I'd rather there wasn't "halt and catch fire" instruction for the > Pentium, programs that crash the PC aren't exactly rare. Actually, no program has ever crashed my PC. That's because it runs Linux. Your argument here is basically: because a huge percentage of Pentium-based computers are not properly protected by the OS against unprivileged software crashing them, there is no need to worry about a hardware bug which would bypass a proper protected-mode OS. This kind of bug cannot be circumvented even by competent OS design. (Interestingly, this particular bug has been - in Linux and BSDI at least. I'm waiting to see how long it takes for fixes to appear in less competently-designed popular operating systems.) Nick Rothwell, CASSIEL http://www.cassiel.com ------------------------------ Date: Tue, 18 Nov 1997 09:49:00 +0200 From: "Pekka Pietik{inen" Subject: Re: Pentium Fix? Actually the fix is far more clever than checking the memory for that instruction sequence, and works perfectly. connecting (ROOT):~ >./crash zsh: illegal hardware instruction ./crash model : Pentium 75+ vendor_id : GenuineIntel stepping : 5 f00f_bug : yes The fix (described in www.intel.com) basically puts the IDT (a list of addresses the processor jumps to when various software interrupts like illegal instructions or page faults happen) on a page boundary so that the first thing on the next page is 0xe (page fault), and instruction fault is on the first page. The first page is left unmapped. When someone runs the f00f code (or any invalid instruction) the processor naturally tries handles the invalid instruction. Before the fix the processor would have died while handling it, but since it can't jump to the handler because it can't find the address to jump to, it gets a page fault. This page fault puts the processor into a sane state, and now some code in the page fault handler can check what really happened and handle the situation properly. The fact that this fix works is only caused by the fact that the instruction fault (and nothing performance-critical) happens to be before the page fault in the IDT. If it hadn't been, Intel would be in some trouble. There is a small performance loss, but it's unnoticeable. Pekka Pietikäinen, Net People Ltd., Oulu, Finland [The above messages relating to the new Pentium flaw are just a sampling of those received. PGN] ------------------------------ Date: 1 Apr 1997 (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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.47 ************************