Subject: RISKS DIGEST 16.60 REPLY-TO: risks@csl.sri.com Errors-To: risks-request@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 5 December 1994 Volume 16 : Issue 60 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 ***** ***** WARNING: SRI RISKS ARCHIVE SOURCE IS MOVING SOON TO A NEW SITE. ***** Contents: Excel linked spreadsheet bug (Michael D. Crawford) Random Testing of Floating Point: Doesn't Everyone? (Robert Ayers) 3 hits and you're out? (SSN use) (Geoffrey S Knauth) The Economist and E-cash (Mark Stalzer) RISKS of Going to the Movies (Keith Schengili-Roberts) Providing Good Defaults (and risks of not doing so) (Ry Jones) The PC as a RISC (Michael Slavitch) HERF Rides Eye To Eye (Winn Schwartau) Interesting product claim (Mike Kenney) Criminals 1, Consumers 0 (Peter J. Denning) Re: Duplicate bridge-tournament hands (Asya Kamsky) Re: Listserv Loops (Steve Summit, Peter da Silva, Joe A. Dellinger) "Tekroids" episode of Tekwar and the perception of viri (Rob Slade) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sun, 4 Dec 1994 02:58:46 -0800 From: crawford@scruznet.com (Michael D. Crawford) Subject: Excel linked spreadsheet bug There is a bug in Microsoft Excel for the Macintosh in which results from linked spreadsheets are incorrectly recalculated. A friend of mine who owns a business overdrew his company checking account by $4,000 as a result. Interestingly, he had a "fail-safe" system, in which his accountant recommended which bills to pay based on the total account balances. The accountant recommend he pay a bill for about $2,000, then inadvertently credited this to the balance sheet rather than debiting it. My friend checked the accountants work using a linked spreadsheet. The calculation showed that he had $4,000 more then was really available. The unlikely coincidence of making a manual mistake that matched a software error convinced my friend that it was safe to write the check. My friend can easily duplicate the bug. Apparently the bug is being discussed on Compuserve these days, with the word being that it only happens on really complicated spreadsheets. My friends spreadsheets, though, are quite simple - one spreadsheet to tally the checking balance, one to tally the credit card account balance, and a third to total the two accounts. Michael D. Crawford crawford@scruznet.com crawford@maxwell.ucsc.edu ------------------------------ Date: Sat, 3 Dec 94 13:41:33 PST From: ayers@mv.us.adobe.com (Robert Ayers) Subject: Random Testing of Floating Point: Doesn't Everyone? In RISKS-16.59 Wilson P. Snyder notes "at Digital, our Alpha AXP processors are tested using psudo-random techniques ... Random testing often finds interesting problems that would never be found by just writing specific tests." Hasn't everybody done this forever? Back in the '60s (yes that's "sixties") I watched IBM upgrade a 7090 to a 7094. The third *day* of the post-upgrade verification was a test of the new floating point arithmetic (a 7094 upgrade added double precision) using randomly generated data and a fixed-point simulation of the FP for comparison. I asked the IBM CE whether that twenty-four hours of floating-point testing was really necessary. He replied "Yup. I've seen the test run OK for sixteen hours and then find a failure." Bob [By the way, I have suppressed a huge influx of Intel `humor' that has been submitted to RISKS. I have seen so many copies of so many different items on so many redistributions that it seems unnecessary to include them here, or to note that I have seen at least 63.999975 distinct jokes thus far. PGN] ------------------------------ Date: Mon, 5 Dec 1994 16:29:30 GMT From: gsk@world.std.com (Geoffrey S Knauth) Subject: 3 hits and you're out? (SSN use) Last week, a friend was writing software to make credit checks as part of a large project involving government loans to individuals. He returned home and told his wife we'd been using my social security number to test the interface, with my permission. His wife works at a bank, and she told him he'd better not do three checks on me, or I wouldn't get any more credit. I was surprised to hear that a credit check carries with it this sort of penalty. Can anyone from the credit industry confirm this? My friend was recently given a "test" SSN to use, so I shouldn't have to worry more. Geoffrey S. Knauth http://www.marble.com/people/gsk.html Marble Associates, Inc., (617) 487-0050 CRASH-B Sprints, Cambridge Boat Club ------------------------------ Date: Tue, 29 Nov 1994 12:27:36 +0800 From: stalzer@macaw.hrl.hac.com (Mark Stalzer) Subject: The Economist and E-cash The 26 Nov 1994 issue of The Economist has a story on electronic money (p.21--23). It covers some of the current attempts to create "virtual banks" on the internet so that consumers can buy from electronic stores without sending credit card numbers in the clear. This is fairly mundane stuff to risks readers, but the story moves on to the evolution of digital cash. Some of the possibilities are interesting, such as private issuers of E-cash (that will probably be more stable than most governments!) to a world-wide currency (no exchanges rates and middle-people). Recommended reading if you're curious about some of the broader issues of electronic money. Mark Stalzer, mas@acm.org [E-cashibus unum. PGN] ------------------------------ Date: Sun, 4 Dec 94 22:53 WET From: kschengi@interlog.com (Keith Schengili-Roberts) Subject: RISKS of Going to the Movies Recently, my wife and I decided to go to see a movie at one of the cinemas in downtown Toronto. It was a rainy day, and there was a long line-up to see the film. I noticed that just inside the foyer of the theatre were a couple of automatic ticket dispensing machines. Nobody was at the machines, save for a couple of kids who were playing with them. I had used the automatic ticket vending machines before, and they operate in a similar fashion to automatic teller machines. Instead of cash, you get film tickets. You can also buy things like popcorn and cola in the form of tickets that you take to the concession stand. It was my wife's treat, so she shooed away one of the boys who was playing with one of the machines, and proceeded to swipe her credit card in the card-reader. Tickets began to pour from the machine. General Admission, Senior's and Children's tickets along with coupons for purchasing a small mountain of popcorn and a river of cola issued from the machine, like a one-armed ticket-dispensing bandit gone mad. In the end my wife was charged for approximately $375.00 of goods. The kids who had been playing with the machine before were nowhere to be seen, and the movie was about to begin. What had happened was this: the kids who had been playing with this machine had made just about every conceivable selection on its touch-screen before my wife got to it. Part of the reason why it must have been fun for them to play with is because you do not have to prove your purchasing power with a credit/bank card beforehand. You can make as many on-screen selections as you like, and it will merrily rack up the total charges. While there is a screen that asks if you want to purchase all of the items you have selected, to someone inexperienced with these types of machines, it appeared to be a "start" screen. A further risk was revealed when my wife used her Credit Card with the machine. It has it's PIN number built-in, (convenient by highly RISK-y) so the moment she swiped the card past the reader, it confirmed the order immediately. In the end the staff at the theatre were very helpful, and at the end of the movie my wife handed over her receipt from the machine, and expected to have the charges on her credit card reversed. Instead she was paid back in cash directly from the box- office takings by the theatre manager. When I asked why, it turned out that there was no procedure between the bank that installed the automatic ticket dispensing machines and the theatre-chain to deal with this type of situation. The manager said that they'd definitely "have to look into it". Luckily a bank was nearby and payment to my wife's account was made before any interest charges could accumulate. When we went back to the same theatre again recently for another movie, I noticed a couple of changes. A ticket-agent stood guard to make sure that nobody played around with the machines who didn't intend to purchase anything, and there was a large sheet of instructions placed beside each machine. I paid for the tickets this time, and used a bank card that does not have a built-in PIN number. Everything went smoothly this time: we got the tickets we requested, and managed to zip past the rest of line and got good seats in the theatre. The movie was good too! Keith Schengili-Roberts, Writer/Reviewer, The Computer Paper - Toronto Office Canada's largest computer magazine, free, on-line at: http//www.wimsey.com/tcp ------------------------------ Date: Sat, 26 Nov 1994 22:58:27 -0800 (PST) From: rjones%rjones@rjones.oz.net (Ry Jones) Subject: Providing Good Defaults (and risks of not doing so) One of the frequently referenced style guides for programming (the Indian Hill guide, I think) talks about the value of good defaults. The current Slackware Linux distribution does not do so in one important area, and I was able to 'explore' a system due to this flaw in the installation: Slackware does not force a root password on install. The system in question was hooked up to the internet for casual use by someone I have known for a long time. Apparently, the two way nature of a PPP link didn't cross the minds of the three people involved in getting the system on the net, and they never set any passwords. I was able to get in as root and make clear to the machine's owner that he had no security. I called him afterwords and we set things up much tighter, but it's disturbing to me that neither the OS install nor the network software install forces you to set any password. To be sure, this is freeware, and is to be used by an experienced user community, but it was all to easy for them to escape onto the net without any warnings. I have noticed many linux systems on the net that still have the default users (gonzo et al) still installed. Good defaults, I think, would solve this. ------------------------------ Date: Mon, 28 Nov 94 09:44:03 -0500 From: "Michael Slavitch, Consultant, (613) 781-9824" Subject: The PC as a RISC (how could I resist 8)* A. Padgett Peterson writes: > This is just what the world needs: self-extracting and executing E-Mail. This was the case with several commercial (non-smtp) mail packages such as Novell's MHS. Several years ago I was developing software for the Novell platform (I still do when people throw money at me to do it :). I was having problems with one of my programs. I uuencoded the file and sent it to a buddy@novell.com, along with source, and for some reason :) the early-version MHS mail system immediately began to self extract the file. Unfortunately, I had given the UUENCODED .NLM (Netware Server Executable) file a hard path (thinking that the smart engineer would see it and know where I had installed it, and yet being smart enough not to put it in a critical system). Unfortunately, it had been expanded on a system by a dumb computer :) where the NW developer also had *root* like privs, so the file would expand and be placed anywhere in the netware file server system. Luckily the program never loaded (although if it had been given a name of a program that was loaded periodically life as we had known it would have ceased to exist) and I found out about it through a *confirmation message* sent to me by the mailer. Now think about this and remember the internet worm (this was *years* later). I told my buddy about this by email and within a couple of weeks there was a patch update to MHS. I got a lot of phone calls from Novell developers trying to figure out what I had done. Basically, I could send a new password files to *supervisor* (NW's *root*) and then after that set file privilages by email to my hearts content. Scary. Let me just say that MHS doesn't do that anymore. And yes, I've tried to break it (with permission) without success since. But I'm a medium-smart hacker. Some real devils out there could probably figure out a way to mess greatly with such systems, especially now that MIME and WWW are becoming more commonplace (what about Web-bombs using creaky web forms? It has been done by a relatively good hacker buddy of mine in a couple of minutes). I am distrustful of the security of any system that allows a person to place a file without explicit authorization, as well as authentication (web forms, FTP, and self-extracting mail). Digital sigs will keep unauthorized people from doing dangerous things, but it won't keep authorized people from doing things that cause stupid computers to do stupid things. Michael ------------------------------ Date: Thu, 01 Dec 94 22:55:19 -0500 From: "Winn Schwartau" Subject: HERF Rides Eye To Eye Connie Chung's "Eye to Eye" (ABC, 12/1/94) provided an excellent primer on accidental electronic interference. (My book is a pretty good source, too. Can't resist the 'plug.') They brought into living room TV color clarity more hard examples of EMI: * Children's life support systems failing by cell-phone induced EMI. * Defibrillators malfunctioning. * Wheelchairs spinning in circles from portable radio interference. * Airplane (727) avionics and guidance systems (both primary and secondary) going haywire from passenger radio. The focus was on _accidental_ EMI events, which were low power events at that. Radio emissions and cell phones and such are not power intensive devices (a few hundred milliwatts) but still can cause dramatic systemic failures. Obviously (for those who know my work) when intentional EMI is "turned up" to higher power levels, the interference is increased as well. Thus, as I discussed in "Information Warfare," when a bad guy has the capability to generate electromagnetic fields of a greater strength, control the frequency and focus or aim them upon targets, we can similarly expect to see man-made EMI events of greater intensity in greater numbers. Bringing down financial econo-technical infrastructures (among other targets) through electromagnetic denial of service attacks is on its way, if it's not here already. I am currently investigating a number of fascinating `incidents.' (Please let me know if you think you might have been `hit' by either HERF Gun or EMP/T Bomb assaults.) A while back [RISKS-16.26] I also posted in RISKS how airplane avionics interference is caused by on board digital devices and how such vulnerabilities could be exploited by suicidal maniacs or those of the terrorist flavor. I also recall a number of readers "doubting nay-sayers" pooh-poohing such hogwash. Take a watch of Connie. HERF is again being vindicated. Winn Schwartau, Executive Director, Interpact, Inc. ------------------------------ Date: Thu, 1 Dec 1994 10:11:42 -0800 (PST) From: Mike Kenney Subject: Interesting product claim I ran across the following product description in the Shareware Express catalog that my wife receives: ``COMPUTERIZE YOUR EMPLOYEE TIMECLOCK. Save time and money. Convert your PC into an employee timeclock and bring timekeeping and payroll tasks into the 20th century! TIMECLOCK logs your employees "in" and "out" and calculates their hours automatically at the end of each pay period. Unlike manual systems, it never makes a mistake ... '' ^^^^^^^^^^^^^^^^^^^^^^^^ Talk about your bold statements. But what if you run it on a Pentium? :-) While I'm on the subject of the Pentium I would just like to toss in my $0.02. I don't have a problem with the fact that the chip had a bug ... it's certainly not the first and it sure won't be the last. I *do* have a problem with the way Intel has handled the situation and I'm speaking as someone who manages 3 Pentium systems. Since I'm at a university research lab, I had no problem getting replacements but others are not so lucky. As CPUs get more and more complex, the chance of bugs slipping through will probably go up. I just hope whichever company it happens to next handles the problem better than Intel. Mike Kenney, UW Applied Physics Lab mikek@apl.washington.edu ------------------------------ Date: Thu, 1 Dec 94 09:23:59 EST From: pjd@cne.gmu.edu (Peter J. Denning) Subject: Criminals 1, Consumers 0 Cellular One of the Baltimore-Washington area just distributed a notice to all customers that they have cut off roaming in the New York City area. They say that fraud has become too serious a problem. It is now not possible to have your calls forwarded to you in NYC. If you wish to make an outcoming call in NYC, an operator will take a credit card number and immediately bill that at rates considerably higher than the normal roaming rates (which are in turn considerably higher than the regular cellular rates). The fraud is that thieves have been stealing electronic id numbers by scanning the cellular frequencies and picking them out; they then program those numbers in new (cheap) phones and sell them on the streets. By the time one finds out that someone else has cloned one's phone, hundreds or thousands of dollars of calls will have been logged. [This problem is of course very widespread. It's more like CRIMINALS $1B, CELLULAR ZERO. Some countermeasures are of course possible, but are impeded by lack of standards, lack of exportability, lack of incentives by vendors, lack of customer interest in paying more, etc. PGN] ------------------------------ Date: Wed, 30 Nov 94 14:41:09 PST From: kamsky@sales.tgv.com (Asya Kamsky) Subject: Re: Duplicate bridge-tournament hands (RISKS-16.58) That is not what happened at all. The bridge hands are dealt out by this machine, and it is set to deal out the same sets of hands until someone resets it, or puts in a new set of hands. The machine wasn't used between the two tournaments, so it dealt out the last set of hands that was fed into it. Usually when hands are duplicated like this, it's the same set of hands being used by humans, not the same set being generated by a machine. As usual -- pilot error. Asya ------------------------------ Date: Thu, 1 Dec 1994 12:37:39 -0800 From: scs@eskimo.com (Steve Summit) Subject: Re: Listserv Loops (Klau, RISKS 16.59) Mailer loops have probably been around since the dawn of e-mail. They're often astonishing, but they shouldn't be: any time mail can be generated by an automaton (e.g. error messages, "vacation" programs), or a single message can spawn multiple messages (e.g. "mail exploders" such as listserv), you have a system with gain. Undamped positive feedback can yield spectacular results, but again, this shouldn't be too surprising. Anyone writing mail software, even of a rudimentary nature, which has even a hint of a possibility of inducing any gain, needs to be acutely aware of these problems, and to take every step possible to reduce the opportunities for positive feedback and to detect and damp it when (not if) it occurs. Without taking such precautions, disastrous mail loops are a certainty; with them, they are merely likely. (In other words, even mail systems which were supposedly designed to prevent loops are fairly regularly surprised when real-world installations discover new ways to connect some pieces together into feedback loops which manage to bypass any safeguards.) I believe there was an article discussing this sort of thing in CACM in 1989 or 1990; unfortunately, I no longer have the reference. Steve Summit scs@eskimo.com ------------------------------ Date: Thu, 1 Dec 1994 13:51:49 -0600 From: peter@nmti.com (Peter da Silva) Subject: Mailing list problems... OK. There's a number of things a list can do to prevent this sort of problem. You are probably doing at least some of these: 1. Stamp outgoing list mail as being "junk". I believe that this is in the "precedence" header. Many systems toss "junk" mail when it's refused. 2. Set outgoing mail to have an "Errors-To:" address. 3. Drop incoming mail that is marked as being "junk". If you were doing all of these things, then the fault is due to the bouncing software. It should really support all three (mark its mail as junk, drop junk mail instead of bouncing it, and respond to an errors-to address), but for it to support NONE of the three is serious brokenness. > So -- has this happened before? Lots of times. A lot of people keep a human in the loop to prevent this sort of error cascade. The only other thing you can do is to be totally anal retentive about how you treat headers. The three items I listed above are just a start. [There were numerous similar responses on this topic, including from catfood@rosebud.strinc.com (Mark W. Schumann), who added that ``A subscriber site that does not honor the "Errors-to:" header is broken and should be turned in to the RFC822 Police.'' {WOULD THAT THERE WERE SUCH!} zerkle@cs.ucdavis.edu (Dan Zerkle), flatau@cli.com (Arthur D. Flatau), John Gardiner Myers , stead@seismo.CSS.GOV (Richard Stead), Peter M. Weiss , crawford@scruznet.com (Michael D. Crawford), thompson@se01.wg2.waii.com (James Thompson). Thanks to all of you. Would that all mail servers were compliant! The bad ones are driving me nuts. PGN] ------------------------------ Date: Fri, 2 Dec 94 18:50:57 CST From: jdellinger@amoco.com (Joe A. Dellinger) Subject: Re: Listserv Loops The "vacation" command will cause the same problem, albeit it only sends one "I'm not here" notice to the entire list before ceasing auto-responding. As far as I know, there is no automatic way for the list processor to detect such auto-replies, and they will occur whenever anyone remains subscribed to a list while on "vacation". In 1989, in the Geophysics department at Stanford, a similar incident involving the Bay Area Chinese Student's mailing list caused all our departmental computers to crash. In that case someone had simply forwarded _all_ their mail to the list processor shortly before going on vacation. The reply addresses kept getting longer with each round-trip iteration, until they overflowed the fixed-length field in the Berkeley mail programs allocated for that string, causing the mail daemon to keep running doing nothing forever. After an hour or so there would be dozens of superuser-priority mail daemons all attempting to run simultaneously and the machine would crash. (Our machines crashed first because in our department we had the highest density of subscribers to that list.) The moral of the story: anything which replicates itself has the built-in potential of becoming a cancer / virus. Note the designers of "mail" recognized the problem and designed in prevention against infinite mail loops, by the brute force expedient of killing messages more than a certain number of hops old. ------------------------------ Date: Sat, 03 Dec 1994 19:23:53 EST From: "Rob Slade, Social Convener to the Net" Subject: "Tekroids" episode of Tekwar and the perception of viri TVTEKWAR.RVW 941201 Bill Shatner has been reading "Snow Crash" (cf BKSNCRSH.RVW)! In tonight's episode of Tekwar, we find that police detectives, and the hero's ex-wife, have been felled by a nasty virus. A *computer* virus. Call the Weekly World News. Shatner is *much* more ambitious than Stephenson. The "Snow Crash" virus, in graphical representation, looked pretty much as you'd expect--snow! The Tekwar virus looks like a young lady. (When she starts to open her blouse, you get just a hint of circuitry and bright light. Hubba, hubba!) Oh, come now, Rob. Don't be a spoil sport. They can make programs that look like text, can't they? So why can't they make programs that look like pictures? Well, it is true that I have copies of the BOO programs, which are utilities for converting binary files into a format that was only printable characters. I understand that there is an MS-DOS program, called COMt, which turns COM files into *executable* forms, using only printable characters. (Padgett Peterson was so taken with the idea that he wrote his Christmas card program using only printable characters.) The "text" programs, however, don't exactly look like a letter from Mom--they look like strings of garbage. Paradoxically, graphics images (realistic graphics, that is) give you even *less* leeway, since the human eye is *very* good at picking up anomalies. The Tekwar virus is recovered from an imperfectly erased copy of the graphic. Under extrapolative recreation, the virus is virulent enough that just looking at it will fry your computer. (Try *that* with your average copy of Stoned. "Lossy" compression wins again!) (By the way, in *that* picture, the young lady has her shirt *on*.) If you look at the virus, it renders you unconscious. Fair enough: flashing lights can stimulate epileptic seizures. However, thereafter the virus slowly causes *physical* degradation of your nervous system. Oh, please. What's the nerve equivalent of JMP? Stay tuned *next* week, when Bill Shatner uses the I-word. (Pay close attention when he announces the virus is loose.) copyright Robert M. Slade, 1994 TVTEKWAR.RVW 941201 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: 5 December 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 yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] 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. THE RISKS ARCHIVES ARE MOVING, POSSIBLY LATER THIS WEEK: ftp unix.sri.com cd risks (BEWARE: THE NEW SYSTEM IS CASE SENSITIVE) CURRENT 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.60 ************************