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 http://www.risks.org as http://catless.ncl.ac.uk/Risks/22.92.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: Near-disaster on a French commuter train (Alexandre Kampouris) Nuclear reactor guard asleep on the job (Ken Knowlton) Houston 911 System prone to crashes (Mark H. Johnson) Continental Airlines takes back free miles (Frank) Overlooked security risk: the telephone (NewsScan) Parking chaos in York (David Wj Stringer-Calvert) Torvalds: geeky kids need dates (NewsScan) Computer blamed for bad pictures shown to Mexico's first lady (Mark Lutton) Spam Abounds (Peter G. Neumann) Fighting spam: raise the bridge or lower the water? (NewsScan) VeriSign agrees to suspend Site Finder service (NewsScan) Purveyor of unencrypted service insists it's secure (Alice Silverberg) Another case of electronic vote-tampering? (Farhad Manjoo via Monty Solomon) AntiVirus autoresponders (Rob Slade) REVIEW: "Intrusion Signatures and Analysis", Stephen Northcutt et al. (Rob Slade) Rebuttal of review of my book by Rob Slade (Michael Caloyannides) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 22 Sep 2003 18:10:46 +0200 From: Alexandre Kampouris <ak@Radio-BIP.qc.ca> Subject: Near-disaster on a French commuter train On Saturday September 20th, a disaster was miraculously averted when a RER suburban train stopped around 7:30 PM between stations near Villeneuve-Triage south of Paris due to equipment failure. According to the preliminary reports, the engineer, who is the only staff member on board, is said to have instructed the passengers over the PA system to alight the train on the left side, and walk to the next station. However it appears that the doors where only open on the right side; the passengers simply started walking on the second track. For a reason yet to be determined the traffic hadn't been interrupted in the other direction, and an oncoming train narrowly missed the myriads of passengers in its path, who by sheer luck escaped death or serious injury by throwing themselves to the ground or jumping aside. An enquiry is underway. Even though the exact chain of events is yet to be established, there seems to be at least two system failures, i.e., (1) the doors opening on the wrong side, and (2) the non-secured track. The frightening event was recorded on video. http://infos.francetv.fr/semiStatic/64-NIL-NIL-259414.html http://www.leparisien.com/home/info/faitsdivers/article.htm?articleid=210899112 ------------------------------ Date: Sun, 28 Sep 2003 14:37:07 EDT From: KCKnowlton@private Subject: Nuclear reactor guard asleep on the job [Quoted from *The New York Times*, Metro Section, 28 Sep 2003, pg 43, by Matthew L. Wald] When two Nuclear Regulatory Commission officials found a security guard asleep at his post at the Indian Point 2 nuclear reactor last year, the agency decided not to issue a notice of violation because there was no terrorist attack on the plant during the half-hour or so that the guard was sleeping, a Congressional audit has found. ... The report also says the commission did not treat the incident more seriously because no guards had been found sleeping "more than twice during the past year." There was no comment in the story (or in the NRC report?) about sleeping behavior of those who deal with knobs, dials, monitors and keyboards. An interesting general philosophical attitude: post-hoc shrugs for all infractions that had no catastrophic consequences. ------------------------------ Date: Fri, 3 Oct 2003 08:39:55 -0500 From: Mark_H_Johnson@private Subject: Houston 911 System prone to crashes To summarize - Houston has deployed a new 911 emergency response system which has had a number of failures since it went "live" a week ago. Pictures of the new facility look somewhat like Mission Control - large consoles with multiple displays in front of each operator. It sure looks nice, but the system does not appear to work reliably. The latest incident occurred during the day when technicians were working on the link between the computers and units within the cars. To quote: When the system started slowing, technicians reverted to the backup, which crashed within minutes. From 9:50 a.m. to 10:30 a.m., dispatchers resorted to dispatching by radio instead of by computer. Without the computer's locator system, they frequently had to ask emergency workers to volunteer for individual assignments rather than assigning them to calls. Another notable quote is But city officials say the only way to test the system was by going "live." Sorry, but that does not sound reasonable to me. For reference: http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2133809 http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2134381 http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2127855 http://www.click2houston.com/editorials/2522205/detail.html [May not all be permanent...] ------------------------------ Date: Thu, 18 Sep 2003 22:28:45 -0500 (GMT-05:00) From: frank099@private Subject: Continental Airlines takes back free miles Last week, I checked my Continental Airlines OnePass frequent flyer account and discovered that my account had been credited with 500,000 bonus miles, allegedly because I won a contest. It turns out that thousands of other people were "winners" as well, with some having a million or more frequent flyer miles added to their accounts. The miles didn't last long and were removed a few days later. However, many people had booked trips with those free miles, which Continental quickly canceled. http://www.usatoday.com/travel/news/2003/09/15-airmiles.htm ------------------------------ Date: Thu, 02 Oct 2003 09:28:34 -0700 From: "NewsScan" <newsscan@private> Subject: Overlooked security risk: the telephone As corporate phone systems become increasingly complex and computerized, criminals are finding new ways to infiltrate company networks, and the problem becomes magnified as businesses turn to IP-based phone systems. "This is the first time that a computer virus can stop your telephones from working," says PricewaterhouseCoopers senior manager Mark Lobel. "There is a whole new class of attacks that can occur. The essence of the problem is that everyone is looking at this as a new technology for voice -- the way we're sending voice communications is absolutely new. But the data is still riding on the same infrastructure that was pounded by recent problems like SoBig." To counteract the threats, phone system administrators need to be much more vigilant about password management and may even consider locking out certain country codes. "In fact, you should probably consider the risk associated with VoIP systems to be as high as the threats to your organization's most sensitive data. If someone in your IT department gets paged when your firewall goes down, they should also be paged when 40 new voicemail boxes mysteriously appear on your IP system," says Lobel. [*E-Commerce Times*, 2 Oct 2003; NewsScan Daily, 2 Oct 2003] http://www.ecommercetimes.com/perl/story/31731.html ------------------------------ Date: Mon, 06 Oct 2003 11:41:08 -0700 From: "David Wj Stringer-Calvert" <david.stringer-calvert@private> Subject: Parking chaos in York The system controlling York's newly installed intelligent traffic variable-message signs (VMS) were hit by a computer virus on 4 Oct 2003, freezing 21 VMS displays at car parks that were intended to show the number of available parking space. Motorists thus went into full car parks expecting to find space. One VMS at St George's Field showed 349 spaces when there were *none*, causing an enormous traffic tie-up. [And no one was around to slay St George's draggin' congestion.] A similar problem had occurred in August. (The system, costing 1.5 million pounds, began operation in July 2003. The software is provided by Tennet and the hardware by Variable Message. A temporary fix is sought to enable the VMSs to be blanked out if this happens again. [Source: `Frozen' signs lead to car park chaos, by Rosslyn Snow, *Yorkshire Evening Press*, 6 Oct 2003; PGN-ed] ------------------------------ Date: Mon, 29 Sep 2003 14:17:45 -0700 From: "NewsScan" <newsscan@private> Subject: Torvalds: geeky kids need dates Asked how to end virus and worm attacks, Linux creator Linus Torvalds told an interviewer: "When you have people who hook up these machines that weren't designed for the Internet, and they don't even want to know about all the intricacies of network security, what can you expect? We get what we have now: a system that can be brought down by a teenager with too much time on his hands. Should we blame the teenager? Sure, we can point the finger at him and say, 'Bad boy!' and slap him for it. Will that actually fix anything? No. The next geeky kid frustrated about not getting a date on Saturday night will come along and do the same thing without really understanding the consequences. So either we should make it a law that all geeks have dates -- I'd have supported such a law when I was a teenager -- or the blame is really on the companies who sell and install the systems that are quite that fragile." [*The New York Times Magazine*, 28 Sep 2003; NewsScan Daily, 29 Sep 2003] http://partners.nytimes.com/2003/09/28/magazine/WLN104109.html ------------------------------ Date: Wed, 1 Oct 2003 10:18:00 -0400 From: "Mark Lutton" <Mark.Lutton@private> Subject: Computer blamed for bad pictures shown to Mexico's first lady The wife of Mexican President Vicente Fox is a staunch defender of family values. Attending a charity presentation dedicated to helping children with cancer, she viewed a picture of a naked man and woman together that was somehow inadvertently included among the slides. A "technical error" is blamed. [Source: Mexico's prim first lady gets eyeful of nudes, Reuters, 1 Oct 2003] http://www.reuters.co.uk/newsArticle.jhtml?type=oddlyEnoughNews&storyID=3536434 [Let's see if this issue gets spam-filtered. PGN] ------------------------------ Date: Fri, 3 Oct 2003 10:34:42 PDT From: "Peter G. Neumann" <neumann@private> Subject: Spam Abounds Unfiltered spam has once again taken a quantum leap. The latest version of SpamAssassin catches about 1000 spams per day on e-mail between Neumann and RISKS. However, even after SpamAssassin does its job, RISKS is still getting about 90% spam from the residual mail. In other words, I have to delete almost all of the incoming mail to RISKS. My own mail is only somewhat less offensive. (And I have been away, which makes it ever more difficult to keep up. I regret the long gap between issues, and my inability to cope with the backlog in the past weeks. PLEASE resubmit any really salient items that you felt I might have missed. I need a salient solution to help overcoming being as-salted.) Spam is evermore not your friend. ------------------------------ Date: Mon, 06 Oct 2003 09:46:36 -0700 From: "NewsScan" <newsscan@private> Subject: Fighting spam: raise the bridge or lower the water? Many software experts now believe that the best way to fight spam is not by targeting it directly but instead by concentrating on the identification of legitimate mail. VeriSign executive Nico Popp explains, "People have been spending all their time creating filters to find the bad guys. We want to turn that on its head and find ways to identify the good guys and let them in." The idea would be to develop the Internet equivalent of caller ID, with a technology that identifies senders and lets receivers presume that unidentified senders are sending junk mail. Richard Reichgut of AuthentiDate says, "It's not easy to change something as successful and widely used as e-mail. But the only way to fix e-mail is to have a strong way to know who is sending you mail." [*The New York Times*, 6 Oct 2003; NewsScan Daily, 6 Oct 2003] http://partners.nytimes.com/2003/10/06/technology/06SPAM.html [Once again, see Lauren Weinstein's Tripoli proposal -- http://www.pfir.org/tripoli-overview -- which is a sensible approach to giving users control over how to confront the e-mail dilemma. BEWARE of ceding this authority to ISPs! PGN] [Also, see "Four Internet pioneers discuss the sorry state of online communication today. The consensus: It's a real mess." by Katharine Mieszkowski, Salon.com: http://www.salon.com/tech/feature/2003/10/02/e_mail/ She quotes Dave Farber, Dave Crocker, Brad Templeton, and Jakob Nielsen. PGN] ------------------------------ Date: Mon, 06 Oct 2003 09:46:36 -0700 From: "NewsScan" <newsscan@private> Subject: VeriSign agrees to suspend Site Finder service VeriSign and ICANN reached a temporary truce Friday, with VeriSign acquiescing to ICANN's demand that it suspend its controversial Site Finder service pending further technical review. ICANN could have fined VeriSign as much as $100,000 or even revoked its contract to manage the master list of .com and .net Internet domain names. Critics have charged VeriSign with undermining the collectivist culture of the Internet with the preemptive launch of its service, which redirects Web users who mistype a URL to the VeriSign Web site. "In the past when you made a dramatic change to the network structure that was the least bit potentially damaging, you went out through the community and you exposed what you were going to do and got reaction," says Carnegie Mellon computer science professor David Farber. VeriSign "just broke the whole process." In its defense, VeriSign executives say they notified ICANN of their plans ahead of time, but admitted that they sidestepped ICANN's lengthy approval process because it's too slow. In response, ICANN says it's "sympathetic to concerns" about its process and has proposed a more streamlined procedure for reviewing new services such as Site Finder. [*Wall Street Journal*, 6 Oct 2003; NewsScan Daily, 6 Oct 2003] http://online.wsj.com/article/0,,SB106519977252395300,00.html (sub req'd) [This is after VeriSign told ICANN to drop dead: See the correspondence http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm and Dan Gillmor's column in response: http://weblog.siliconvalley.com/column/dangillmor/archives/001361.shtml noted courtesy of Dave Farber's IP. PGN] ------------------------------ Date: Fri, 3 Oct 2003 15:21:02 -0700 From: Alice Silverberg <alice.silverberg@private> Subject: Purveyor of unencrypted service insists it's secure Here's a hotel reservation url that expects you to send your credit-card information unencrypted (though when you phone the associated number to ask about it, they insist that it's secure): http://www.innsuites.com/ ------------------------------ Date: Sun, 5 Oct 2003 13:20:43 -0400 From: Monty Solomon <monty@private> Subject: Another case of electronic vote-tampering? (Farhad Manjoo) Another case of electronic vote-tampering? Representatives of the computer vote-counting industry are unfairly dominating the standard-setting process, say critics. By Farhad Manjoo, Salon.com, 29 Sep 2003 When the IEEE, the world's leading professional society of engineeers, decided in the summer of 2001 to create a technical standard for electronic voting machines, most everyone concerned with the elections business thought it was a grand idea. For the most part, the IEEE operates just as you'd expect a bunch of engineers to behave -- the group is rigorous, open-minded, dispassionate, and reluctant to embark upon any major endeavor unless everyone with an opinion has had an opportunity to hold forth. "Consensus" is the IEEE's main buzzword; and while that ethic can lead to some frustration, it also explains why so many industries and government agencies ask the IEEE to draw up technical standards for new technologies. People trust the IEEE's open process, and when it sets down certain specifications -- governing everything from aircraft gyros to wireless networks -- the specs are widely respected by technologists. And by the summer of 2001, a standard for voting machines was clearly needed. After the hobbled 2000 presidential election, officials across the nation were rushing to purchase new equipment to replace their maligned punch-card systems. Elections vendors were heavily promoting fully electronic, ATM-style touch-screen voting machines, but many computer scientists warned -- and are warning still -- of critical security flaws in such systems. The key players in the debate over electronic voting saw the IEEE as a good place to resolve concerns people had with the new systems; they hoped that after hearing all sides, the vaunted body could create respected technical guidelines for the machinery of modern democracy. Two years later, however, the IEEE group charged with drafting a voting machine standard is paralyzed by bitter in-fighting. Members of the body can't agree on the substance of a proposed standard for voting machines, nor can they even come to a consensus on a fair process for determining such a standard. The parties involved are arguing about big things -- about whether, for instance, electronic voting machines should be required to produce a "voter-verifiable" audit trail, which many security experts say is the only way to guarantee security in electronic systems -- and tiny things, such as the order in which topics are discussed in the meetings they hold. To hear members of the committee tell it, the whole process has become a circus -- a circus that illustrates how difficult it might be to eventually create a national standard for voting systems. [...] http://www.salon.com/tech/feature/2003/09/29/voting_machine_standards/ ------------------------------ Date: Sun, 5 Oct 2003 13:35:27 -0800 From: Rob Slade <rslade@private> Subject: AntiVirus autoresponders I notice the NTBUGTRAQ seems to have added to following as a sigblock to all messages: "Most viruses these days use spoofed e-mail addresses. As such, using an AntiVirus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered." Note once again that variations may occur. The infected user may be identified in Swen infected messages by the Return-Path header. Frequently the infected user's mailbox has been filled and is over quota, so the postmaster, abuse, and possibly support accounts should be notified as well. (The abuse and support I accounts that I have contacted who have taken the time to investigate have confirmed that users identified in the Return=Path headers are infected.) rslade@private slade@private rslade@private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 1 Oct 2003 07:54:59 -0800 From: Rob Slade <rslade@private> Subject: REVIEW: "Intrusion Signatures and Analysis", Stephen Northcutt et al. BKINSIAN.RVW 20030831 "Intrusion Signatures and Analysis", Stephen Northcutt et al, 2001, 0-7357-1063-5, U$39.99/C$59.95/UK#30.99 %A Stephen Northcutt stephen@private %A Mark Cooper %A Matt Fearnow %A Karen Frederick %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2001 %G 0-7357-1063-5 %I Macmillan Computer Publishing (MCP) %O U$39.99/C$59.95/UK#30.99 800-858-7674 info@private %O http://www.amazon.com/exec/obidos/ASIN/0735710635/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0735710635/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0735710635/robsladesin03-20 %P 408 p. %T "Intrusion Signatures and Analysis" Intrusion detection and network forensics are now vitally important topics in the security arena. An explanation of how to identify dangerous signatures, and extract evidence of an intrusion or attack from network logs, is something that most network administrators require. Unfortunately, while the idea is good, and badly needed, the execution, in the case of the current work, is seriously flawed. The introduction doesn't really specify a purpose or audience for this book. Mention is made of the GIAC (Global Incident Analysis Center, also seemingly referred to at times as the GCIA) certification, but no definition is given as to what this actually is. Chapter one presents a number of examples of network log entries and formats. The interpretation, though, concentrates on easily identifiable items such as IP addresses, and neglects components that are less well known. There seems to be some attempt to structure the descriptions, but it is unclear and confusing, as are a number of the illustrations and figures. Chapters three and four list a "top ten" of specific attacks, described down to a byte level, but not always in clear detail. Perimeter logs, such as those from firewalls and routers, are discussed in chapter six. Restraint in reaction to odd traffic is urged in chapter seven, particularly in light of the probability of address spoofing. Chapter eight outlines packets that indicate mapping scans, while nine does the same with searches that might be gathering system information. Denial of services attacks are reviewed in chapters ten and eleven, first with respect to attacks that attempt to exhaust specific resources, and then in regard to bandwidth consumption. Chapter twelve discusses trojan programs, concentrating on detection of unusual open ports. Miscellaneous exploits are listed in chapter thirteen, but since exploits are listed throughout the previous three chapters it is difficult to find a distinctive for this section. Fragmentation attacks are described in chapter fifteen. Chapter sixteen reports on some odd looking non-malicious packets, in warning against reacting to false positives. A grab bag of odd packets is listed in chapter seventeen. As should be evident from the description above, there is a good deal of valuable material in this book. Unfortunately, it is not easy to extract the useful bits. The book as a whole could use serious reorganization. While chapter one appears to be an introduction to the technical details, a far better explanation of packets and the import of various fields is given in chapter five, ostensibly on non- malicious or normal traffic, and this material should probably have been placed at the beginning of the manual. Chapter fourteen, almost at the end of the text, reviews buffer overflows, which are seen throughout the chapters preceding it. There is a slight attempt to explain the book in chapter two, but the content and organization is perplexing, there is heavy use of unilluminated insider jargon, and the presentation of example packets and subsequent conclusions without the middle step of identifying the items that make these data suspicious could be quite frustrating to the student. The new system administrator will not find the explanations clear or illuminating. The experienced professional will not find particular attacks or traffic types easy to find for reference. Both groups will find themselves flipping back and forth between sections of the book, or even between sections of the exegesis of one particular attack. However, both groups will likely be interested in the book anyway, simply because of the lack of other sources. copyright Robert M. Slade, 2003 BKINSIAN.RVW 20030831 rslade@private slade@private rslade@private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 01 Oct 2003 16:00:23 -0400 From: Michael Caloyannides <Michael.Caloyannides@private> Subject: Rebuttal of review of my book by Rob Slade (RISKS-22.90) In his 9 Sep 2003 review of the book "Desktop Witness", 0-471-48657-4, Rob Slade made numerous factually incorrect statements that your readers are likely to be mislead by. A careful reading of the book would have shown that reviewer that steganography using conventional software is explicitly discouraged (rather than encouraged as he incorrectly claims) in the book precisely because it is detectable through steganalysis tools that look for statistical irregularities in the composite file; a careful reading of that same section would have shown the reviewer -- and anyone else -- that the book then proceeds to show that unconventional steganography is inherently undetectable because there is a multiple infinity of ways to imbed a hidden meaning in an overt act, especially if it used rarely and if the ratio of covert to overt message is low. Who can credibly detect a steganographic content in a recipe for lasagna posted in some Usent newsgroup, or in the presence of an occasional spelling error or in a graphic included in an otherwise professional document? As with the steganography example, so with the rest of the points he raises; his objections are based on a superficial reading of the book he reviewed that missed the points discussed in that book. For example, he sets the biased tone of his review by postulating an inconsistency in the title and subtitle of the book ("Desktop Witness". The Dos and Don'ts of Personal Computer Security), when it is quite clear that there is no such inconsistency because the book provides "the dos and dont's of personal computer security" so that one's desktop computer will not end up being used as a witness against one. Worse yet, his review is repeatedly tainted with his religious objection to the fundamental premise of the book which is that honorable civilized people have a right to their privacy. While Mr. Slade's religious background, which includes a degree in Christian Science, is his own business, it is allowed to distort what should have been a factual review with his own value judgments. One reads, for example, in his review his assertion that the book's reasoned arguments in support of individual privacy are "shrill", "extreme" or "paranoid". These oddly emotional words in a supposedly detached review are at best suspect, given the fact that: a) According to the FBI, roughly 1 in 20 Americans has been the victim of identity theft, and the trend is increasing at an alarming rate. b) There is a huge and healthy debate today about the extent to which individual privacy and the Bill of Rights should be sacrificed in the post 9/11 world. For a balanced review of the same book by a University professor in the UK, your readers may also wish to read http://www.newscientist.com/opinion/opbooks.jsp?id=ns23486 This book, by the way, is used in a number of Universities for training students in computer science as well as in law. ------------------------------ Date: 30 May 2003 (LAST-MODIFIED) From: RISKS-request@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-request@private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@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.Marshall@private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => 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 risks@private with meaningful SUBJECT: line. => ARCHIVES: http://www.sri.com/risks http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] Lindsay 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.92 ************************
This archive was generated by hypermail 2b30 : Mon Oct 06 2003 - 15:17:59 PDT