Subject: RISKS DIGEST 16.56 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 14 November 1994 Volume 16 : Issue 56 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** Contents: Catalogin' (Henry Cate) Worker cleared of deleted planning files (Vinc Duran) "Netsafe makes the Internet safe for K-12 schools" (Forman) Alberta vote-by-phone fiasco (Mich Kabay) Rob Slade's review of Robert Slade's book (Rob Slade) Re: EMI and construction cranes (Michael P. Hartley, Arthur Byrnes) Re: Ottawa Library fines people ... (Peter Kaiser, Sean Donelan) Re: Postscript FAX Security Hole (Andrew Klossner, Brooks Benson, Ross Oliver, Kevin S. McCurley, Ed Taft, Barry Margolin) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: [Whenever] From: cate3@netcom.com (Henry Cate) [culled by PGN] Subject: Catalogin' ``It's not clear whether Morris Feline Stuart is a Democat, a Fat Cat or a Republicat -- or even a fan of Ross Purr-O -- but Morris is now a registered voter in Cuyahoga County.'' Normalee Stuart of Shaker Heights, Ohio, says that she registered her cat to prove there are few, if any, safeguards against voter fraud in the county. She got the idea when a a neighbor had told her of receiving a voter registration card addressed to a woman who had been dead for 12 years. Ohio law does not require people -- or cats -- to identify themselves when registering to vote. In fact, state law doesn't require identification from people when voting and allows mail-in registration. [Excerpted from a UPI item in the (Cleveland) *Plain Dealer*, as noted (without date) by Henry Cat(e). Soon cats and dogs will be able to vote by E-mail. On the Internet, no one knows whether it's reigning cats or dogs. Normalee, anyway. PGN] ------------------------------ Date: Thu, 10 Nov 1994 18:38:35 -0700 (MST) From: vincd@ile.com (Vinc Duran) Subject: Worker cleared of deleted planning files Worker cleared of deleting planning files By James Burrus, Camera Staff Writer Boulder Daily Camera Thursday, November 10, 1994 A former Boulder County Planning Department employee was cleared Tuesday of charges that she deleted an unknown number of files from county computers. Charges against Vina Windes were dropped for "insufficient evidence" and because "information indicates no crime may have been committed," according to a motion filed Tuesday by the county's district attorney. Windes, 53, has worked as a secretary in the current planning division of the county Planning Department for five years. Graham Billingsley, Boulder County land use director, said charges were dropped after his department and Windes worked out a deal Monday in which "she would tell us what she did so we can put together the missing information. So far she hasn't done that so we don't know" what happened. But Windes said the files were never erased to begin with. "They just didn't know where anything was" in the computer system, Windes said. "All I did was leave. No one else did what I did, so they didn't know where to find anything on the computer when I was gone." Windes gave two weeks' notice of her resignation on Sept. 8 and started a new secretarial job Oct. 3. She was taken away from her new job in handcuffs Oct. 7 by Boulder County sheriff's officers and charged with computer crime, a felony, and abuse of public records. "The whole thing got blown out of proportion because of a lack of communication," Billingsley said. "Lack of communication?" Windes said. "There was no communication. All they had to do was call me and ask. Instead, they sent a sheriff's investigator to arrest me." Vinc Duran vincd@ile.com or vduran@nyx10.cs.du.edu ------------------------------ Date: Wed, 9 Nov 1994 18:30:35 -0800 From: forman@cs.washington.edu Subject: "Netsafe makes the Internet safe for K-12 schools" Imagine how often your network could go down with this new service: "Netsafe(tm) makes the Internet safe for K-12 schools. Netsafe keeps information away from minds that are not ready for it." Netsafe consists of a black box that monitors school traffic to the Internet and when an attempt to access a host with undesirable information is made (you select what categories to censor, they maintain the list of hosts), it shuts down all Internet access for 15 minutes and sends an email or beeper message to the local administration. Netsafe costs $20,000 the first year, $10,000 in successive years! They manage Netsafe over the Internet itself. Excerpts from product announcement by Russell Nelson, nelson@crynwr.com ------------------------------ Date: 14 Nov 94 15:37:33 EST From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Alberta vote-by-phone fiasco The Canadian newspaper, _The Globe and Mail_, reports today (94.11.14) on a disastrous attempt to tally votes by phone: Alberta phone voting crashes: Liberal fiasco casts doubt on future of high-tech balloting in Canada. By Scott Feschuk, Alberta Bureau. Calgary -- Alberta Liberal officials will be trying this morning to determine how the party's weekend leadership convention degenerated into what they concede was an outright debacle. Edmonton MLA [Member of the Legislative Assembly] Grant Mitchell, 43, was selected to head the opposition party, but his second-ballot victory was all but overlooked as the telephone voting system crashed, and many members were unable to vote or their votes were not recorded. The author continues with the following key points of interest to RISKS and NCSA FORUM readers: o Rural Albertans "found it all but impossible" to vote by phone during most of the first ballot. o The Maritime Telegraph and Telephone Co. claimed that "the system could handle more than 500 calls a minute" but the system crashed when a mere 11,000 people tried to vote in the 5.5 hours allotted. o The voting was stopped for 40 minutes in the middle of the process. o Distribution of the personal identification numbers (PIN) required to vote was incomplete, prompting complaints from disenfranchised voters. o Some users were informed by the computer system that their PIN had already been used to vote. o Some users reported that it took them over an hour to complete one vote. o Many users were informed that their vote had _not_ been counted even though later analysis suggested it had. o The sequence of touch-tone buttons required to vote on the second ballot was _different_ from the sequence used during the first ballot, resulting in confusion by an "unknown number of participants" whose votes were therefore lost. o Liberal Party officials are now "reluctant to pay Maritime tel's C$100,000 fee [~U$72,000]." o There were discrepancies in the numbers of people counted in the votes; at one point, the chief electoral officer reported "that more than 12,500 people had voted in the first ballot...." but he later reported just over 11,000 votes. However, "...[a]bout 19,000 people paid C$10 to participate." Calgary MLA Frank Bruseker commented, "You really have to wonder what happened to those other 8,000 people.... Did they not vote, or did their votes get lost, or did they try to vote and just get too frustrated?" o The problematic balloting has discredited the Liberals' claim to be an efficient alternative to the current government. o Bad feeling has worsened between the rivals for the leadership as a result of claims of unfairness due to the technological breakdown. o Maritime Tel's system will next "be used again this weekend in Saskatchewan, where provincial Conservatives will select a new leader." M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (HQ: Carlisle, PA) ------------------------------ Date: Fri, 11 Nov 1994 17:55:07 EST From: "Rob Slade, VARUG, SecSIG, BCVAXLUG, ComSIG and EdSIG" Subject: Rob Slade's review of Robert Slade's (no relation :-) book [Rob Slade is one of our most prolific reviewers. Here we give him a change to review Robert Slade's book. PGN] BKCVP.RVW Please note that the following is a completely fair and unbiased review. I strive at all times to be even-handed in my reviewing. My vested interest in this work in no way can be said to influence my judgement. I mean, to say that just because I spent *THREE SOLID YEARS* writing it means I might have a biased opinion about it is a prejudiced opinion on your part, isn't it? :-) %A Robert M. Slade %C 175 Fifth Avenue, New York, NY 10010 %D 1994 %G 0-387-94311-0 or 3-540-94311-0 in Europe %I Springer-Verlag %O U$29.95 800-SPRINGER, fax 201-348-4505 %O in Europe email ertel@springer.de, UK viv@svl.co.uk %O (and the title was *NOT MY IDEA!*) %P 480 %T "Robert Slade's Guide to Computer Viruses" This is the most FANTASTIC virus book EVER WRITTEN! This is the most FANTASTIC virus book that EVER WILL BE WRITTEN!! The day this book was released the ENTIRE VIRUS WRITING COMMUNITY committed suicide from depression over the fact that no one would EVER BE HURT BY A VIRUS AGAIN! Book stores are advised to have LARGE STOCKS of the book on hand, prominently displayed, and probably to hire extra staff for the crush of buyers. Grown men have been known to pull their own liver out when told that they could not buy the book! (And that was before it was PUBLISHED!) When we sent the books to reviewers, they typically danced in the streets for joy for several days. However, we reprint here some of the less effusive comments: "Mr. Slade's lists are more interesting than the NYC phone book." - Dr. Fred Cohen "Obviously some johnny-come-lately upstart." - Harold Joseph Highland "Is this guy some kind of comedian?" - William Murray "i think its cute and i like the title but i have a few questions ..." - sara gordon "Wonderful! It certainly cured *my* insomnia!" - Dorothy Denning "A mantlepiece!" - Terry Jones "I only have a hundred new samples that came in this week, and then I'll read it. Promise." - Fridrik Skulason "Should have had more sample code." - Ralph Burger "" - John McAfee (forwarded by Aryeh Goretsky) "Vrooooom, vrooooom!" - Padgett Peterson "Too long." - Ross Greenberg "Still doesn't reliably detect MtE." - Vesselin Bontchev "[A bruised read]" - PGN "Should be powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards -- and even then I have my doubts." - Eugene H. Spafford "Where's my baseball bat?" - Edwin Cleton "Is this legal?" - Paul Ferguson "I don't think this is funny." - Brad Templeton "We're the federal government. We don't *do* that." - James Earl Jones "Let me diagram that on a Turing machine for you ..." - Yaron Goland "A great virus book. No, I meant a great *anti*virus book. No, I meant a great *virus* book. No ..." - John Buchanan "Cool." - Ray Kaplan "My title was better than his." - Cliff Stoll "I elisted this book, and I have the password. Therefore I am now the author." - Gene Paris "We probably shouldn't be publicising stuff like this." - J. B. Condat Cecil B. DeMille, Alfred Hitchcock, John Ford, John Houston and Federico Fellini are working on a co-production of the movie version. Casting is not yet complete, but rumours indicate that Tom Hanks will play frisk, Arnold Schwartzenegger will portray Padgett Peterson, and Mark Ludwig will be Stoned. The part of Vesselin Bontchev will be played by a Cray YMP. DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: Thu, 10 Nov 1994 14:01:07 -0500 (CDT) From: "Michael P. Hartley, \"Dreading the Info SuperTrafficJam\"" Subject: Re: EMI and construction cranes (Summit, RISKS-16.55) While not directly related to computer RISKS, I feel a comment on how the FCC allocates frequencies is apropos here. Back in '91, the parts of the 72Mhz range that formerly were allocated in 40kHz wide ranges for R/C planes were re-allocated. Now, the R/C frequencies are 10Khz wide, 20Khz apart with various other devices allocated the frequencies between. These include pagers and some crane operations, among others. The old, pre-1991 transmitters are still legal to use until sometime around 1998. An older or poorly tuned R/C transmitter can cause short-ranged problems, like spurious pager signals or disruption of crane operations. R/C Tx are very low powered. Their effective range may be as far as 3 miles. The real RISKS are obvious to the public. In the R/C community, cranes are notorious for using very 'messy' and over-powered transmitters. A crane, pager tower, or other source of EMI could cause R/C fliers to lose control. A 10Kg object, hurtling through the air at over 200 KPH and spinning a razor- sharp 15" prop at 18000 RPM can cause a lot of damage or loss of life. Michael P. Hartley loadstone@ins.infonet.net ------------------------------ Date: Mon, 14 Nov 94 12:37:48 EST From: byrnes@escmail.orl.mmc.com (Arthur Byrnes (ATS)) Subject: Microwave oven RFI? (Summit, RISKS-16.55) "Broadcast towers ... and consumer microwave ovens ... are suspected, (of causing interference to the radio controls of a crane.)" Not knowing the Seattle area, but assuming that the "Nearby hill" is probably several thousand feet away, and maybe several miles away, the quoted person's (Donovan) comment shows a very poor understanding of the technology he is working with. It is outraegous that the blame can be placed on a microwave oven. Maybe, if the oven were inside the crane, there would be enough leakage to cause interference, but it is not likely even then. Even a broken oven that would work with the door open, and pointed toward the crane, wouldn't interfere with the crane if it was more than several hundred feet away. We know of course that the "Broadcast Towers" themselves wouldn't affect the crane, but the transmitters using those towers could. The interesting thing is that in most cases of isolated RFI (interference affecting only a particula person or machine), the "Cause" is not the source of the interfering signal, but the receiver being affected. Poorly designed receivers are a major cause of headaches to legally operating radio transmitters. Arthur J. Byrnes (Licensed Radio user Amateur, and Commercial.) ------------------------------ Date: Thu, 10 Nov 94 08:20:27 MET From: Peter Kaiser Subject: Re: Ottawa Library fines people ... Daniel Smith writes: > a) Each "ring signal" you hear is synchronized with the actual sounding of > the bell... No, it isn't. Our phone has a switch that turns the bell on and off. As we eventually discovered, a hard bump can switch off the bell; and in a household with children and animals, the phone is inevitably bumped hard enough. Furthermore, it's unplugged at times. It's obviously risky to assume that because one hears a ring signal, a phone is actually ringing. ___Pete kaiser@acm.org +33 92.95.62.97 ------------------------------ Date: Thu, 10 Nov 1994 2:56:08 -0600 (CST) From: Sean Donelan Subject: Re: Ottawa Libary fines people ... The goals of automated telephone notification are to reduce the postage costs and to notify people more quickly. For example, alerting you to overdue books faster so the fines don't get as large. DRA sells a few of different phone notification systems to libraries. Ottawa Public Library is one of our customers, but I don't know their exact setup. However, here is the basic (the specifics may vary depending on hardware platform) notification method. 1) Dial phone 2) Monitor call progress signals (if we're lucky the library has a telephone line that returns answer supervision) 3) When telephone line "answered" speak notification message twice, otherwise after a number of failed attempts send a mailed notice otherwise rescheduled call and exit 4) Wait up to 10 seconds for DTMF (touch-tone) key if DTMF digit "0" pressed go back to step 3 if other DTMF key pressed record it in notice response (e.g. "Press 1 to confirm") otherwise record no response (rotary dial, answering machine?) Its not a foolproof system. DTMF talk-off, wrong phone numbers, children answering the phone can cause the notice to be marked "SENT" (note: I don't use the word "received.") But it usually gets the job done under a variety of adverse conditions on low-bid hardware. (Hint, hint, pass that next tax increase for the library, and maybe they'll be able to afford a more sophisticated system.) >Well, I am. I know that it is only two bucks, but the implications that >arise from misuse or overly trusting such a system are worrisome. What if >the government started issuing parking tickets or summonses in this manner, >or banks warning you of surcharges on financial transactions? What if my >wife answered the phone and the book was "how to handle infidelity in you >marriage" :) (it wasn't). Some libraries use postcards to notify people when a copy of "How to handle infidelity in your marriage" is available. Parking tickets are presumed valid even if someone rips it off your windshield before you see it. There are all sorts of risks in all sorts of notification systems. Nevertheless we accept many risks as normal. Libraries rarely send notices via certified return receipt requested mail. The problem of "lost" notifications is something libraries have dealt with for a long time. The dog ate it. The post office lost it. The kids hid the overdue notice before the parent gets home. Different libraries have different policies for handling reports of not receiving a notice. Generally proof of receipt is not a requirement. What should be considered a reasonable attempt at notification? Sean Donelan, Data Research Associates, Inc, St. Louis, MO Domain: sean@dra.com, Voice: (Work) +1 314-432-1100 ------------------------------ Date: Mon, 14 Nov 94 07:08:27 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Postscript FAX Security Hole (Crawford, RISKS-16.55) A quick description of security for PostScript FAX (as implemented in various laser printers) follows: If the ReceivePostScript FAX parameter is false, the printer will reject any attempt to inject PostScript through the modem. In this case, it will accept only the FAX format. If the PostScriptPassword FAX parameter is not the empty string, then the transmitting printer must supply a password. Receiver challenge and encryption are used. The default values of these parameters are true and the empty string, respectively, so a factory-new printer will accept PostScript without requiring a password. In this case, any attempt to change system or device parameters (such as passwords) from within an incoming FAX job will fail unless the (separate) system password is supplied. Also, attempts to generate outbound FAXes will fail. If no system password has been set (as in a factory new printer), then such attempts fail. I can't find anything in the documentation which gives disk files better protection from a FAX job than from a local job. The reference for all this is "PostScript Language Reference Manual Supplement for Version 2014" by Adobe Systems Incorporated. This is available, as a PostScript file (naturally), from ftp.adobe.com as "pub/adobe/DeveloperSupport/TechNotes/PS.Supp.2014.ps". "2014" here refers to the major revision number of the PostScript interpreter, as reported by the printer on the page that it prints at power-up. Similar files are available for versions 2011, 2012, and 2013. -=- Andrew Klossner (andrew@frip.wv.tek.com) ------------------------------ Date: Thu, 10 Nov 94 08:58:48 -0600 From: brooks_benson@il.us.swissbank.com (Brooks Benson) Subject: Re: Postscript FAX Security Hole A similar situation may exist with NEXTSTEP's Mail application. NEXTSTEP uses Display PostScript as it's imaging model. When one selects for display a piece of email that contains an encapsulated PostScript file attachment, the PostScript is sent to the window server and executed. This feature has led several clever hackers to create NeXTmail PostScript "viri". I have seen several of these, all pranks, none malicious. One causes a number of spiders to scurry across the desktop, which must be squashed with a mouse click before allowing you to regain control of your desktop. Another causes all the window objects to drop off the bottom of the desktop one at a time, yet another shakes the entire desktop, giving the impression of an earthquake. Although I have personally not seen any destructive email viri, I can't say that none exist. I'll ask roughly the same question as the original poster. Was the possibility of malicious use of the PostScript language considered when determining standards for intelligent PostScript devices?? Brooks Benson Swiss Bank Corporation International Finance Division brooks_benson@il.us.swissbank.com ------------------------------ Date: Thu, 10 Nov 1994 14:30:51 -0800 From: Ross Oliver Subject: Re: Postscript FAX Security Hole In RISKS-16.55, Mike Crawford write about the risks of remote configuration of intelligent devices such as his Postscript printer. One possible solution to this risk is to require a switch to be thrown, button pushed, jumper changed, or some other physical manipulation of the actual device before any critical configuration information can be changed. A physical "lock-out" would provide security when needed, yet still allow the benefits of remote configuration if desired. The company I work for manufactures X terminals, and we have incorporated this type of feature into our terminals. When a special type of keyboard, called a "secure keyboard" is attached to the terminal, the critical portion of the terminal's configuration data (stored in non-volatile memory) can be locked against further changes. The secure keyboard is then removed and replaced with a standard keyboard. Ross Oliver ross@ncd.com ------------------------------ Date: Thu, 10 Nov 94 21:14:57 MST From: mccurley@cs.sandia.gov (Kevin S. McCurley) Subject: Re: Postscript FAX Security Hole In RISKS-16.55, Mike Crawford pointed out that accepting postscript to a fax machine is really accepting a program to be executed. Postscript is a programming language with operators for renamefile, deletefile, createfile, and some others that are risky in some situations. Moreover, operators can be created from other operators, so it is not even sufficient to scan the postscript stream for the offending sequences before executing them because they can be built from other strings at runtime. Many web viewers such as netscape and mosaic can be configured to invoke external viewers such as ghostscript that are in reality postscript language interpreters. It is therefore possible for someone to click on a URL inside a web viewer, and in so doing have changes made to their local file system that are not apparent to the user, because it caused a postscript file to be brought back and executed. The default mode (safer) for the recent version of ghostscript does not execute these operators, but the risk still exists for other configurations. Postscript is probably also not the worst offender for this - what if your local web viewer on a UNIX machine processes Bourne shell scripts locally by feeding them to /bin/sh, or your DOS viewer executes .bat files by feeding them to command.com? Click here to reformat your disk ... It is clearly possible to write internet software that is dangerous to operate, but the risk can easily be eliminated through proper configuration and coding. Many of us drive automobiles to work every day, recognizing that they possess the capability to inflict serious injury and death if used improperly or if they experience a catastrophic failure. Will the government someday legislate seatbelts for web viewers and fax machines because of the risks to uninformed or careless users? Kevin McCurley Sandia National Laboratories ------------------------------ Date: Fri, 11 Nov 94 10:25:10 PST From: taft@mv.us.adobe.com (Ed Taft) Subject: Re: Postscript FAX Security Hole > Would anyone know whether this has been considered under the postscript FAX > standard? It seems to me it would be a problem for just regular PS faxes - > one would just hack it over the phone line from another PS fax machine. Indeed, this issue was considered at length in the design of PostScript fax. There are several passwords that control access to both PostScript fax specifically and to system administrator functions generally (such as erasing the disk). The defaults are set up to be relatively permissive. This decision is based on the reality that many PostScript fax printers will be installed and operated by unsophisticated users having no system administrator support and who expect the product to work right out of the box. However, the defaults are such that system administrator functions can't be executed by a fax job. This, of course, solves only part of the problem. There is no protection against a fax job that executes something like: 1000000 {showpage} repeat More comprehensive facilities for authentication, access control, resource accounting, etc., await implementation in future versions of PostScript fax products. Ed Taft taft@adobe.com ------------------------------ Date: Fri, 11 Nov 94 17:34:38 EST From: barmar@near.net Subject: Re: Postscript FAX Security Hole Don't you run the same risk when you print any PS file that you download from the net or receive as email and then send to your printer? Do you examine every PS file for security holes before you print it? PS FAX just gets rid of the middleman. As for changing the printer password, wouldn't they have to know the old password in order to get into the mode that allows it to be changed? [...] What's needed is probably a general concept of trust levels associated with PS document sources. Dangerous commands would only be permitted for documents that came from a trusted source. When printing PS files, the user could indicate the trust level (high trust if they generated the file themselves from an application, low trust if they got it from the net). For automated processing like PS FAX, it could simply default to low trust, or perhaps permit passwords to be included (either in the PS code, or perhaps in the FAX wrapper). In effect, a PS FAX machine needs to be like a computer with a dialin modem: you need to be able to define accounts and give them access privileges. Barry Margolin BBN Internet Services Corp. barmar@near.net ------------------------------ Date: 20 October 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from 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. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not automated). 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. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.56 ************************