Subject: RISKS DIGEST 18.02 RISKS-LIST: Risks-Forum Digest Tuesday 9 April 1996 Volume 18 : Issue 02 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: The weakest link: Social (In)security Administration (Sean Reifschneider) ``Jail Gives Hackers a Lesson in Reality'' (PGN) Australian Insurance Company and Database (Andrew Waugh) De facto Daylight Savings (Matt Welsh) Re: Teen Accused of Hacking (William Ehrich) Microsoft Exchange helpfully misdirects e-mail (John Hoffmann) Re: Notes on e-mail: Use diaeresis (Tim Pierce, Otto Stolz) CompuServe's "secure login protocol": two steps forward, one back (Heinz-Bernd Eggenstein) IBMMAIL e-mail address woes (Erik Naggum) Re: X-Confirm-Reading-To: Pegasus woes on mailing lists... (Peter Yamamoto) The risks of .forward (Christophe Beauregard) Re: Wrong approach to Java security (Andrew Berman) Re: Risks of rewritable BIOSes (Jeremy J Epstein, Nicholas C. Weaver) Re: Computers, Freedom and Privacy '96 (Shabbir J. Safdar) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 7 Apr 1996 22:12:30 -0500 (CDT) From: Sean Reifschneider Subject: The weakest link: Social (In)security Administration The URL "http://www.nando.net/newsroom/ntn/info/040696/info5_14984.html" reports "one of the biggest breaches of security of personal data held by the federal government". Apparently several employees of the Social Security Administration sold information including SSNs and mother's maiden names of more than 11,000 people to a credit-card fraud ring. The fraud ring was able to use this information to activate cards which were stolen from the mail. Citibank had implemented a scheme which required customers to "activate" their credit cards when they receive them by calling a phone number and providing personal information like their mothers maiden name. It seems that while systems are being designed to protect our property, it's just causing the crime to move closer to the person. If someone steals your credit card from the mail or your car from the parking lot, you're probably at a safe distance. Instead, they are forced to carjack your car at a stoplight because of your alarm system, or find out personal information about you. Similarly, I heard about home breakins on alarmed houses in which the burglar would regularly trigger the alarm and be careful to leave no traces. Once the police stopped coming (because the alarm was faulty), they were free to break in and swipe whatever they like. No matter how secure the system, the weakest link can be the clerk who's paid $12K/year to work on the system. It doesn't take much money to convince this person to hand out our personal information. This sort of thing kind of makes the hassle I went through in keeping my SSN from my insurance company. If you've never tried it, for me it was a huge hassle... Apparently, all of my claims needed to be handled by hand by one of the supervisors. Of course, if everyone did it, their $4/hour clerks could take care of it. Sean Reifschneider, Inimitably Superfluous URL: HP-UX/Linux/FreeBSD X11 scanning software. [Also noted by Monty Solomon quoting from Edupage, and WOODWARD@BINAH.CC.BRANDEIS.EDU (Beverly Woodward), who cited the article in "U.S. Workers Stole Data on 11,000, Agency Says" in *The New York Times*, 06 Apr 1996, p. 6, from which most other reports seem to have been drawn. PGN] ------------------------------ Date: Mon, 8 Apr 96 18:45:15 PDT From: "Peter G. Neumann" Subject: ``Jail Gives Hackers a Lesson in Reality'' Terry Ewing (now 21, with 21 months in federal custody ahead of him) downloaded 1,700 credit-card numbers off of a Tower Records computer system, just before leaving for DefCon, the West Coast "hackers' convention". His friend Michael Kim (now 20) is facing an 18-month sentence. Apparently, Tower folks knew their systems had been under attack previously, and were monitoring misuse. Police encouraged Tower to wait for the next attack -- in which the intruders used the Tower computer to sort the captured credit-card numbers by expiration date and create a file of those with a date at least a year away -- while being observed. Agents tracked the intrusion to their apartment, which was searched, revealing the purloined information. The two young men were convicted of a felony, although they had not profited from the credit-card numbers. [Source: *San Francisco Chronicle*, 8 Apr 1996, p.A2.] The article concludes with a quote from Mike Godwin of EFF about those who ``have this myth that they are cool guys, and [that] the cool guys always win over the suits. But the fact is that they are half-socialized, post-adolescents with serious ethical and moral-boundary problems.'' [Stores should not store credit-card numbers, but I guess we can no longer number the stores that do not behave sensibly. I just asked a mail-order outfit if they would keep a card number around for a long-deferred delivery; the answer was, ``yes, but we keep in a place where no one can access it.'' I am sure that gives you RISKS readers a lot of comfort. PGN] ------------------------------ Date: Sat, 06 Apr 1996 15:07:33 +1000 From: Andrew Waugh Subject: Australian Insurance Company and Database The 6-7 Apr 1996 edition of 'The Weekend Australian' carries a report (p 5) on a court case involving the large Australian insurance company AMP and an attempt to build a large database of all Australian households. It was alleged that the "massive database... was supposed to identify every household in Australia, give each household a unique identifier number, detail the dwelling type of each household - whether it was two-story, weatherboard [timber] or brick - and also detail the fire, storm and flood risk rating of each home." The contractor developing the database, Indata, expected this database to give AMP a significant commercial advantage. This database was alleged in court to to have been based on a magnetic tape of the Australian electoral roll. Under the Australian Electoral Act, magnetic tapes of the electoral roll cannot be obtained for commercial purposes. The former manager of Indata said that he had assumed AMP had investigated the legalities of purchasing the tape and that Indata and AMP were acting within the law. The tape had already been purchased before the manager joined Indata. The court case is a committal hearing against a former AMP client manager who is charged with 12 counts of attempting to defraud AMP. The fraud involves payments to Indata totalling $324,809 (Aus). AMP is expected to claim that was not aware of the illegal purchase of the electoral roll and that their client manager had inappropriately authorised payment to Indata. AMP has demanded return of the money. The committal hearing will continue next month. andrew waugh ------------------------------ Date: Sun, 7 Apr 1996 13:31:38 -0400 From: Matt Welsh Subject: De facto Daylight Savings At http://www.timing.se/Daylight.html there is a brief discussion of the rules for Daylight Savings Time changeovers for central Europe and the UK. At the end of the page it says: > NOTE: From autumn 1996 the rule of changing from standard time to > daylight time is changed. The new rule is valid for central Europe > including the UK is: > > Standard time to Daylight Saving LAST SUNDAY OF MARCH > Daylight Saving to Standard time LAST SUNDAY OF OCTOBER > > The rule is a "de facto standard," not a law. > > The switching occurs at 01:00 UTC for central Europe (Stockholm Paris etc.) > Local time that is at 02:00 STD to DST and 03:00 DST to STD. > (STD = Standard time, DST = Daylight Saving Time or Summer Time.) > > Note: The legal switching is steered by laws that state dates for a couple > of years. When a period ends a new law is issued that gives the dates for > the next years. > > The Laws do not state any general rule. Only dates for a couple years > each time. The "de facto rule" works, but there is no warranty it will > work forever! With all of our scrambling about to deal with the Year 2000 problem, shouldn't we be just as concerned with this inconsistency that arises yearly (especially if there are no 'hard and fast' laws/standards to dictate DST changeovers)? M. Welsh, mdw@cs.cornell.edu ------------------------------ Date: Sat, 6 Apr 1996 11:32:31 -0600 From: ehrich@minn.net (William Ehrich) Subject: Re: Teen Accused of Hacking If my bank kept my money in a cardboard box in their parking lot and children stole it, I would blame the bank before the children. As long as corporations and institutions design their computer systems only for convenience and least cost, with maybe a superficial gesture at something called 'security', they won't solve the problem. The biggest risk of all is from people who won't accept their responsibility. - William Ehrich ------------------------------ Date: Mon, 8 Apr 1996 11:40:21 -0400 From: John Hoffmann Subject: Microsoft Exchange helpfully misdirects e-mail Like most e-mail clients, Microsoft's Exchange allows you to maintain lists of user's addresses along with aliases. In our simple configuration, we have two, a personal list and a global list. Up until recently, since our e-mail system was closed and limited to project members, my personal list was almost empty. Since we have added an Internet gateway, I've begun adding addresses not on the global list to my personal list. Exchange has another useful feature as well, it will expand names from just the first characters. If multiple names match the abbreviation, it will ask you to pick one. Today I sent out an internal message, using "schu" as an abbreviation for schumacher, which I have done many times in the past. Shortly there after the message was returned from the AOL e-mail daemon as undeliverable, highly surprising since it was an internal message not destined for the Internet. It turns out that last week I incorrectly added an AOL user whose name also begins with "schu" to my personal address list. Exchange apparently only checks one list at time, flagging multiple possibles only within the list. In this case, it checked my personal list first, matched the AOL user, and quietly sent the message on. If the name at AOL had been correct, I would have not known about the misdirection at all. The risks are obvious - instead of a somewhat trivial and incomprehensible internal message, the message could have been highly confidential or time critical. The solution is trivial as well - check all mail lists for conflicts (or at least have that as the default configuration & easily selectable). ------------------------------ Date: Fri, 5 Apr 1996 19:09:29 GMT From: Tim Pierce Subject: Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01) >Usenet (at least NNTP) is generally 8-bit transparent, and any European >soc.culture group will tell you that ISO 8859-1 usually works, ... Though many machines on Usenet are eight-bit clean, NNTP is defined to be seven-bit. There's no guarantee that the use of raw characters in ISO-Latin-1 will come out unharmed on the other end. More risks: assuming that an action is advisable simply because it "usually works." This, unfortunately, is becoming more and more common even among news software developers, some of whom have simply conceded the seven-bit encoding battle and now write for an eight-bit net. ------------------------------ Date: Tue, 9 Apr 1996 10:39:53 -0500 From: Otto Stolz Subject: Re: Notes on e-mail: Use diaeresis (Sandee, RISKS-18.01) On 2 Apr 1996 16:20:16 GMT, sandee@Think.COM (Daan Sandee) said: > [...] "co=F6perate", "na=EFf", and "Bront=EB.". [...] It was already > mangled in the RISKS posting Apparently, these examples were sent to RISKS encoded as "quoted-printable". I guess, they were contained in an e-mail item adorned with the appropriate MIME headers to announce that transfer encoding to any interested parties. However, in the process of digesting, all header fields (except the From, To, and Subject fields) were stripped off. This seems to be a general problem with contemporary mail-digesting software. Of course, the transfer-encoding has to be undone before you can safely remove the pertinent header field. I hope, our moderator will be able to find a mail-digesting program that handles MIME headers properly. > [...] I wish people wouldn't assume that the way their machine handles > non-ASCII characters is the same as everyone else's. This is exactly the reason MIME was invented for. > Usenet (at least NNTP) is generally 8-bit transparent, and any European > soc.culture group will tell you that ISO 8859-1 usually works [...] Not quite so! There are mail transfer agents, and perhaps other intermediate software, that still will drop the most significant bit of every 8-bit character. > This post of mine, however, goes out by e-mail (SMTP) and upper bits will > be stripped [...] Hence, contributions to RISKS, and other e-mail based services, must exploit MIME to convey those characters (until, eventually, the powers that be might agree on a 8-bit, or even 16-bit, based mail protocol). It is the digester's duty to undo any transfer-encoding before the mail is digested, and to encode the whole digest for transport, as necessary. > Well, I can handle diaereses all right, as long as they arrive in a form > recognizable by my software. And it will be the subscriber's duty to undo the transfer-encoding of the whole digest. Otto Stolz [I have asked several folks what I would need to do to MIME-ify RISKS. I get responses that it is not that easy, or that it won't help those who don't deal with MIME, or that perhaps I should just wait until things settle down. Meanwhile, we have a justification for indigestion with undigestification. PGN] ------------------------------ Date: Thu, 04 Apr 1996 19:34:12 +0200 From: Heinz-Bernd Eggenstein Subject: CompuServe's "secure login protocol": two steps forward, one back Summary: a new CompuServe Information Service (CIS) logon protocol was designed to prevent passive and active attacks (where the attacker impersonates a CompuServe node) but a flawed implementation in the WinCIM 2.0(.1) client software still allows active attacks. Version 2.0 of the "WinCIM" access software introduced a new logon protocol. Previous versions of the software had transmitted the user's UID AND his/her password in plaintext during logon. The risks are obvious, especially when connecting via the Internet to CompuServe (e.g. to save long distance telephone charges). The new, "secure logon protocol" is a challenge-response type protocol where the "challenge" is to compute a keyed hash-function, the key is derived from the shared secret, the user's password: 1) The client (WinCIM) generates a pseudorandom string of bits, its "nonce" (RB) 2) The client transmits the user's UID (e.g. 12345,6789) and the additional parameter "/secure:1" to request a secure login. 3) The host transmits its pseudo random nonce (RA) (The old protocol would instead prompt for the password) 4) client sends RB to the host 5) client computes UR:=MD5(S|Z|RA|RB|S) and sends it to the host (where S (128 bits) is a function of the password, "|" stands for concatenation, Z is a 128bits block of 0s and MD5 is the well known message digest function.) 6) The host performs the same calculation with it's copy of the user's password. If the results match, the host sends HR:=MD5(S|Z|RB|RA|S) (Note the symmetry in the calculation of HR and UR) 7) The client software verifies HR with it's copy of the password to make sure the host is really a CIS node (!) (See the script-files cserve.scr and seclog.scr in the subdirectory SCRIPTS of a WINCIM 2.0(.1) installation, WinCim is available via anon. ftp at ftp.compuserve.com). Weaknesses: a) The scriptfile cserve.scr (versions 3.8 & 3.8.1) has the following bug: even after requesting a secure logon, the client software will fall back into the old protocol when receiving a "Password" prompt (Client: "I want a secure logon" Host:"OK, but anyway, give me your password" Client "Well ok then, here it is ..."). It will send the password in plaintext! This makes the protection against active attacks (see step 7) obsolete. b) A timeout condition or even an invalid HR response form the host will (seclog.scr & cserve.scr version 3.8.1) restart the protocol (it won't disconnect!), using *the same* client-nonce RB again, instead of generating a new one. If a spoofing host can predict RB as in this situation, it can pick the same nonce, leading to HR=UR=MD5(S|Z|RB|RB|S), so the host can just send back UR as HR. Note that unlike a), b) does not compromise the user's password. There may be other ways to predict the client software's nonce e.g. *if* the PRNG used by WinCIM is predictable (this calls for further investigation). Note that *offline* dictionary attacks to guess the password are possible after a passive, eavesdropping attack (so you still have to pick a "good" password). It's debatable whether CIS's password recommendation (, both words unrelated, e.g. apple@battery) is adequate in this context). I notified CIS about these weaknesses and I was informed that they are "fixed" now, no details were given about the fix (source: Britta Herbst, German customer support (11111.754@compuserve.com)). Risks? The new protocol is obviously an improvement over the old, plaintext-password-only version. It's debatable whether protection against active attacks is at all necessary for access to an online service. However, CIS itself designed it's protocol to prevent spoofing attacks. Anyway, I think this a good example how to half-ruin a good protocol by embedding it into carelessly written code. Credits: Thanks to Gary Brown (70003.1215@compuserve.com) for sending me information on the implementation of the new protocol). Heinz-Bernd Eggenstein [usual disclaimers] ------------------------------ Date: 03 Apr 1996 13:11:21 UT From: Erik Naggum Subject: IBMMAIL e-mail address woes You may not know the IBMMAIL system. Internet addresses are translated to a seven-digit number, which users use instead of real addresses. It so happens that I once ran a large mailing list and needed to track down which messages were not delivered to which people, and so generated a unique Return-Path for each message. This caused a large number of IBMMAIL numbers to be assigned to such addresses. About once a month, I receive confirmations of business transactions between Hong Kong and Singapore companies to one of these addresses. Clearly, the RISK is that humans mistype numbers all the time, and when the addresses in a given range are all valid, will send mail to the wrong recipient every now and then, just as people misdial telephone numbers. All information expressed in long numbers whose accuracy matter to either party include redundant digits to reduce the number of valid numbers and to provide consistency checks. The same should be true of IBMMAIL numbers. (Indeed, it should perhaps be true of domain names and usernames, too.) # ------------------------------ Date: Thu, 4 Apr 1996 10:42:36 -0500 (EST) From: Peter Yamamoto Subject: Re: X-Confirm-Reading-To: Pegasus woes on mailing lists... > Recently, on a mailing list I maintain, a Pegasus (the name of a > Mac/Windows e-mail reader) user posted a message with a line: > > > X-Confirm-Reading-To: > > This would be fine if Pegasus respected the field value when acting on > the presence of this field. But Pegasus programmers apparently took the > RISK of assuming that they didn't have to. Now every list member using > Pegasus is generating a confirmation message to the list. Well, the problem wasn't as simple as that, that is only what it looks like... The "problem" is due to a new release of Pegasus which added a directed confirmation header field as well as keeping the old confirmation header field (which old versions simply respond to as best as they can). The new field name is called X-Confirm-Reading-To: and the old name is "X-pmrqc: 1". Hence, unless familiar with these things, the mailer looks like it is not behaving. There are Risks in this whole episode, but I've worn myself thin trying to defend the meaning of my post to a listserv listowner's list (a warning of disruptive behaviour) with the author of Pegasus who took my comments differently (as a rude personal attack). Peter ------------------------------ Date: Tue, 2 Apr 1996 11:12:20 -0500 (EST) From: cpbeaure@undergrad.math.uwaterloo.ca Subject: The risks of .forward Standard procedure for us net types is to leave .forward files when we change accounts. This is what I did when I left my previous employer. Because of the nature of the Internet firewall we had there, to access the net users had to actually log into the firewall machine - a bad idea in itself, but it gets worse. One fine day, I logged in to find a message informing me that the firewall password had changed. Conveniently, the message also included the new password. It seems that when I left, not only had they not erased the .forward file, but they hadn't removed me from the system alias file. The risks? 1) Clean up after your old employees. 2) E-mail goes everywhere. 3) Don't e-mail passwords. Ever. ------------------------------ Date: Fri, 05 Apr 1996 16:59:49 PST From: Andrew Berman Subject: Re: Wrong approach to Java security (Stuart, RISKS-18.01) >In RISKS-17.95, Jacob Palme suggests that the reputation of "well-kept >depositories" and PICS-like ratings can be used to guard against malicious >Java code. A more useful idea along the same lines is to allow for code to >carry a digital signature. ... Neither PICS-like ratings nor Digital Signatures is going to solve the problem. Yes, they might constrain some malicious users. But what about the data loss from buggy software? Also, decentralization of code is a promise of web-based languages. A world in which every piece of code has to be checked against a database of signatures is a much less flexible world than one in which code runs in a "safe" environment. Not to mention that a digital signature for a company will undoubtedly be known by more people than a digital signature for a single user. Thus, the opportunities for theft of the signature would increase dramatically. Andrew P. Berman Dept. Of Computer Science, University Of Washington aberman@cs.washington.edu| http://www.cs.washington.edu/homes/aberman ------------------------------ Date: Tue, 09 Apr 1996 09:58:42 -0500 From: JEREMY J EPSTEIN Subject: Re: Risks of rewritable BIOSes (Epstein, RISKS-8.01) After my posting in RISKS-18.01, several people sent me e-mail. A few clarifications to my original note: * Some PC vendors have a jumper that disables writing the flash. In my experience, this is unusual, although it's clearly present in some cases. For those who are lucky enough, the jumper is even documented. Clearly this is a good solution for those whose PCs have the option. Of course most users won't read the manual that comes with the PC and thus won't realize that there's a risk, much less understand how to thwart it. [Pointed out by mark@leasion.demon.co.uk (Mark Evans) and afelson@milton.ecte.uswc.uswest.com (Adam Felson).] [AND also by "Nicholas C. Weaver" , with the default being disabled -- see the next item. PGN] * I wrote "...each vendor has solved the problem differently..." The word "vendor" should be understood as the vendor of the motherboard, which may not be the same as the PC vendor. That is, a brand X PC may use a brand Y or brand Z motherboard. So looking at the outside of the case may be insufficient to determine whether the PC is "safe". [Pointed out by Mark Evans.] * As an aside I wrote that the risk would be eliminated if people used more modern systems such as UNIX, OS/2, or NT. As pointed out by Benedikt Stockebrand (benedikt@devnull.ruhr.de), it doesn't *eliminate* the risk, because there may be bugs that allow subverting the system and thus gaining access to the flash RAM. Stockebrand also pointed out that (on UNIX systems) if you can get the virus/trojan run by root, then all bets are off. Perhaps I should have said that running a more modern system *reduces* the risk, since a virus/trojan would have to be a lot smarter than in a DOS/Windows environment. The above not withstanding, the point stands: most Pentium-based PCs are extremely vulnerable to flash-based attacks. ------------------------------ Date: Fri, 5 Apr 1996 10:52:40 -0800 From: "Nicholas C. Weaver" Subject: Re: Risks of rewritable BIOSes (Epstein, RISKS-17.81) Although I believe software solutions are necessary for correcting the flash-BIOS problem on existing motherboards, I think all future motherboards should just resort to an old-fashioned physical jumper. If the jumper is in place, then the BIOS is reprogrammable. (If a malicious person has access to your motherboard, he/she can do a LOT more damage then simply reflashing the BIOS, but a malicious program can't -- especially if the motherboard is shipped without the jumper in-place.) ------------------------------ Date: Sat, 6 Apr 1996 15:59:55 -0500 (EST) From: "Shabbir J. Safdar" Subject: Re: Computers, Freedom and Privacy '96 (RISKS-18.01) My RISKS commentary about the Bruce Sterling piece at CFP '96 drew many pieces of e-mail. You can get a RealAudio recording of it from URL:http://www.w3.org/pub/WWW/CFP4/live.ram (I don't have a RealAudio player on this machine, so I cannot verify that it works..) The live version left me feeling numb and panicky. [oram@unixg.ubc.ca (John Oram) reported that the audio version of the entire CFP 96 is available for your listening pleasure "(in the bandwidth-conserving RealAudio format)" at: http://swissnet.ai.mit.edu/~switz/cfp96/ .] ------------------------------ Date: 18 March 1996 (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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for unabridged version of RISKS information] 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, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Particularly relevant contributions may be adapted for the RISKS sections of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. * Submissions: By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited public distribution and redistribution in electronic or other form. * Reuse: Blanket permission is hereby granted for reuse of all materials in RISKS, under the following conditions. All redistributed items must include the Risks-Forum masthead line. All reuse must be accompanied by the following statement: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse. As a courtesy, reusers of individual items (as opposed to forwardings of entire issues) should notify the authors, and should pay particular attention to any subsequent corrections. RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks 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 PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 18.02 ************************