RISKS-LIST: Risks-Forum Digest Friday 21 February 2003 Volume 22 : Issue 58 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/22.58.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Surgeons transplant mismatched organs (Steve Klein) Health threat from computer use (Pete Mellor) INFOSEC issues reach out to elevators (Russ Cage) A $55,000 Net scam warning (Monty Solomon) FTD.com hole leaks personal information (Fuzzy Gorilla) ATM vulnerabilities and citibank's gag attempt (Ross Anderson) Microsoft steamed over Hotmail spam (NewsScan) Deadly input validation? (Chris Adams) Fire risks (Tony Jones) "E-lip" telemarketing phone systems (Al Meers) Web site product serial number validation (Nik Smith) Two-digit year field strikes again (Fuzzy Gorilla) Too much tech can kill you (Jesus Climent) Lawyers say hackers are getting bum rap (NewsScan) Re: Playing Russian Roulette with traffic lights (Nicholas Weaver) The fourth solution... (Peter da Silva) REVIEW: "Mike Meyers' Security+ Certification Passport", Trevor Kay (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 20 Feb 2003 11:44:33 -0500 From: Steve Klein <stevekleinat_private> Subject: Surgeons transplant mismatched organs On 7 Feb 2003, doctors at Duke Hospital in North Carolina mistakenly transplanted a heart and lungs from a donor with Type A blood to a recipient with Type O blood. Her body immediately started rejecting the transplanted organs. The organs, which came from a cadaver in Massachusetts, included paperwork correctly listing the donor's type-A blood. The hospital admits the error, but hasn't made public any information indicating how the mistake was made. On 20 Feb, new matching organs were transplanted in a second surgery. Under normal conditions, a heart-lung transplant has a 50% success rate. [I have yet to hear whether there was any computer-related error here -- for example, someone miskeying the patient's blood type as A or misrepresenting the donor's type as O. Please let us know if you hear anything further. PGN] ------------------------------ Date: Mon, 10 Feb 2003 01:09:44 +0000 (GMT) From: Pete Mellor <pmat_private> Subject: Health threat from computer use Sitting too long at your computer can cause potentially deadly blood clots. The European Respiratory Journal reports the case of a young man from New Zealand who nearly died after developing deep-vein thrombosis (DVT) after using his computer as much as 18 hours a day. The clot in his leg broke off and traveled to his lungs. (This problem has been reported on long airline flights, and was reportedly first noticed in people who sait in World-War-2 air-raid shelters). [Source: BBC news, 28 Jan 2003; PGN-ed] http://news.bbc.co.uk/1/hi/health/2698119.stm Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB +44 (0)20 7040 8422 ------------------------------ Date: Thu, 20 Feb 2003 17:22:37 -0800 (PST) From: Russ Cage <russcage937362at_private> Subject: INFOSEC issues reach out to elevators The RISKS of the following should be obvious to regular readers of this forum. Emphasis IN CAPITALS added by poster, not in original. INTERNET LIFT CONTROL: Alcala University's Electronic Department has a research group that is developing an electronic system that will monitor the operation state of an elevator and transmit that information through the Internet to a central computer. The system would be installed in each lift with temperature-gauge inputs in various locations. The transmission signals WILL PERMIT THE MACHINERY TO BE RESET AND ACTED UPON BY REMOTE CONTROL. Collaboration is being sought through a joint venture or a licensing/manufacturing agreement. .... ELENET(R) is a free e-mail newsletter transmitted biweekly by Elevator World, Inc., the publisher of ELEVATOR WORLD magazine. ELENET(R) is a registered trademark and all rights are reserved. Copyright 2003(C) Elevator World, Inc., 356 Morgan Avenue, Mobile, AL 36606, phone: (251) 479-4514, fax: (251) 479-7043, Internet: www.elevator-world.com. [I got a real UPLIFT from reading that one. I hope it PUSHES YOUR BUTTONS as well. In elevator parlance, it could RUS(S)tle your CAGE. I note that the Spanish word for elevator is "ascensor", which suggests that we might contemplate the SENSOR CENSOR that filters the information that is available to the Internet when a Critical Person or someone with a large rear end (as*censor) enters the elevator, and perhaps even a SEE-YOU-LATER-ALLOCATOR ACTUATOR when you wish to delay someone you don't like. PGN] ------------------------------ Date: Tue, 28 Jan 2003 00:22:29 -0500 From: Monty Solomon <montyat_private> Subject: A $55,000 Net scam warning Despite being described as a long-time Internet user and an accomplished dentist who was knowledgeable about Internet crime, Bruce Lachot decided to buy a new BMW M5 over the Internet from someone in Germany, for the bargain price of $55,000. The result: no car, no trace of the seller, and the need for a lot more dental patients. [Bob Sullivan, MSNBC, 23 Jan 2003; PGN-ed] http://www.msnbc.com/news/854552.asp ------------------------------ Date: Sat, 15 Feb 2003 15:55:52 -0500 From: "Fuzzy Gorilla" <fuzzygorillaat_private> Subject: FTD.com hole leaks personal information A security flaw at FTD.com left a large flowering bouquet of private information ready for picking during the busy business week leading up to Valentine's Day. Using sequentially modified cookies, outsiders could exhaustively access customer billing records, including names, addresses, and phone numbers. (Availability of credit-card data was reported initially, but later denied by FTD -- perhaps after they blocked it.) This was discovered when one customer found another person's information displayed by his browser, and reported to NTBugTraq on 12 Feb. It was fixed on 14 Feb. Prerequisite for doing the attack was reported as 'HTML for Dummies' (or equivalent). [Source: Robert Lemos, FTD.com hole leaks personal information, CNET News.com, 13 Feb 2003; PGN-ed] http://news.com.com/2100-1017-984585.html ------------------------------ Date: Thu, 20 Feb 2003 09:58:47 +0000 From: Ross Anderson <Ross.Andersonat_private> Subject: ATM vulnerabilities and citibank's gag attempt [See the cryptome.org URL below, which is one of the sites at which this message and its supporting documents appeared. PGN] Citibank is trying to get an order in the High Court today gagging public disclosure of crypto vulnerabilities: http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_gag.pdf I have written to the judge opposing the order: http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_response.pdf The background is that my student Mike Bond has discovered some really horrendous vulnerabilities in the cryptographic equipment commonly used to protect the PINs used to identify customers to cash machines: http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560.pdf These vulnerabilities mean that bank insiders can almost trivially find out the PINs of any or all customers. The discoveries happened while Mike and I were working as expert witnesses on a `phantom withdrawal' case. The vulnerabilities are also scientifically interesting: http://cryptome.org/pacc.htm For the last couple of years or so there has been a rising tide of phantoms. I get e-mail with increasing frequency from people all over the world whose banks have debited them for ATM withdrawals that they deny making. Banks in many countries simply claim that their systems are secure and so the customers must be responsible. It now looks like some of these vulnerabilities have also been discovered by the bad guys. Our courts and regulators should make the banks fix their systems, rather than just lying about security and dumping the costs on the customers. Curiously enough, Citi was also the bank in the case that set US law on phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an omen, if not a precedent ... ------------------------------ Date: Wed, 19 Feb 2003 08:38:14 -0700 From: "NewsScan" <newsscanat_private> Subject: Microsoft steamed over Hotmail spam Microsoft has filed a lawsuit against unnamed bulk mailers who harvested the e-mail addresses of Hotmail users in order to bombard them with junk messages. The spammers allegedly used tools to randomly generate e-mail addresses and then tested them to see which accounts were active. Microsoft argues that this form of dictionary attack violates federal laws, including the Computer Fraud and Abuse Act. (*The Register*, 19 Feb 2003; NewsScan Daily, 19 Feb 2003) http://www.theregister.co.uk/content/6/29382.html ------------------------------ Date: Tue, 18 Feb 2003 22:00:39 -0800 From: Chris Adams <chrisat_private> Subject: Deadly input validation? Two teenagers died when their rowboat sank in Long Island Sound on 24 Jan 2003. The 911 operators who took their last-minute phone call have been charged for not handling the call and delaying the search for a day. The story suggests that there may have been some familiar RISKS themes along with the obvious ones: the operator attempted to enter "Long Island Sound" as the location but the software prevented that and, after consulting an equally ill-informed superviser, the operator simply gave up and dropped the call. It sounds like this was a known problem as the official response has been that they should have known to use the address of the nearest police station instead. http://story.news.yahoo.com/news ?tmpl=story&ncid=533&e=9&cid=533&u=/ap/20030218/ap_on_re_us/missing_teens ------------------------------ Date: Fri, 21 Feb 2003 07:13:57 +1100 From: Tony Jones <tmjat_private> Subject: Fire risks A newly-available Web site at <http://www.sentinel.csiro.au/> declares: "Sentinel Fire Mapping is a mapping tool designed to provide timely fire location data to emergency service managers across Australia. The mapping system allows users to identify fire locations that pose a potential risk to communities and property." Unfortunately, recent publicity for the site has generated a burning interest: "Due to heavy demand this Web site is currently experiencing delays. Please be patient and allow priority access to emergency services." ------------------------------ Date: Fri, 21 Feb 2003 10:44:39 EST From: AlMeersat_private Subject: "E-lip" telemarketing phone systems I got a fundraising phone call last week from one of the US political party's campaign fund raising organizations. This alerted me to a new type of phone-calling mechanism that more and more telemarketers are using. While the voice on the other end of the line was human, there were odd pauses between portions of our conversation, a few clicks on the other end of the phone line, and sometimes an odd response to my questions or comments. I realized that I was talking to a machine which was being controlled by a human. Not an "Eliza" like computer program mind you, but a recorded voice mechanism which a human was controlling. Half of the responses were totally appropriate, accurate, and well-delivered, but the rest seemed that "he" was not really listening to me, or had to read from a pre-canned and scripted set of responses. Well, of course that is exactly what was going on. The human telemarketer would be listening to the call, and in response to my questions, comments, and responses, push a button on a computer screen which would then play a prerecorded statement in answer to my query. It was fairly easy to ask a couple of offbeat questions which could only be handled by vague, stiff, and rather useless zombie-like answers. The system can actually be quite useful in many circumstances where the phone operators repeat the exact same answers many times during the day. A live operator can sound bored, angry, distracted, or have a hard to understand accent, where the prerecorded voice is always pleasant, clear, and can even have the same regional or national accent of the caller. These same human controlled computer response "e-lip" systems are not just useful in telemarketing, they can also be useful in phone Customer support environments, at least on the front line calls. And in an Internet "chat" room support environment, one technician could carry on multiple conversations simultaneously, responding by copy&pasting pre-canned text to a screen full of slow typists. In a chat-room environment, the delay in responses would barely be noticed unless the tech was trying to do too many conversations at once. http://sfgate.com/cgi-bin/article.cgi?f=3D/c/a/2003/02/19/LAZ.TMP details a SBS Yahoo tech call with "Floyd" and support.sbcglobal.net/general/contact/ can connect you with "Austin". Both are apparently a form of "e-lip" systems. The risk here is that inappropriate responses from a "known" machine can be tolerated to some extent, but my tolerance level shrunk to almost zero when I realized that I was being "fooled" into thinking I was actually talking with a human. There is a difference between talking WITH a person, and talking AT a person who is responding via a canned-response machine. If I was talking to Stephen Hawking, the machine responses are "normal", but these systems are attempting to fake you out, and those same responses evoked frustration, resentment, and maybe even anger. After playing with the "cyborg machinery" for a few seconds I just hung up. ------------------------------ Date: Thu, 20 Feb 2003 18:01:41 -0000 From: "Nik Smith" <nikat_private> Subject: Web site product serial number validation Ok, I know it's not much of a security issue, but to leave the code in your Web page viewable to see what format the 'valid serial number' should be is just silly. I wanted to download a patch for my lecturer to run a copy of 3dstudio max on XP, and went to www.discreet.com to do this: (Yes, they have licenses, but the software version they use won't work on XP) www.discreet.com/support/max where I was prompted for my name, surname, address, serial number of the product etc in order to obtain the update. After being told I had entered incorrect details persistently, I thought I'd check the source code to see what it wanted. Yep, there it was: function ValidSerial(item) { if (item.length != 12) return false; if (item.indexOf('-') != 3) return false; var i; for (i = 0; i < item.length; i++) { var c = item.charAt(i); if (((c < "0") || (c > "9")) && (i != 3)) return false; } if (item == "226-19791979") return false; if (item == "110-12345678") return false; return true; So, in goes a random number in the format clearly described, and away I go. A valid street name and postal code can be obtained from www.streetmap.co.uk and typing in a random street name, and an e-mail address, should they need to send you an activation code or such like, can be set up at hotmail instantly. The least they could've done is use .asp to hide the code. One easy way to avoid disclosing your personal information to companies you'd rather not have it. Nik, student at BCUC(.ac.uk) ------------------------------ Date: Fri, 31 Jan 2003 18:22:21 -0500 From: "Fuzzy Gorilla" <fuzzygorillaat_private> Subject: Two-digit year field strikes again In Norway, a 106-year-old woman was summoned to start school, and offered free bus rides to the school. The last time she had started school was of course 1903, having been born in '97. "Since I can already read, maybe I should skip a couple grades," she joked. [Source: Associated Press, 31 Jan 2003; PGN-ed] http://news.yahoo.com/news ?tmpl=story2&u=/ap/20030131/ap_on_fe_st/norway_senior_student ------------------------------ Date: Thu, 20 Feb 2003 12:33:12 +0100 From: Jesus Climent <jesus.climentat_private> Subject: Too much tech can kill you As a proof that technology can lead to a dead end, here it goes what happened last winter to my girlfriend and me. While visiting Portugal, in Lisbon, we had to go to the doctor. The medical insurance she is subscribed to allows her to receive medical assistance without any bills, which are sent to the insurance company. For the only purpose of being sure that the carrier of the insurance title the insurance company is asked to send a fax copy of the actual contract. Oh well. That is not as easy as it sounds. When called, the company representative who answered the 24hrs service line said "we don't do faxes anymore. Don't they have an e-mail address?" It happens that in the 24 service hospital we went to, they do not have e-mail. And for that matter, what kind of authentication mechanism both ends would have used to ensure that the sender was who it claimed to be? As seen, early technology adoption with a depreciation of old communication methods is as bad as slow technology adoption. Finally we had to pay the bill. She will probably sue the company ;) Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es ------------------------------ Date: Fri, 21 Feb 2003 10:39:34 -0700 From: "NewsScan" <newsscanat_private> Subject: Lawyers say hackers are getting bum rap The National Association of Criminal Defense Lawyers has joined with the Electronic Frontier Foundation and the Sentencing Project in publishing a position paper that argues people convicted of computer-related crimes tend to receive harsher sentences than perpetrators of comparable non-computer-related offenses. "The serious nature of the offenses is overplayed," says Jennifer Granick, author of the paper and clinical director at Stanford University's Center for Internet and Society. "The (majority) of the offenses are generally disgruntled employees getting back at the employer or trying to make money." In a review of 55 cases prosecuted under the most-often used computer crime statute, only 15 involved harm to the public and only one resulted in a threat to safety. Those convicted "are receiving sentences based on the fear of the worst-case scenario rather than what the case may really be about," says Granick. The paper was submitted in response a request for public comment by the U.S. Sentencing Commission as required by the Homeland Security Act of 2002. Cybercrime legal expert Scott Frewing says he agrees with many points raised in the paper, but recommends a two-tiered sentencing threshold: "I would be comfortable in a situation where the code addresses the discrepancy between those who cause bodily injury and those that don't. If that results in the law being unfair to a virus writer, maybe that's enough to put them on notice." [CNet News.com 20 Feb 2003; NewsScan Daily, 21 February 2003] http://news.com.com/2100-1001-985407.html?tag=fd_top ------------------------------ Date: Wed, 19 Feb 2003 17:25:58 -0800 From: Nicholas Weaver <nweaverat_private> Subject: Re: Playing Russian Roulette with traffic lights (Foster, R-22.57) [Dan Foster said "there is no safe way to deterministically recover" from the failure he described in RISKS-22.57. PGN] Actually, there is a reasonably "safe" automatic recovery procedure for traffic lights to transition from blinking-red to normal operation: Switch to red in all directions for the 10-20 seconds, in order to clear the intersection of those who were crossing in 4-way stop mode. This allows the intersection to clear of traffic before normal operation resumes. You can pick nits on cases where a car ends up being stuck in the intersection after the light resumes normal operation, but those can occur during normal operation as well. [Congratulations to RISKS readers who responded to this one. We received over 100 messages, mostly with content similar to Nicholas's. Many thanks. That sets the all-time RISKS record thus far. CHEERS! PGN] ------------------------------ Date: 28 Jan 2003 19:45:22 GMT From: peterat_private (Peter da Silva) Subject: The fourth solution... (Re: SQL Slammer, RISKS-22.52) > As usual the two most common responses are: > 1. Blame Microsoft for producing code with holes in. > 2. Blame the sysadmins for not patching systems. > [and 3. Nobody blames the anti-social [deleted] who wrote it] My reaction is to blame the sysadmins who exposed a system to the Internet running unhardened applications without minimal firewalls in place. I have one Internet-visible box running SQL server... it's isolated behind a proxy firewall that doesn't allow any connections n or out that aren't specifically required for the application running on top of the database. This is really the appropriate level of protection for an application that's only "LAN tight"... regardless of who wrote the OS or application. I wouldn't demand everyone use a proxy firewall, but I would expect at least as much protection between it and the Internet, and between the inside LAN and it, as there is between the inside LAN and the Internet. But even the elementary precaution of restricting incoming connections to ports and addresses that are known to be required would have been enough to stop this worm in its tracks. ------------------------------ Date: Thu, 20 Feb 2003 07:48:41 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Mike Meyers' Security+ Certification Passport", Trevor Kay BKMMSCRP.RVW 20030207 "Mike Meyers' Security+ Certification Passport", Trevor Kay, 2003, 0-07-222741-9, U$29.99/C$44.95 %A Trevor Kay trevorat_private %C 300 Water Street, Whitby, Ontario L1N 9B6 %D 2003 %G 0-07-222741-9 %I McGraw-Hill Ryerson/Osborne %O U$29.99/C$44.95 800-565-5758 fax: 905-430-5020 %O http://www.amazon.com/exec/obidos/ASIN/0072227419/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0072227419/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0072227419/robsladesin03-20 %P 363 + CD-ROM %T "Mike Meyers' Security+ Certification Passport" Given the organization of the Security+ objectives, part one covers general security concepts and chapter one is on access control. Some factors are dismissed a little bit too concisely: it is difficult to justify the blanket statement that biometric authentication is "extremely accurate and secure." (Biometrics does get a bit more explanation in the chapter on physical security, but there is no indication of that in this location.) For the first set of sample questions, the emphasis is on simple definitions and fact recitation, but later questions do become somewhat more complex. A variety of attacks are described in chapter two, generally reasonably. The virus material is unfortunately poor, concentrating on older viral technologies (such as the almost extinct boot sector viruses and older DOS precedence-based companions) and failing to provide proper outlines of the basic antivirus technologies. Part two looks at communications security. Chapter three deals with remote access, but the content has limited application to security. Technologies related to Internet application security are reviewed in chapter four. The highlights are touched on, but the lack of detail can be troubling. Cookies are discussed, with some mention of privacy, but the potential problem of cross-site tracking is not dealt with at all, and neither is the danger of HTML (HyperText Markup Language) formatted messages when the topic turns to e-mail. The material on wireless networking and security, in chapter five, is very weak. The explanation of direct-sequence spread spectrum is not clear at all, a mention of SSL (Secure Sockets Layer) makes no reference to the description in the previous chapter (and almost contradicts it), and security itself gets short shrift in the haste to trot out the alphabet soup of related technologies. Part three deals with infrastructure security. Chapter six runs through a list of networking components, cabling, and storage media, again with limited allusion to security. Network topologies and intrusion detection systems are discussed in chapter seven. System hardening, generally by applying patches and disabling functions, is reviewed in chapter eight. Cryptography is in part four. Most of the basic content in chapter nine is sensible, but it is clear from the paragraphs on double- and triple-DES (Data Encryption Standard) that the author does not fully understand the subject. Chapter ten reviews key management, but it is not clear why the topic was separated from that of PKI (Public Key Infrastructure). Part five deals with operational and organizational security. Physical security, in chapter eleven, is covered fairly well. Disaster recovery is confined to backups and fault tolerance: chapter twelve supports Kenneth Myers contention (cf. BKMGTCPD.RVW) that most people concentrate on recovering technology rather than the business, and would be improved by a broader view that incorporated all aspects of the operation. Chapter thirteen lists some areas that should be covered in a security policy. Forensics is dealt with poorly, and chapter fourteen also throws in education and training. While the book still adheres, rather slavishly, to the arbitrary structure of the Security+ list of objectives, the content is generally pretty reasonable, providing background explanations for important concepts, and keeping the descriptions of many of the specific technologies limited to the fundamental ideas. The text does tend to be terse, given the size of the book, but most basic material should be available to the student. This does vary by chapter: some seem to be merely going through the motions. The work could be improved with some removal of duplicated material. For example, there are three separate discussions of social engineering, and two could be replaced with cross-references. Despite its smaller size, I would recommend this volume over the Syngress "Security+ Study Guide and DVD Training System" (cf. BKSCRTYP.RVW), but not emphatically. copyright, Robert M. Slade, 2003 BKMMSCRP.RVW 20030207 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 29 Mar 2002 (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 Majordomo balks when you send your accept, please forward to risks. [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. .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 21" for volume 21] 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 22.58 ************************
This archive was generated by hypermail 2b30 : Fri Feb 21 2003 - 16:52:25 PST