precedence: bulk Subject: RISKS DIGEST 18.88 RISKS-LIST: Risks-Forum Digest Friday 7 March 1997 Volume 18 : Issue 88 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** Contents: NASA: Another Website Bites the Dust (David Kennedy) Two More Microsoft Internet Explorer Bugs (David Kennedy) Another MacInTax "Glitch" (David Kennedy) Re: 12/99 problem (Clive D.W. Feather, Mark Brader) Computer glitch leads to police friendly fire (J.R.Valverde jr) Re: Mouse-based interfaces (Dean Esmay via Phil Agre) Trusting the software vendor (Matt Welsh) "Rich" computing versus security (Matt Welsh) Re: ActiveX security: The other side (Wayne K. Gerdes) Lab monitoring (Fritz Schneider) Risks of crying wolf (David Lesher) Moonlighting on safety-critical systems (Jonathan Bowen) The SEI Conference on Risk Management (Carol Biesecker) The Ethics of Electronic Information in the 21st Century (Les Pourciau) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 5 Mar 1997 16:59:16 -0500 From: David Kennedy <76702.3557@compuserve.com> Subject: NASA: Another Website Bites the Dust http://www.nasa.gov is NASA's home page. It appears it was hacked last night. It's off-line now. When a mirror of the hacked page is posted, I'll let you know if someone else on the list doesn't first. If my report is accurate, the hacked page included: >Our mission is to continue where our colleagues the ILF left >off. During the next month, we the members of H4G1S, will be >launching an attack on corporate America. All who profit from >the misuse of the internet "ILF" refers to the Internet Liberation Front who attacked GE and others in December 94. The only person who has claimed to be a member of the ILF is Christopher Schanot, a then-high schooler from St. Louis, who's in jail for what he did. He broke into systems using a password provided by a classmate who was the son of an employee of one of the systems he entered. He also used password sniffers to capture legitimate passwords that were passed over the net unencrypted. The rest of the hacked NASA page is some mundane pro-hacker stuff about Kevin "Condor" Mitnick and Ed "Bernie S" Cummings. Lesson: Running a web site requires somebody to take the time to know about the vulnerabilities and *do* something about them. There are no quick fixes. As William Hugh Murray, a colleague, says, "There is no magic." Dave Kennedy CISSP National Computer Security Assoc 76702.3557@compuserve.com ------------------------------ Date: Fri, 7 Mar 1997 02:12:18 -0500 From: David Kennedy <76702.3557@compuserve.com> Subject: Two More Microsoft Internet Explorer Bugs 1. EliaShim warns of security hole in Internet Explorer Courtesy of the COMTEX Newswire via CompuServe's Executive News Service > PC Week Online (March 6, 1997) - Less than a week after the discovery of a > potential security gap in Internet Explorer 4.0, Microsoft Corp. may have > another hole to fill. EliaShim Ltd., an anti-virus company, claims it has > identified security problems in Microsoft Internet Mail and News > applications. "Hostile links" can be embedded in newsgroup messages or in > messages received by Internet Mail as shortcuts, company officials said. 2. Another Internet Explorer Bug Found Courtesy of the COMTEX Newswire via CompuServe's Executive News Service > REDMOND, WASHINGTON, U.S.A., 1997 MAR 7 (Newsbytes) -- By Bob Woods. > Another bug in Microsoft's [NASDAQ:MSFT] Internet Explorer (IE) World Wide > Web browsing software has been discovered by a group of University of > Maryland students. The students posted their results at their Web site > today, and claimed that the bug could let a hacker remotely break into a > user's computer or install viruses onto the system. UMD students David > Ross, Dennis Cheng, and Asher Kobin found the bug in IE 3.01. Microsoft acknowledges the bug but hasn't defined it full impact. > The bug apparently centers around IE's Iframe, or floating > frames feature. The patch for the URL/LNK bug does not fix the UMD student's bug. > The students' Web site is at http://dec.dorm.umd.edu/ . > Microsoft's IE site is at http://www.microsoft.com/ie . Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc. ------------------------------ Date: Fri, 7 Mar 1997 02:12:21 -0500 From: David Kennedy <76702.3557@compuserve.com> Subject: Another MacInTax "Glitch" Intuit warns of MacInTax glitch Courtesy of the COMTEX Newswire via CompuServe's Executive News Service: > MacWEEK Online (March 5, 1997) - Intuit Inc. this week sent a letter to > its MacInTax users detailing a potential pitfall for electronic > filers. Users who fail to save their documents before filing them > electronically may receive word from the IRS of an incomplete filing. The > company said the problem will likely affect only a small percentage of > users, as most would opt to save their work before transmitting > files. However, there are some customers who tend to go straight to the > electronic filing function without saving. Patch at http://www.intuit.com/ or by disk. > In a statement, Intuit Vice President Larry Wolfe said the problem is > "absolutely covered" under Intuit's general product guarantee. "If a > customer has filed an incomplete electronic return with MacInTax, Intuit > will pay the penalty plus any interest assessed by the IRS," he said. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc. ------------------------------ Date: Fri, 7 Mar 1997 08:19:07 +0000 From: "Clive D.W. Feather" Subject: Re: 12/99 problem This looked like a Y2K problem at first sight. However, it isn't. Some names are changed to protect me from defamation suits. I work for a major ISP, and many of our customers pay us monthly by credit card. This problem hit a whole batch of customers at once, but I'll just pick one and call him or her C. C has a card issued by a major bank, who we'll call B. We use a major credit card organisation in the UK for all credit card transactions; let's call them V. When a customer signs up with us, they quote card number and expiry date, which we enter on to our computer. Each month we take that data and send V a packet of the form . Now suppose that the card originally expired in 08/96. The customer might be good enough to let us know that they have a new card expiring in 08/98, and we can update our records, or they might not. If they don't, then we send to V. The other day we charged C's card. It came back "rejected". So, following normal practice, we suspended the account and waited for C to call us. After doing so, C phoned B and confirmed the card was fine. A four-way conversation then ensued. It turns out that what happened was the following. C's card had an original expiry date of 12/96. Our software noticed that the card was expired, and sent the request with an expiry of 12/99. On arrival at V, their software looked up the card number in a table which says, in effect: "this range of card numbers was issued by B with an expiry of 12/96". V's software also knows that B uses a 3-year rollover of cards. So they added 3 to 12/96, amended the expiry field to 12/99, and forwarded the request to B. Meanwhile, someone at B decided that, given the special meaning of 12/99, issuing cards that expiry then is a Bad Thing. So cards expiring in 12/96 were renewed with an expiry of *11*/99. The resulting mismatch caused the rejection. I understand that V's computers will be reprogrammed to solve this problem. But just whose is the error? Clive D.W. Feather Demon Internet Ltd. +44 181 371 1138 CityScape Internet Services Ltd. ------------------------------ Date: Fri, 7 Mar 97 11:11:44 EST From: msb@sq.com Subject: Re: 12/99 problem Clive Feather writes: > This looked like a Y2K problem at first sight. However, it isn't. Sure it is. Without Y2K, who would have thought of choosing the month/year "12/99" as an out-of-band flag value? In fact it's a particularly silly Y2K error, since 99/99 would have fitted the field length just as well. > But just whose is the error ? Either B's or V's, but in order to tell which, we'd have to know what they said to each other and when. Did V tell B that they needed to know their expiry rollover pattern in order to validate transactions, or did they just assume that because B had been using a 3-year rollover they always would? If the former, then did B inform V that their practice was being varied this time, and if so, did they do it in timely manner so that V could be prepared for it? Mark Brader, msb@sq.com SoftQuad Inc., Toronto ------------------------------ Date: Fri, 07 Mar 1997 18:30:08 WET From: "J.R.Valverde (jr)" Subject: Computer glitch leads to police friendly fire The Vasque Country in the north of Spain has a strong terrorist group, ETA, which -among other activities- often attacks the Police. Last week there was a sad incident: two secret police groups started shooting each other. The reason? According to the government it was all due to a computer glitch. Things are said to happen like this: that afternoon there had been a bombing in town. One group of civil-dressed secret policemen saw a group of armed guys in a car and started off after them. Of course, first thing they did was call the central offices to ask for information on the car and its owner. Here comes the computer bug: they could not get any information and assumed those guys were the terrorists that had done the bombing. The other car was loaded with secret policemen too. They saw that they were being followed by armed civil-dressed people in a car, could not get any information either and assumed they were being pursued by terrorists that were after them to kill them in a second coup de main and fled away. You can see what happened. At some point the first car stopped, the second did the same, all them took their arms, all them got alarmed at seeing each too their arms, someone shoot first, and hell was left loose... The problem? relying on computers for tasks where human lifes are involved and not having adequate fail-safe systems. jr ------------------------------ Date: Thu, 6 Mar 1997 19:01:15 -0800 (PST) From: Phil Agre Subject: Mouse-based interfaces (Re: Hersh, RISKS-18.87) [He's right. Phil] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help@weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Thu, 6 Mar 1997 21:53:39 -0500 >From: Dean Esmay Subject: mouse-based interfaces [...] I was both pleased and disturbed to read Jay Hersh's comments on GUIs and the disability community in your recent RRE mailing, and a bit concerned about some of your comments on his thoughts. Not that either of you are wrong, but you aren't exactly right either. The deaf child, the woman with multiple sclerosis, and the blind man all have fundamentally different needs, none of which are necessarily compatible. Given that, I'm not sure who Jay Hersh thinks he's talking about when he refers to the "community" needing to fight against mouse-centric interfaces, and I am even less sure that the waters aren't further muddied by your comments about the efficiency of keyboard interfaces. I worked for a number of years in an employment agency for the disabled, and have attended and even led workshops on how to make computers more accessible to the disabled. I think three things should be kept in mind before anyone tries to influence how computers interact with people: 1) GUIs are substantially beneficial to some disabled users. 2) The problem with computer software not working well for some people has been around far longer than the widespread use of GUIs. 3) There is no one solution (to date) that works well for everybody. Prior to GUIs, the visually impaired did pretty darned well. After all, text-based software can often be easily adapted to speech synthesis. While there were things to complain about, the blind generally did pretty good. But the blind are not the only members of the disability community, and the non-blind disabled were often still faced with serious aggravations, or even locked out in the cold. GUIs fixed that for many of them. A number of devices exist that substitute for the traditional mouse, the best of which is a strap-on headset with which a person with no use of hands can point by merely moving her head (or even just her tongue if neck mobility is limited) and "clicking" with a puff of breath. Your beloved EMACS is normally worthless to a woman without arms. But give her an interface where she can point and click with her hands-free mouse, "type" clicking on the keys of a floating on-screen keyboard that feeds her "keystrokes" to the window of her choice, and that responds to specific voice commands for shortcuts, and she can do anything you can. In today's GUI world, most properly-written software can use such special tools without need for modification or special programming. It's also probably unfair to lump Apple in with Microsoft. Apple has a long history of working with the disability community. Back in the old Apple II days, they manufactured special devices to help the disabled use their computers. When the Mac came along, they cooperated enthusiastically with the manufacturers of the hands-free mouse and similar devices, and worked hard to make their GUI and their API work effortlessly with such special tools. Apple also put a good bit of money into developing and testing their Easy Access and Closeview extensions, which ship free with every Mac/OS machine and vastly improve the interface for many disabled people (including some with partial vision). They even include system software extensions to make voice control possible in any program, and powerful built-in scripting that can automate many tasks in many applications. Of course, Apple comes up short with some, especially the blind. That section of the community has generally stayed with the text interface operating systems that work best for them. But still, Apple has arguably done much to adapt to people with special needs, for which they deserve credit. But let's set aside Apple, which is only one imperfect company. The fact is that today, a majority of the disabled can use much Windows software right off the shelf, too. This is a tremendous step forward from ten years ago. But the same GUI which has helped so many others is forcing the blind to the sidelines. It's damned hard to adapt a GUI to a speech-synthesized, sight-free world. It's not impossible; some very clever macro-based work-arounds do exist. But much more needs to be done to address this problem. There badly needs to be a widespread discussion of issues like applications and APIs which just plain ignore the needs of the disabled. We need to encourage elimination of unnecessary popup menus and dialogs, buttons with graphics but no text, buttons with text but no graphics, hierarchical pull-down/pop-up menus that are a bitch to navigate if you can't see well or have poor coordination, and more. The blind also have a need for more productivity and utility software written specifically with them in mind; the market is large enough now that, while it might not be much of a blip on Microsoft's radar screens, it's more than enough for small companies and cottage industrialists to make decent money. I've met a few people who write that kind of software for a living, but there's room for more. I commend you for bringing this issue to wider attention, and I hope you'll talk more about it in Red Rock Eater. But I urge you not to get lost in generalizations about what a vague, unspecified "disability community" needs, or tangle that up with what you find most useful for yourself. In any case, thanks for doing something to at least start people thinking about these issues! http://www.syndicomm.com/esmay ------------------------------ Date: 7 Mar 1997 12:09:01 GMT From: mdw24@cl.cam.ac.uk (Matt Welsh) Subject: Trusting the software vendor (Re: Atkinson, RISKS-18.85) > ... you trust the retailer to sell you only legitimate product ... It's interesting that Microsoft should defend Authenticode with this analogy, when in fact Microsoft itself has been known to distribute CD-ROMs with viruses. Given that I can't even "trust" Microsoft software obtained through traditional distribution channels, by what stretch of belief am I supposed to concede that Authenticode will solve this problem for non-traditional channels? M. Welsh, Cambridge Computer Laboratory ------------------------------ Date: 7 Mar 1997 12:24:05 GMT From: mdw24@cl.cam.ac.uk (Matt Welsh) Subject: "Rich" computing versus security (Re: Atkinson, RISKS-18.85) >Users want and demand a rich computing experience. ... It seems that it would be worthwhile in the course of this discussion to step back a bit -- instead of merely attacking or defending Authenticode, why don't we look at the basic statement used to defend ActiveX? Paraphrasing, "In order to have a rich computing experience, applications must forgo some degree of security." This is a contentious statement. A great deal of work has been done in both the academic and industrial computing communities to develop computing environments which enable 'sandboxing' of code and still provide a 'rich computing experience' - e.g., flashy graphics, I/O device and network access, and the like. Although with the advent of Java we are starting to see these ideas in the mainstream, they're not particularly new. It is far easier to verify and trust my Java Virtual Machine implementation, for example, than it is to verify and trust every ActiveX control which comes my way. In the former case we are basing our trust on the developers of the computing environment - in the latter, upon every software developer who ever writes or has a hand in every ActiveX control we use. In the former case, the security of the system can be verified and is enforced through technical means; in the latter, only through social and legal ones. I know which one of these I'd rather employ. M. Welsh, Cambridge Computer Laboratory ------------------------------ Date: Fri, 07 Mar 1997 11:29:56 -0500 From: "Wayne K. Gerdes" Subject: Re: ActiveX security: The other side (Rath, RISKS-18.87) Having done a proposal for development of a worm/agent based software distribution system similar to ActiveX or FTP inc's CyberAgent I have done some serious thinking about the security problems. A truly useful piece of software must have access similar to a standard user account, or at least a captive account. Java's sandbox model is wonderful if the idea is to provide graphics using the local machine's CPU power. It is, however, very difficult to perform useful work with such a system, where useful work is defined as, say word processing involving references to active objects and saving files locally. A more scientific example might be performing calculations as part of a distributed computation and forwarding the results to some arbitrary destination. Another example might be querying a series of remote databases and forwarding the results. These examples require the ability to address arbitrary hosts, require disk storage space, and/or a vanity of other access and privileges. The primary problem is that Windows 3.1 thru Windows 95 does not have the security features to isolate such programs. Under "more advanced" operating systems such as UNIX, VMS, or Windows NT, to name just a few, it is possible to create a "larger sandbox", via separate accounts, captive accounts, disk quotas, limiting system calls, etc. Note that even this will not eliminate the security problem(s). It is always the temptation to install new software with root privilege or equivalent. It is almost always possible for hackers to find some OS bug to exploit. As readers of this digest know, even well intentioned programs often corrupt data, crash machines etc. The next element of the security problem, is the surprisingly high quality of web distributed software. Despite the many security concerns of down loading and executing some arbitrary piece of software written by Unknown, most people do it and the worst thing that usually happens is that it crashes. AS Mr. Rath notes, most people want to "just get on with it". Security warning messages about "Should this program be allowed to access the disk?" or "Accept this cookie?" quickly become annoying and get turned off. Under these circumstances the current digital certificate and code signing is a reasonable approach. What the current system does lack is degrees of trust. It might be reasonable to require a very large bond before issuing a AAA certificate and a small one for a BBB certificate. Web sites could be established to rate the reliability of new software. Something like Cancel Moose could be developed to chase down and deactivate certificates belonging to errant software. Instead of downloading certificates they might be implemented as active objects stored at well known web sites. This would make the process of revoking them MUCH easier. Looked at from this view point ActiveX vs Java can be seen as sort of large scale beta testing of "the REAL solution". Wayne K. Gerdes w.k.gerdes@larc.nasa.gov (757)864-1520 (AST, Data Systems) Flight Electronics Tec. Div, Systems Integration Branch MS 152D ------------------------------ Date: Fri, 7 Mar 1997 17:10:47 -0500 (EST) From: Fritz Schneider Subject: Lab monitoring (Re: Fraudulent use of e-mail addresses, RISKS-18.87) Just a quick response to Andrej Panjkov's article regarding a bad experience he had with e-mail forged in his name. After relating his situation, Mr Panjkov gives the following advice: > Lessons: monitor undergraduate computers carefully. At the very least, > register users. And use PGP. Perhaps, we should all periodically sweep > the web to see where our names are ending up? Although in theory I agree with all of these suggestions (ignoring the impracticality of the last), I question the wisdom of assuming that misuse of technology such as the net will be perpetrated by the younger generation. There is no reason to necessarily suppose that older (graduate) students are any more ethical than their younger (undergraduate) counterparts. In fact, it seems to me that the BIGGEST risk comes from those with more education, skills, and experience. Therefore if one can only monitor one lab but not both, it would be more prudent to keep an eye on those with the resources to carry out the most destructive acts. I am, however, not convinced that mere "monitoring" of a computer lab can prevent forged e-mail... The Risk here: 1. Assuming that age/education is inversely proportional to ill intent. Fritz Schneider [ fritz@columbia.edu ] ------------------------------ Date: Fri, 7 Mar 1997 04:48:27 GMT From: wb8foz@netcom.com (David Lesher) Subject: Risks of crying wolf I am in Maryland [301], but the local calling area extends across DC [202] into Virginia[703]. Within that area (which also includes parts of 410 and soon will have 240 and 443), calls are 10D, with a leading "1" not necessary. (Rather; without it, you are assured the call is not toll.) So I tried to call 703 715 xxxx, in the Vienna area. But I got an intercept, telling me that THAT number was now in the 540. (540 was split from 703 last year, with Risks of its own after Bell sent postcards to the WRONG group of customers...) Now, AFAIK, no part of 540 is DC-Metro. And 715 did not move. But I gave it a try, and sure enough, Bell decided "540-715X" was a 301 #, (Gaithersburg, local to me) but one out of service. (With no "1" it knew better than to try 540-715-xxxx.) Now, 715 is *still* in 703. So that intercept is bogus. But look who likely gets wrong numbers from believing it: 540-715 if/when it's created, and 301 540-715x. The Risks? Well, believing the error message may do you more harm than good. And as the sparse NPA space turns increasingly dense, others won't have the benefit that I received; that of the wrong number I dialed being idle. Did Arthur C. Clarke see THIS coming, too ;-? wb8foz@nrk.com (301) 56-LINUX ------------------------------ Date: Fri, 7 Mar 1997 09:24:45 GMT From: J.P.Bowen@reading.ac.uk (Jonathan Bowen) Subject: Moonlighting on safety-critical systems Below is a possibly worrying message which I received recently. (Name and contact details are blanked out.) Who takes the responsibility if things go wrong? Jonathan Bowen, Univ. of Reading, Department of Computer Science, Whiteknights, PO Box 225, Reading, Berks RG6 6AY, UK http://www.cs.reading.ac.uk/people/jpb/ >Date: Thu, 6 Mar 1997 19:05:30 +0000 >From: xxxxxxxx >To: J.P.Bowen@reading.ac.uk >Subject: wanted >Would it be appropriate for you to [post] this opportunity on your system? > WANTED - Moonlighter with mixed signal simulator and formal verification > tools to modify a circuit for a medical device. Reply confidentially to > FAX xxx xxx xxxx. ------------------------------ Date: 6 Mar 1997 18:54:32 GMT From: cb@SEI.CMU.EDU (Carol Biesecker) Subject: The SEI Conference on Risk Management The SEI Conference on Risk Management: Managing Uncertainty in a Changing World April 7-9, 1997, The Cavalier Hotel, Virginia Beach, Virginia For the most current information about the SEI Conference on Risk Management and other SEI events, visit our Web site at www.sei.cmu.edu/products/calendar.html For additional information about the conference, contact SEI Customer Relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Phone, Voice Mail, and On-Demand FAX 412 / 268-5800 E-mail: customer-relations@sei.cmu.edu World Wide Web: http://www.sei.cmu.edu The keynote speakers are . Dr. Paul G. Kaminski, Undersecretary of Defense Acquisition and Technology . General Alton D. Slay, USAF (ret), Slay Enterprises, Inc. . Timothy Lister, The Atlantic Systems Guild, Inc. Five half-day tutorials are being offered during the morning of Monday, April 7, 1997. Two panel sessions are planned for the afternoon of Tuesday, April 8, and the morning of Wednesday, April 9. A special track is planned for invited program managers to talk about their risk management experiences. This track starts Monday afternoon, April 7, 1997, and runs in parallel with two more tracks, Acquisition/Risk Management in Practice and Theory, Models, and Lessons Learned. ------------------------------ Date: Fri, 07 Mar 1997 09:02:55 -0600 (CST) From: Les Pourciau at UMem Subject: The Ethics of Electronic Information in the 21st Century THE ETHICS OF ELECTRONIC INFORMATION IN THE 21st CENTURY September 26-28, 1997 The University of Memphis {Libraries & Information systems & Linder Center for Urban Journalism & Division of Research and Graduate School & Marcus Orr Center for the Humanities & Cecil C. Humphreys School of Law & Fogelman College of Business and Economics } Fogelman Executive Center, The University of Memphis, Memphis TN, U.S.A. http://www.people.memphis.edu/~operations/fec_list.htmlx Additional Memphis Web Site: http://www.memphistravel.com Abstracts due by 25 April 1997. [Check website for details.] ------------------------------ Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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 or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.88 ************************