RISKS-LIST: Risks-Forum Digest Weds 13 February 2002 Volume 21 : Issue 91 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.91.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Microsoft C++ feature against buffer overflows itself vulnerable (Gary McGraw) Hole found in Net security program (Bill Hopkins) Security flaw in Sony Vaio computers (Monty Solomon via Dave Farber) Computer controller crane goes wrong (Jeff Jonas) Election risks from lack of randomization (Keith Price) Search engines may give you the wrong e-mail address (Robert Marshall) Hotel Internet access (Christian Holz) "Secure" credit-card transactions with new Amstrad e-mailerplus (Merlyn Kline) Officer calls for refund of 'speeding' fines (Monty Solomon) Risks of the rise of PowerPoint (Andrew Main) Microsoft and English (Toby Gottfried) Re: Bulgarian parliament against weight loss (Valentin Razmov) Bill payer system silently changes payments (Phil Weiss) Social Security Numbers printed on tax envelopes (Steve Klein) Virus writers aren't playing fair (William Colburn) Re: Homograph risks (Merlyn Kline) Survey finds security lax at nonprofits (Audrie Krause) REVIEW: "Zimmerman's Algorithm", S. Andrew Swann (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 13 Feb 2002 12:57:03 -0500 From: "Gary McGraw" <gemat_private> Subject: Microsoft C++ feature against buffer overflows itself vulnerable Microsoft added a new security feature to their latest C++ compiler, called both Visual C++.Net and Visual C++ version 7, that was released 13 Feb 2002. This security feature is meant to protect potentially vulnerable source code automatically from some forms of buffer overflow attack. The protection afforded by the new feature allows developers to continue to use vulnerable string functions such as strcpy() as usual and still be "protected" against some forms of stack smashing. The new feature is closely based on an invention of Crispin Cowan's StackGuard and is meant to be used when creating standard native code (not the new .NET intermediate language, referred to as "managed code"). Note that the new feature is meant to protect any program compiled with the "protected" compiler feature. In other words, the idea is that using this feature should help developers build more secure software. However, in its current form, the Microsoft feature leads to a false sense of security because it is easily defeated. An ironic RISK, to be sure. Microsoft's feature includes the ability to set a "security error handler" function to be called when a potential attack is underway. Because of the way this was implemented, the Microsoft security feature is itself vulnerable to attack. An attacker can craft a special-purpose attack against a "protected" program, defeating the protection mechanism in a straightforward way. There are several well known approaches not based on StackGuard that a compiler-producer might use to defeat buffer overflow attacks. Microsoft chose to adopt a weak solution rather than a more robust solution. This is a design-level flaw leading to a very serious set of potential attacks against code compiled with the new compiler. The Microsoft compiler is thus in some sense a "vulnerability seeder". More technical information about the flaw can be found at http://www.cigital.com/news/mscompiler-tech.html The flaw was discovered by Chris Ren, a Cigital Labs researcher. Microsoft has been alerted to the flaw and plans to address it in future VC releases. Gary McGraw, Ph.D., CTO, Cigital ------------------------------ Date: Fri, 8 Feb 2002 19:18:39 -0500 From: "Bill Hopkins" <whopkinsat_private> Subject: Hole found in Net security program In case you haven't seen it... I'm sure you'll hear from others who are likely more familiar with the product. http://www.nytimes.com/aponline/technology/AP-Computer-Security.html Quick summary: BlackICE Defender and BlackICE Agent have a security hole involving, yes, buffer overflow. Once through the firewall, guess who's in charge? A download fixes it. ------------------------------ Date: Sat, 26 Jan 2002 17:51:43 -0500 From: David Farber <daveat_private> Subject: Security flaw in Sony Vaio computers (from Monty Solomon) TOKYO: Japan's Sony issued a warning on Thursday after finding a software problem in a popular range of computers that could expose around 900,000 customers to attacks from hackers. [...] http://www.timesofindia.com/articleshow.asp?art_id=473172674 ------------------------------ Date: Sun, 10 Feb 2002 04:01:49 -0500 (EST) From: "Jeff Jonas" <jeffjat_private> Subject: Computer controller crane goes wrong Jersey City NJ, 16 Jan 2002: A computer controlled/assisted crane got into an unstable position, requiring the evacuation of nearby apartments for 2 days now. RISKS follows when airplanes and trains surrender control from people to computers. Now add construction cranes. ------------------------------ Date: Tue, 12 Feb 2002 11:34:39 -0800 (PST) From: Keith Price <priceat_private> Subject: Election risks from lack of randomization At first I did not think it was a computer risk. I'm still not sure if it is, but the random order list is computerized. The Mayoral election (Nov 2001) in Compton, CA was overturned (8 Feb 2002) because of the random ordering of names on the final ballot. The local clerk had not requested a new randomized order from Sacramento, and had used the same order as in the earlier primary election. The Judge decided that the 300-vote margin was less than the advantage due to being listed first rather than second and reversed the counted results. So, in California they will count your vote, but your vote may not count. ------------------------------ Date: Tue, 12 Feb 2002 13:33:31 +0000 From: "Robert Marshall" <robertat_private> Subject: Search engines may give you the wrong e-mail address I was searching for the work e-mail address for a friend using google. Let's say the name was Paul Consultant. Google gave me a hit with the correct company and the web page was such that his e-mail appeared in the google summary. So I cut and pasted it directly without having to visit the company web site. It appeared as PR.Consultantat_private When the e-mail bounced I investigated and the company web page has the mail as P.R.Consultantat_private, as does google's cache. It looks as if google is trying to cut down on the synposis by removing redundant '.'s Unfortunately they aren't always redundant. Fortunately my e-mail bounced rather than going to an unrelated recipient. ------------------------------ Date: Mon, 11 Feb 2002 01:30:18 +0100 From: Christian Holz <chrishat_private> Subject: Hotel Internet access I have just found out about an interesting feature of STSN Internet Access, common at hotels in the New England area. They have little boxes connected in each room which provide either full-fledged Ethernet access, USB or Modem connections. To make it especially easy for users, they re-route packets based on the service used(!). When I tried to connect to my SMTP server (which uses SMTP-AUTH to protect against Spamming), I got a message informing me that the used SMTP server does not provide SMTP-AUTH. After a short heart-attack that my server has been hacked, I telnetted to my SMTP-Server and I was connected to STSN's. The risk: Obvious, if they can re-direct based on the service used, they could possibly see a lot of passwords by providing proxy-services for common services. In addition with the hotel-guest information, this could give an interesting profile of hotel guests. I wonder what information they can get their hands on if they have this services in Capitol-Hill hotels... I am using SSH-tunnels from this day onwards... ------------------------------ Date: Fri, 8 Feb 2002 15:53:01 -0000 From: "Merlyn Kline" <merlynat_private> Subject: "Secure" credit-card transactions with new Amstrad e-mailerplus Amstrad (http://www.amstrad.com/) in the UK have announced their new Internet appliance, the e-mailerplus. Among other features, this includes a "built in a SMARTCARD reader to enable Secure Credit Card Transactions in the future". Given that there is no extant standard for this sort of thing, I wondered how this would work. The answer is quickly found on their web site: "The e-mailerplus has all the necessary hardware required to enable this additional level of security ALREADY BUILT-IN and it is only a matter of delivering the software code to the machine remotely, which we will do, as and when it is developed." "We will be developing software in conjunction with this secure payment system which will be downloaded automatically to the entire population of this machine at NO cost to the user." RISKs readers will no doubt wonder what other code might be downloaded, by whom, and for what nefarious purposes. ------------------------------ Date: Sun, 10 Feb 2002 23:56:39 -0500 From: Monty Solomon <montyat_private> Subject: Officer calls for refund of 'speeding' fines HARTFORD - A hearing officer for the state Department of Consumer Protection recommended yesterday that a New Haven rental car company be ordered to refund the ''speeding'' fines it levied after tracking customers with satellites. Hearing officer Robert H. Brinton Jr. also recommended that Acme Rent-a-Car be prohibited from fining customers in the future. The company had used global positioning system satellites to track its cars and had fined renters $150 each time a car exceeded 79 mph for more than two minutes. ... [Source: Associated Press, 8 Feb 2002] http://www.boston.com/dailyglobe2/039/metro/Officer_calls_for_refund_of_speeding_fines+.shtml ------------------------------ Date: Sun, 10 Feb 2002 23:09:54 +0000 From: zeframat_private (Andrew Main) Subject: Risks of the rise of PowerPoint There was an interesting radio program today discussing the influence of the PowerPoint program on business ("In Business", BBC Radio 4, 2002-02-10 21:30). One of the presenter's main points was that the use of PowerPoint has affected the way businesses operate: not only are slides now used so much that each presentation revolves around its slides, rather than vice versa, but also apparently PowerPoint now has a Content Wizard, that provides templates for certain types of presentation. There were reports of PowerPoint users sticking religiously to the format of the template, as the canonical way to organise a presentation. The PowerPoint developer who was interviewed sounded somewhat embarrassed by the phenomenon: she said "~we expected people to modify those presentations a great deal~" (approximate quote). The main risk here is familiar: users blindly accepting whatever default the computer provides, without considering whether it's appropriate (RISKS-7.57, et al.). In this context, rather than doing anything sufficiently incorrect to make things obviously fail, the inappropriate defaults are having a subtle influence on businessmen's thinking (slides titled "our vision for the future" and so on). Really the risk is a more general informational one -- people misunderstanding the purpose and intent of a piece of information, or often misunderstanding which source of information is authoritative. We have the same class of problem when humans talk to humans -- how many people will call their bank and ask "please change my address" rather than "please note my change of address"? The obvious solutions are also human/informational ones: clearer thinking about these issues on the part of the receivers of information, and on the other side clearer labelling of the intent of information. Andrew Main <zeframat_private> ------------------------------ Date: Sun, 10 Feb 2002 11:57:39 -0800 From: "Toby Gottfried" <toby6700at_private> Subject: Microsoft and English In RISKS-21.90, Bear Giles writes about Microsoft "appropriating" the word "begin" in e-mail messages to denote UUENCODEd text. "Microsoft's justification for suggesting a significant change to the English language instead of fixing their bug is given as:" Riding roughshod over some little used trifle like the English language is not a big deal to an important technology innovator like Microsoft. They did just that by naming a major project dot-Net (".Net"). Before that, a period followed by a capital letter was used to mark a sentence boundary. Experienced readers of English will note a brief interruption in their parsing whenever .Net is encountered mid-sentence. And they will be annoyed about it. ------------------------------ Date: Tue, 22 Jan 2002 21:19:22 -0800 (PST) From: Valentin Razmov <valentinat_private> Subject: Re: Bulgarian parliament against weight loss (Larmour, RISKS-21.88) > weighing scales set into the seat While the proposed improvement does have its downsides, the alternative suggestion for using personalized cards would *not* work as it misses the main point the system is trying to solve (and the biggest problem of the previous system) - preventing collusion. (MPs have been known to give their cards to colleagues while absent from the plenary hall, which creates the danger of passing laws without even having quorum among voting MPs.) Cards (whether personalized or not) are capabilities, possibly with some form of authentication "attached" to defeat theft, but certainly not to defeat collusion - if I want to give you my card, I could just as well tell you my secret code for "activating" it. Hence biometrics come to mind as a form of authentication that prevents collusion in our case without the need for a designated parliament secretary looking over MPs' shoulders. Weighing scales offer a degree of protection at a very low cost. The system does allow both false positives (non-malicious MPs unable to vote because of a sudden difference with their established weight) and false negatives (dishonest MPs casting a vote not only for themselves), and while this does not guarantee that glitches won't happen, it also makes premeditated malice somewhat harder to carry out. Alternative schemes would have their own tradeoffs and it is not immediately clear if any of them would be any more cost-effective. (The low-tech version of MPs standing in line to cast physical ballots every time they need to vote is about as fool-proof as can get, but not very efficient.) Valentin Full disclosure: I am Bulgarian, but I did not know about the new system until reading the news. ------------------------------ Date: Tue, 22 Jan 2002 21:01:43 -0800 (PST) From: Phil Weiss <philsjunkmailat_private> Subject: Bill payer system silently changes payments I use First Tech Credit Union's (http://www.1sttech.com/) online bill payer system. As is typical for many financial institutions, the processor is not First Tech itself, but instead a company called Princeton ECom (http://www.princetonecom.com/). The system works by having the user select a payee, then having the user enter in the due date for the bill along with the amount. If the processor can pay the bill using electronic funds transfer (EFT), the system subtracts 3 days from the date entered and uses that for the day money will be withdrawn from your account and the payment sent. If the processor cannot pay using EFT, it subtracts 8 days from the due date and uses that instead. It then presents a confirmation page. I found out recently a couple of risks (in addition to some known ones with their system). When my December payment was late, I looked at the status of the payment and was surprised to see that it had silently been changed to "check" from "electronic." Since it had been scheduled 3 days before the due date but was now sent by check, it arrived several days late. When I inquired to the credit union they gave me several explanations. The processor recently began requiring the account number that is entered for my mortgage company to be a 10 digit number (0001234567 instead of 1234567). At the same time the mortgage company changed it's "make checks payable to" name from Mortage Service Center back to PHH Mortgage Services (they've switched this several times on me over the years). They will make that change silently without warning the user if you change anything about the payee to break the match of your payee info to their list of EFT payess. And if they make a change to the payee due to a change in policy, it will change your payment methods without notifying customers that they need to update their pending payments. It isn't really a ris, it's a certainty of errors. The risk on my part was assuming the system would work. Being a software developer by trade, it's something I shouldn't have assumed. I've since changed all the important payments so that the due dates are at least a half a month ahead of their due date. If I don't see the money deducted from my account, I can take substitute action. (For things like my newspaper subscription, I don't really care.) ------------------------------ Date: Tue, 29 Jan 2002 08:47:37 -0500 From: Steve Klein <stevekleinat_private> Subject: Social Security Numbers printed on tax envelopes The city of Detroit, Michigan has sent out 400,000 income tax forms with taxpayers' social security numbers printed on the outside of the envelopes. City officials were unable to explain why the numbers were included on the forms or how the printer got them. Ralph Kinney, deputy chief of the Wayne County Sheriff's Department's High-Tech Crime Unit, said names, addresses and Social Security numbers are the main targets of identity thieves. "Social Security is really the key to unlocking a person's credit identity," Kinney said. "If that key falls into the wrong person's hand, it makes it a lot easier for someone to become that person." Identity theft, a felony in Michigan, is one of the fastest-growing white-collar crimes, Kinney said. Dennis Ertzbischoff, a local citizen who was one of those affected said, "This is the kind of mistake a first-year programming student would make. This was sheer stupidity. Nobody reviewed the work, and nobody caught it." (Excerpted and paraphrased from the Detroit Free Press, 2002-01-29.) Steve Klein, Your Mac Expert, Phone (248) YOUR-MAC-EXPERT (or 248-968-7622) ------------------------------ Date: Mon, 28 Jan 2002 15:53:36 -0700 From: "Schlake ( William Colburn )" <schlakeat_private> Subject: Virus writers aren't playing fair Today I got a weird e-mail with some inline uuencoded data that had a filename of www dot myparty dot yahoo dot com. My Mcafee didn't detect it as a virus, but it uudecoded into a DOS executable so I was suspicious. I sent it off to Mcafee, and they sent me back an EXTRA.DAT for it. Then came the real trouble. I use a milter I wrote (http://www.nmt.edu/~wcolburn/antivirus/) to detect viruses. Up until today, it had used error codes to know if a file needed scanning. The mail file would be "ripmime"ed, and if the error code was 0 (no error) then it meant that some files were successfully extracted. If files were extracted then they needed to be scanned. This new virus, W32/Myparty (ED), defeated me on several levels. The virus wasn't MIME encoded, so ripmime didn't find it. I added a blind uudecode to my milter, but it was defeated as well. The uuencoded virus is "corrupt" (but it creates some output which runs), so the return code from the uudecode command indicates (is indistinguishable from) nothing decoded. In the end, I decided that the best thing to do is to blindly uudecode AND ripmime AND scan every single message. As you can imagine, this is a terrible solution. The core of the problem stems from the fact that MS products seem to "be generous in what they accept" (the way all good software should be written?), and so they don't care that the mail wasn't MIME encoded, nor that it contained a corrupt file. The risk is that systems are so complex it is getting increasingly hard to protect them. That virus shouldn't propagate because it isn't MIME encoded, but it does. That virus shouldn't propagate because it uses a corrupt file transfer, but it does. If both things were done on purpose, then the writer was clever. I can image that more software writers than myself considered "garbage" or "corrupt" data as "safe". ------------------------------ Date: Wed, 30 Jan 2002 09:47:31 -0000 From: "Merlyn Kline" <merlynat_private> Subject: Re: Homograph risks (RISKS-21.89) > For example, a Russian "o" and an English "o" look alike ... The default font chosen by Microsoft for some of their desktops (e.g., Windows NT) contains homographs for lowercase L and uppercase i. I've suffered from minor problems arising from this and I can imagine bigger risks. Worse, the default font used by many of their code editors used to contain homographs for lowercase L and the number 1. I learnt this the hard way, staring at broken code that was *obviously* correct! I've long since acquired the habit of using a non-standard font for code editing so I can't say whether the latest versions of their fonts still have this problem (which is presumably inherited from the historical use of lowercase L as the number 1 on many typewriters). [Backwards compatibility is either a pun or an oxymoron. PGN] ------------------------------ Date: Wed, 30 Jan 2002 11:26:45 -0800 From: Audrie Krause <audrieat_private> Subject: Survey finds security lax at nonprofits We've just released the results of NetAction's survey of security practices in nonprofit organizations. I thought it might be of interest to RISKS readers. Despite the growing importance of computers to nearly every aspect of nonprofit operations, an online survey of security practices in nonprofit organizations found substantial room for improvement, especially in maintaining the security of confidential and/or sensitive files, user work habits, and disaster planning. "Nonprofit organizations are just as vulnerable to cyber attacks as businesses and government agencies," said NetAction executive director Audrie Krause. "This should be a wake up call to the nonprofit sector: security needs to be improved." NetAction's report on the survey results, "Computer Practices in Nonprofit Organizations," is available at: http://netaction.org/security/. Many of the respondents acknowledged the need to improve their security practices. When asked to identify specific security issues their organization needs to address, about two-thirds of the survey respondents listed user work habits and disaster planning, about half listed data backups and encryption, and about one third listed virus protection and firewalls. The need to improve the security of confidential and/or sensitive files (such as personnel records or financial documents) was especially evident. Only 4% of nonprofit organizations encrypt all sensitive files. Yet nearly two thirds of the organizations surveyed store sensitive files on computers connected to a local network, and nearly half store them on computers connected to the Internet. Moreover, computer users in nearly one fourth of the organizations that NetAction surveyed do not routinely lock or shut down their computers when they are away from their desks, and 80% of the nonprofits indicated that volunteers, interns, outside consultants and/or temporary staff have access to office computers. "Some risks aren't as obvious as others," said Krause. "Most organizations are aware that they could lose important data if they don't do regular backups. But they may not realize that when users forget to logoff, a disgruntled employee could steal confidential information, or a nosy volunteer could access an organization's personnel records." NetAction's survey also found that only slightly more than half of the nonprofit organizations back up their data every day, and only about one third have a data recovery plan in the event of catastrophic data loss. The organizations did a somewhat better job of protecting their computers from viruses. About two-thirds of the organizations updated their anti-virus software one or more times per month. However, the survey also found that about two-thirds of the nonprofits use Microsoft's Outlook or Outlook Express to send and receive e-mail despite the higher risk of an attack by viruses or worms than with other e-mail clients. The online survey was conducted between December 19, 2001 and January 20, 2001. Although the results cannot be generalized to the larger nonprofit community because random sampling techniques were not used, Krause said nonprofit organizations should find the report useful in assessing their own computer security practices and identifying practices that need improvement. [...] She added, "Security experts were concerned about the vulnerability of computer systems to cyber attacks long before the horrendous events of September 11, 2001; the level of concern has only increased since the terrorist attacks on New York City and the Pentagon. [...] NetAction, Audrie Krause, Exec.Dir., 601 Van Ness Ave., No. 631, San Francisco CA 94102 1-415-775-8674 http://www.netaction.org audrieat_private ------------------------------ Date: Tue, 12 Feb 2002 07:56:32 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Zimmerman's Algorithm", S. Andrew Swann BKZIMALG.RVW 20011126 "Zimmerman's Algorithm", S. Andrew Swann, 2000, 0-88677-865-4 %A S. Andrew Swann (Steven Swiniarski) %C 375 Hudson Street, New York, NY 10014 %D 2000 %G 0-88677-865-4 %I DAW Books Inc. %P 387 p. %T "Zimmerman's Algorithm" A thriller should have a convoluted plot, but this one has slightly too many twists and turns for comfort. It's very difficult to keep track of at least three sets of bad guys, and by the time the penultimate plot is exposed I had a hard time caring who was responsible. Still the action is brisk, and the writing is lively and interesting. So is the fact that so much technology in the story is basically correct. The outcomes are sometimes questionable, such as a computer made with superconducting materials that physically (and not just electrically) degrade at room temperature. But the fact that researchers developing artificial materials are steadily working towards room temperature superconductors is true. The math isn't that bad, either. There is a slight overemphasis on the need for primes in encryption systems, but it is interesting to see a recognition of the controversy over enormous computer generated proofs. The computer work is a bit weaker. Genetic algorithms are not terribly well explained in the computer world in general, so it isn't surprising that the detail in the book is a bit fuzzy. The discussion of computer viruses as a form of artificial life is interesting, as is the view of benignity as a survival factor, although the idea of masses of undetected viruses hiding out on the Internet is a bit much. (I must say, though, that, if you are going to propose the usual undetectable virus, one that can write operating systems is a good candidate.) I would like to know whether the choice of name for the eponymous mathematician was influenced by PGP. copyright Robert M. Slade, 2001 BKZIMALG.RVW 20011126 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.91 ************************
This archive was generated by hypermail 2b30 : Wed Feb 13 2002 - 23:22:01 PST