precedence: bulk Subject: Risks Digest 20.97 RISKS-LIST: Risks-Forum Digest Thursday 27 July 2000 Volume 20 : Issue 97 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 and by anonymous ftp at ftp.sri.com, cd risks . ***** FLASH NOTE: The catless archive copy of RISKS-20.96 is temporarily **** ***** truncated, and Lindsay Marshall has been unavailable to fix it. ****** ***** Please use alternative sources at SRI or the.wiretapped.net (below). ** Contents: House hearing on FBI's "Carnivore" (Alan Davidson) Fake Paypal site collects user ids and passwords (Avi Rubin) Followup on cause of SeaLaunch rocket failure (Kenneth Basye) Outlook bug allows self-executing Trojan horses (Kevin Poulsen) Powergen: More credit-card info exposed (Ursula Martin) Civilian payroll problem (Stan Niles) The Least Mail Online (Rob Slade) AT&T exposes account info (John Chapin) Re: Sliced fiber-optic cable ... (Mark Richards) Re: London Underground magnetic ticket bug (Clive D.W. Feather) Trust and Risk in Internet Commerce, Jean Camp (PGN) 9th USENIX Security Conference 2000 (Hali McGrath) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 26 Jul 2000 23:04:40 -0400 From: Alan Davidson Subject: House hearing on FBI's "Carnivore" [Written by Lina Tilman ] Oversight Hearing on Fourth Amendment Issues Raised by FBI's "Carnivore" Program Subcommittee on the Constitution, House Committee on the Judiciary Monday, July 24, 2000, 1:00 p.m. Chairman Canady opened the hearing by introducing the Carnivore system as one that "isolates, intercepts and collects" information that passes through an ISP. Canady expressed hope that evaluations of the system would be based on facts instead of "irrational fears and suspicions". Canady concluded by acknowledging the potential for abuse of the system as a significant concern. Rep. Watt briefly addressed his concern regarding Big Brother in general and the government's ability to invade citizens' privacy in particular. Watt acknowledged that such ability has been enhanced by advancements in information and communication technologies. Rep. Hyde first noted the legitimate need of the law enforcement to access information required for criminal investigations. Hyde then described the tension between such necessary access and the citizens' right to the "valuable commodity" of privacy. Rep. Conyers introduced a number of questions as part of his inquiry into Carnivore's ability to "bite more than it can chew". Conyers first noted his concern regarding the applicability of the pen register authority, under which Carnivore collects transactional electronic data, to the online environment. Conyers' other concerns included the FBI's refusal to allow ISPs themselves to deliver the necessary information once a lawful order is obtained. Rep. Hutchinson stated that while Carnivore appeared to be a minimization tool, there exist legitimate questions regarding its application. Concerns include proper monitoring of Carnivore's collection and filtering of e-mail communication. Hutchinson mentioned the Privacy Commission bill, which he co-sponsors with Rep. Moran, as an attempt to establish a body of experts who would, among other things, examine the data collection practices of law enforcement to determine whether they violate the privacy rights of the U.S. citizens. Rep. Bachus stated that in Carnivore's case, technology appears to have "outrun the law". Bachus expressed his suspicion that criminals would easily evade the system and it would exclusively monitor the communications of law abiding citizens. Bachus further expressed his concern regarding illegitimate access to confidential files within agencies such as the FBI. The first panel consisted of Dr. Donald Kerr, FBI lab director, Larry Parkinson, FBI General Counsel, Kevin DiGregory, DOJ and David Green, DOJ. Dr. Kerr introduced FBI's Carnivore as a tool, analogous to a "packet sniffer", of lawful interception of criminal communication. After being installed on a network pursuant to a court order, Carnivore collects the transactional information of its targets' e-mails; its configuration and filter settings depend on the specifics of the court order. Carnivore conducts neither broad searches nor long-term surveillance; instead, it filters out all content information and stores only the non-content "to" and "from" lines of targeted communication. Carnivore is passive on the network and is used only by a technical team of the law enforcement; in its two years of existence, it has been used very infrequently and narrowly. Dr. Kerr concluded by stating that the FBI presently plans an independent review of the system by industry and academic experts. Mr. Parkinson testified that Carnivore is a minimization tool that operates under substantial oversight. Mr. DiGregory, in turn, argued that Carnivore is equivalent to other simple investigative tools that law enforcement uses offline. Chairman Canady asked whether Carnivore captures the URLs of communications with Web sites. The panelists answered that it does not, unless a URL is included in the transactional information of an e-mail. Rep. Watt appeared upset that independent review was scheduled after Carnivore has been in use for two years. A number of Members expressed distrust regarding the law enforcement's use of Carnivore under described limitations. Rep. Hutchinson asked whether the FBI has ever captured content that it then had to filter out. The panelists answered that it has not. Panelists noted that in addition to restrictions and specifications that limit data collection prior to Carnivore's activation, there exist safeguards on law enforcement's use of collected data when it is first examined and, later, at trial. The second panel consisted of Barry Steinhardt, ACLU, Alan Davidson, CDT, Tom Perrine, Pacific Institute for Computer Security, Robert Corn-Revere, Hogan & Hartson, Matt Blaze, AT&T Labs, Stewart Baker, Steptoe & Johnson, and William Sachs, ICONN. Mr. Steinhardt stated that Carnivore is an unprecedented maximization tool that has the potential to access all communications that pass through an ISP. Mr. Steinhardt analogized Carnivore to a digital wiretap, expressing concern that its broad access is inconsistent with restrictions set by the Fourth Amendment and the ECPA. Mr. Steinhardt noted that the FBI has a "checkered past" with regards to First and Fourth Amendment violations. Mr. Davidson addressed the differences between transactional data in the on- and off-line environments, noting that off-line Fourth Amendment protections do not neatly translate into online communications. Davidson showed a series of slides that displayed sample packets that Carnivore could obtain; he argued that "non-content" data that Carnivore currently accesses under a pen register or trap and trace authorization reveal a great amount the actual content of a target's communication. Davidson argued that Congress must increase statutory protections for electronic communications, raising the Carnivore authorization standard from relevant to probable cause. Mr. Perrine noted that Carnivore is technically capable of monitoring all traffic that passes through the network. Mr. Perrine spoke about the inapplicability of telephony concepts to the online environment. He stated that the FBI's use of Carnivore lacks accountability, noting that it is impossible to monitor the system or keep track of its configurations or filters without the knowledge of its source code. Mr. Perrine argued that Carnivore represents a threat to privacy that is protected under original wiretap legislation. Mr. Corn-Revere argued against a number of points brought up by government witnesses on the first panel. Mr. Corn-Revere appeared skeptical that the FBI would use Carnivore's capabilities in limited ways that protect individuals' privacy. He noted disconcerting implications inherent in the system's ability to switch its level of surveillance. In conclusion, Mr. Corn-Revere stated that there presently exists no way to ensure accountability of FBI's use of Carnivore. Mr. Blaze argued that while the FBI operates with good intentions, it is difficult to ensure that Carnivore operates as intended. The system may inadequately filter, target the wrong individual or extract pieces of communication out of context. Mr. Blaze noted that large-scale systems such as Carnivore are problematic and tend to fail silently -- without operators' knowledge -- due to bugs, vulnerabilities and mistakes. Mr. Blaze argued that widespread publication of Carnivore's source code and architecture is the best way to ensure its soundness. [See http://www.crypto.com/papers/openwiretap.html; PGN] Mr. Baker stated that communication concepts from the telephony world do not apply to electronic communication. Mr. Baker argued that it is "crazy" and "bizarre" not to acknowledge that there exists a reasonable expectation of privacy in the content-revealing "to" and "from" lines of an e-mail. He urged the Members to institute a notice requirement when a system such as Carnivore monitors e-mail communications. Mr. Sachs testified that ISPs are capable of providing the FBI with requested communications when a lawful order exists. He noted that Carnivore represents the most intrusive method of obtaining transactional data of e-mail messages. Mr. Sachs acknowledged that albeit technically feasible, such monitoring by an ISP discourages free online communication, protected by the First Amendment, and slows down network traffic. During the Q&A period, Davidson noted that little is known about Carnivore's precise capabilities and functions. Rep. Watt expressed concern that currently available Carnivore-like electronic surveillance systems allow anyone to monitor online traffic. Panelists noted that there exists an a-priori legal issue with the FBI's installation of Carnivore -- in the telephony world, the FBI would not be able to install, on a telephone service provider's network, a device that would monitor all passing communications. Panelists and Members appeared to agree that there must exist a notice requirement; presently, notice depends on the individual ISPs' policies. Davidson argued that two things must occur: (1) the standard for access to transactional data on the Internet must be raised, and (2) "trap and trace" must be re-defined for the online environment. Mr. Perrine noted that according to the Supreme Court, transactional data may not disclose the target's identity. Mr. Steinhardt observed that the FBI witnesses addressed the use of Carnivore in the e-mail context only; it remains unclear how the system monitors files transferred using other protocols. Furthermore, it is unclear what statutory protections govern such file transfers. Mr. Steinhardt argued that the notion and significance of non-content data has changed since CALEA was adopted, and urged the Members to consider two changes to existing surveillance guidelines: (1) judges should be given discretion in matters of online pen register and trap and trace orders, and (2) the standard for obtaining a pen register and trap and trace must be raised for both the online and the telephony environments. Lina Tilman, Center for Democracy and Technology 1634 Eye St. NW Suite 1100, Washington, DC 20006 202 637 9800 fax 202 637 0968 ltilman@cdtmail.org http://www.cdt.org/ [From EPIC Alert 7.14, 27 Jul 2000, http://www.epic.org, I find Testimony presented at the House Judiciary Committee hearing: http://www.house.gov/judiciary/2.htm The hearing can be viewed in its entirety over the web at: http://www.cspan.org/technology_science/ More on the history of FBI monitoring of Internet communications and the "digital telephony" law (or CALEA) is available at the EPIC Wiretap Page: http://www.epic.org/privacy/wiretap/ PGN] ------------------------------ Date: Tue, 25 Jul 2000 15:23:18 GMT From: rubin@research.att.com (Avi Rubin) Subject: Fake Paypal site collects user ids and passwords Somebody in the Ukraine registered PayPaI.com (note the resemblance to PayPal, especially with the upper-case I [in some fonts]), then copied Paypal's HTML and sent mail to a bunch of paypal users saying 'J. Random has just transferred $827 to you using PayPal, log in at http://www.paypaI.com/ to claim it!' of course, as soon as you "logged in" your password was mailed to some free e-mail service. For more on the story see http://www.msnbc.com/news/435937.asp?cp1=1 among other places. Avi http://avirubin.com/ [Monty Solomon notes that Paypai.com is registered to Birykov Inc. in South Ural, Russia, according to MSNBC: http://www.msnbc.com/news/435937.asp PGN] ------------------------------ Date: Thu, 27 Jul 2000 15:45:22 -0400 From: Kenneth_Basye@dragonsys.com Subject: Followup on cause of SeaLaunch rocket failure (RISKS-20.84) According to an article at space.com, the cause of the failure in March was "a single line of code" which allowed the rocket to be launched with a valve open in the second stage, setting the stage (sorry) for a helium leak. SeaLaunch is preparing for another launch tomorrow (July 28th). (http://www.space.com/missionlaunches/sea_launch_000714.html) Ken Basye ------------------------------ Date: Wed, 19 Jul 2000 21:09:06 -0700 (PDT) From: Kevin Poulsen Subject: Outlook bug allows self-executing Trojan horses http://www.securityfocus.com/news/62 A newly discovered vulnerability in Microsoft's Outlook and Outlook Express programs leave thousands of computers open to attack from malicious e-mail, and puts the lie to the conventional wisdom that you can't get a computer virus if you don't open attachments. Microsoft issued an advisory on the bug Wednesday morning, after a programmer announced it to the world over the Bugtraq mailing list Tuesday. In the advisory, Microsoft says Outlook users can eliminate the vulnerability by upgrading to Internet Explorer 5.01 Service Pack 1, or, Explorer 5.5. Either upgrade will patch the hole on Windows 95, 98 or NT. Windows 2000 users must install the Service Pack to close the hole. The bug is a classic "buffer overflow" error in the section of Outlook that parses the Date field of each incoming e-mail. By padding the date with a long string of characters, an attacker can escape from the area of memory reserved for storing it, and into a section that executes instructions. From there, the attacker's e-mail could secretly infect a victim computer with a "back door" program like Back Orifice, or instruct it to send the offending e-mail back out to the net like the LoveLetter virus. The vulnerability doesn't require any attachment to the e-mail; Outlook users need only read a message to be hit. Outlook Express users are even more vulnerable, and can fall prey to malicious code without reading the message, or even being at their computer when it comes in. "This has the potential to be the worst one we've seen yet," said Brian Martin, a senior security engineer at Maryland-based Digital Systems International Corporation. "If this can execute as soon as the mail is received, oh man, that's just perfect." Based on a hurried analysis Tuesday night, Martin said that the bug could likely be used to take control of vast numbers of machines at a time. "What if you had a mail list with thousands of people and you posted to that?," said Martin. "One well-placed e-mail and you can probably infect thousands of people with a Back Orifice or a NetBus." Aaron Drew announced the bug to the Bugtraq mailing list on Tuesday, along with code that ostensibly demonstrates the hole. MSNBC reported that the hole was also discovered over a month ago by researchers at USSR Labs, which also boasts working exploit code. Both the news service and the security group kept it a secret while awaiting a Microsoft fix. The Microsoft advisory credits USSR Labs for reporting the bug to them, "and working with us to protect customers." Outlook's vulnerability to running malicious code without any user interaction raises the ominous threat that a virus writer might create a fast spreading worm that would spread in the style of Melissa or last May's "ILoveYou" virus, but without the need to trick people into running hostile attachments. Experts fear that many users -- perhaps most -- will invariably fail to close the hole and will thus remain open to attack. "Nobody downloads their security patches," said Dan Schrader, an anti-virus expert at Trend Micro Tuesday. "Which is unfortunate, because it's relatively simple to do." Martin warned that attackers won't be losing interest. "Between [USSR Labs] already having the code, and someone else posting follow up code to a public source, there are probably a dozen people working on their own version. And they're probably each figuring out the best ways to exploit this." ------------------------------ Date: Thu, 20 Jul 2000 21:03:48 -0700 From: Ursula Martin Subject: Powergen: More credit-card info exposed The UK electricity utility Powergen advised all its online customers to change credit-card numbers after details of 7000 customers were mistakenly made available on the web in early July 2000. [Source: http://www.guardianunlimited.co.uk/netprivacy/] ------------------------------ Date: Mon, 24 Jul 2000 13:40:04 -0400 From: "Stan Niles" Subject: Civilian payroll problem ``Civilian Payroll Problem: A major systems problem with the Automated Time and Attendance Production System (ATAAPS) has resulted in a significant loss of Time and Attendance (T&A) Report data. All transactions that were entered into ATAAPS between Saturday, 8 July 2000 and Tuesday, 18 July 2000 have been lost and are not recoverable. The lost transactions include leave, premium pay, tour of duty changes, default job order changes, and corrections that were made between those dates.'' I just got back from being away from work without checking in on my e-mail for a whole week (yippee!). This is what greeted me. I don't really know their process and I too busy digging out from the accumulated pile of mail etc. to find out. But ten days of lost payroll data? Haven't they ever heard of "backups"? Stan Niles Army Research Lab ------------------------------ Date: Fri, 21 Jul 2000 09:07:26 -0800 From: Rob Slade Subject: The Least Mail Online E-mail generally works so well that we have started to take its successful operation for granted, forgetting that delivery is still not guaranteed. As a case in point, Sprint Canada's The Most Online service had one of its regularly unscheduled outages last week, this time affecting incoming e-mail. The timing was particularly unsettling to me, as a group of us were in the final stages of negotiation with a publisher, and the discussions were being conducted via e-mail. From the date stamps on some late e-mail that is starting to dribble in, the outage probably started late Wednesday night. I didn't notice anything until late Thursday, when I expected to download the usual 150 messages that would have built up in the time I had been away from Net access. Instead I couldn't get anything. Calling the Sprint support line got a recorded announcement that "some subscribers may experience some problems in obtaining incoming e-mail." Friday a dribble of e-mail started to come through, but the announcement persisted over the weekend. Wednesday a fair number of old messages started to come through, so it seems that some of the backlog is starting to clear. However, there is no indication that I am going to get all my e-mail. In addition, during this whole outage I was sending mail from others of my accounts to the Sprint account. Of all the messages sent, some of the delayed at least six days before delivery, only one generated any kind of a bounce message or notification. (That bounce, generated at least five days after the original message was sent, stated that delivery had been impossible for at least 4 hours.) Therefore, it's quite possible that a number of people are mad at me for not responding to mail I've never seen. Once again, the risk is that we are seeing the Internet system, dependable though it may be, as completely reliable. (As usual, I submitted this to Sprint for their reaction before sending it out. They replied within about eight hours--confirming that the outage had occurred, and pointing out that their terms don't guarantee any minimum level of service at all :-) In the meantime, you know where to reach me. But maybe you'd better copy more than one address, just to be sure :-) rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Mon, 24 Jul 2000 20:00:37 -0400 From: John Chapin Subject: AT&T exposes account info I recently had occasion to call the AT&T Credit Management Center, 1-800-532-7486. You can type a home phone number into their voice menu system and it will answer back with the account standing, recent payment amounts and dates, without any password or other authentication. Perhaps this only applies to delinquent accounts (mine was, temporarily). AT&T only recently began billing residential long distance customers directly here in the Boston area, rather than through Bell Atlantic. They appear to be new to the privacy management side of customer accounts too. John Chapin, Assistant Professor, MIT Laboratory for Computer Science 545 Technology Square, Cambridge, MA, 02139, 617/253-3538, fax 617/258-8607 jchapin@lcs.mit.edu http://sdg.lcs.mit.edu/~jchapin ------------------------------ Date: Thu, 6 Jul 2000 09:57:16 -0400 From: "Mark Richards" Subject: Re: Sliced fiber-optic cable ... (RISKS-20.93) The same thing happened in our town - a much smaller scale - but the poor response of our phone service semi-monopoly Bell Atlantic is worth noting: Here in Massachusetts, and perhaps in other states in the US, we have something called "Dig Safe". It's both an admonition for the brain dead and an actual service for identifying buried utilities. With a simple phone call, Dig Safe coordinates the identification and marking of buried utilities so that excavators are not electrocuted or blown up. In our small community someone either forgot to call them or the marking was incorrect. They plunged a backhoe through a Bell Atlantic buried phone cable and "disrupted" service to a few thousand customers for several days. It was an "old" cable - the wires weren't colour-coded - making the wire-matching task extremely impossible. The really ugly part of the story is that no one, particularly Bell Atlantic, bothered to notify the local public-safety agencies. Their lame excuse, following this debacle, was that "the police should have known, considering we requested an officer at the scene for traffic control". The "accident" left thousands without access to emergency services and the emergency services were not given proper notification to employ a backup plan. By the way, the backup plan has already been thoroughly tested. Thanks to the incompetence of Bell Atlantic, our 911 emergency service has been knocked out twice in the past several months. Each time it's blamed on "defective equipment". These problems continue, while our Public Utilities Commission sleeps at the switch. The only time they wake up is when Bell wants a raise. Mark Richards ------------------------------ Date: Thu, 27 Jul 2000 10:27:24 +0100 From: "Clive D.W. Feather" Subject: Re: London Underground magnetic ticket bug (Boyd Roberts, RISKS-20.95) Actually, the risk here is in misunderstanding the system. The system as a whole (not just the automated gate) worked exactly as designed. The ticketing gates have 40 or 50 heuristics for detecting problems and fraud. If the gate is unhappy with the ticket presented, it displays the message "Seek Assistance" and a code number that the staff can use to determine what the problem is. The staff member at the barrier line can apply much more intelligence to the situation than a machine can. In particular, if you talk to railway staff you'll discover that they soon acquire a "sixth sense" of when people are trying to fiddle and when they are being honest. There are also various "trick" questions they can ask. Mr Roberts was caught by the "in-out-in" detector. This applies *at a station*. It is quite possible to exit at a *different* station before the timer (15 minutes, I think) expires, because this detector will not then apply. >It could be even worse; say there's a fire and you need to get out and the >station is not staffed. The barrier line *MUST* be staffed at all times. If the member of staff has to leave for some reason, he or she *MUST* deactivate the system, which opens all the gates. This is a Health and Safety issue, and LU would be fined heavily if caught breaking it. >The Paris Metro, RER and SNCF does this right. There's an entry timer, but >it's not used to control exiting. The Paris Metro is a flat fare system, so there's no need for ticket checks on exit. The situation isn't exactly comparable. Clive D.W. Feather +44 20 8371 1138 ------------------------------ Date: Mon, 24 Jul 2000 16:59:48 -0400 From: "Peter G. Neumann" Subject: Trust and Risk in Internet Commerce, Jean Camp Trust and Risk in Internet Commerce L. Jean Camp MIT Press, 2000 292 pp., ISBN 0-262-03271-6 http://mitpress.mit.edu/promotions/books/CAMTHF99 As Internet-based commerce becomes commonplace, it is important that we examine the systems used for these financial transactions. Underlying each system is a set of assumptions, particularly about trust and risk. To evaluate systems, and thus to determine one's own risks, requires an understanding of the dimensions of trust: security, privacy, and reliability. In this book Jean Camp focuses on two major yet frequently overlooked issues in the design of Internet commerce systems--trust and risk. Trust and risk are closely linked. The level of risk can be determined by looking at who trusts whom in Internet commerce transactions. Who will pay, in terms of money and data, if trust is misplaced? When the inevitable early failures occur, who will be at risk? Who is "liable" when there is a trusted third party? Why is it necessary to trust this party? What exactly is this party trusted to do? To answer such questions requires an understanding of security, record-keeping, privacy, and reliability. The author's goal is twofold: first, to provide information on trust and risk to businesses that are developing electronic commerce systems; and second, to help consumers understand the risks in using the Internet for purchases and show them how to protect themselves. Rather than propose a single model of an Internet commerce system, the author provides the information and insights needed by merchants and consumers as they develop the Internet for commerce. L. Jean Camp is Assistant Professor at Harvard University's Kennedy School of Government. ------------------------------ Date: Wed, 26 Jul 2000 18:57:04 GMT From: hali@usenix.ORG (Hali McGrath) Subject: 9th USENIX Security Conference 2000 9th USENIX Security Symposium 2000 Conference August 14 - 17, 2000 Denver, Colorado, USA Conference URL: http://www.usenix.org/events/sec2000 Presentations by top notch instructors and industry experts such as: Avi Rubin, Daniel Geer, Tina Bird, Brad Cox, Char Sample, Jim Duncan, Rik Farrow, and Marcus Ranum, Ian Goldberg, Suelette Dreyfus, Mudge, and Mark Chen. Keynote Speaker Dr. Blaine Burnham, Director of the Georgia Tech Information Security Center and former NSA program manager. Full program details and registration are available online at http://www.usenix.org/events/sec2000. ------------------------------ Date: 13 Dec 1999 (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) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => 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@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/textfiles/risks-digest/ . ==> PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.97 ************************