Text File

precedence: bulk Subject: RISKS DIGEST 19.71

RISKS-LIST: Risks-Forum Digest Friday 1 May 1998 Volume 19 : Issue 71

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://catless.ncl.ac.uk/Risks/19.71.html

Contents: [Mayday! = an appropriate cry for RISKS] Washington Metro Stops Payments on Troubled Computer (D. Scott Lucero) Euro phone network collapse: France'98 Cup tickets (Cris Pedregal Martin) A case of GPS jamming by a computer-test failure (Peter B. Ladkin) Software clandestinely uploading: Intuit TurboTax? (Mike Williams) British ATMs authenticate with iris-scanning (Tim Pierce) Re: A new kind of "sin attack" (Reuben G. Torrey) Re: Yes, Virginia, no classified information is leaked... (Michael Hogsett) Outrunning Bears (Adam Shostack) Risks of assumptions (Leonard Erickson) Y2K Testing Bugs (Name withheld) Y2K bug and public health concerns (Chris Kuan) Re: Going to jail innocently over a speeding ticket (John Carr) Re: Y2K on the road (A. Padgett Peterson) Passwords (Kevin 'Bob' Fu) IEEE newsletter on Security & Privacy (Avi Rubin) CFP: "Software Practice & Experience" on security (Gene Spafford) REVIEW: "Intranet Security", John Vacca (Rob Slade) "Beyond Calculation" - seeing the forest for the trees (Mike Martin) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Wed, 29 Apr 1998 19:13:44 -0400 From: "D. Scott Lucero" <LuceroDon@optec-hq.optec.army.mil> Subject: Washington Metro Stops Payments on Troubled Computer

*The Washington Post* (29 April 1998) reports that Washington DC's Metrorail is stopping payment on a system which pinpoints the position and operation of every train in the 92-mile system and controls 470 switches and 500 signals. Metro officials say that the system has crashed 50 times in the last 15 months. Screens go black, images jiggle, duplicate train numbers and slow response occur frequently according to officials. According to the Metro General Manager, "First we couldn't get the source code from [the contractor]. Then when we got it, it was in foreign language because they had a contractor work on it overseas... They've had people come and go. There has not been total continuity." A familiar RISK, not having developers close to the system. I used to think that not having the escalators work was a big deal - it appears they've got bigger problems.

Scott Lucero

------------------------------

Date: Fri, 24 Apr 1998 13:42:26 -0400 (EDT) From: Cris Pedregal Martin <cris@unreal.cs.umass.edu> Subject: Euro phone network collapse: France'98 Cup tickets

[A well known denial-of-service RISK, reported to remind everyone that these things keep happening.]

In a news item about the European Union's intention to fine the organizers of the soccer world cup France'98 (in non-US English: the organisers of the football world cup...), the leading Spanish daily _El Pais_ (http://www.elpais.es/p/d/19980424/deportes/entrada.htm, in Spanish), reports that (translated loosely):

[After complaints by the EU that almost all tickets were sold to French citizens, the organizers agreed to put 110,000 tickets on sale for non-French, through a single telephone number.] Almost 20 million people tried to reach 33.149.87.53.54 to buy tickets [...] with the result of blocking the phone system of several countries especially Netherlands, Belgium and the United Kingdom [...] only 15,000 tickets of the 110,000 available were sold because of the slowness of the system...

As a consequence of the ill-will generated, the EU may impose a fine of up to 10% of the world cup's gross income.

I did not find other reports of this; perhaps the European readers can report on the extent of the denial of service which must have affected traffic unrelated to the world cup ...

Cris Pedregal Martin - www.cs.umass.edu/~cris - Comp. Sci. UMass

------------------------------

Date: Mon, 27 Apr 1998 13:58:11 +0200 From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de> Subject: A case of GPS jamming by a computer-test failure

A colleague has pointed out to me that a confirmed case of significant GPS jamming is related at

http://www.fcw.com/pubs/fcw/1998/0413/fcw-frontgps-4-13-1998.html

A 30 Dec 1997 Continental trans-Atlantic flight lost all GPS signals as it descended south from Albany NY to Newark NJ for landing. Continental originally believed that the flight had been subject to intentional military jamming exercises. The FAA declared an `interference zone' of 300km, although they believed the jamming was localised around the Albany VOR navigation radio beacon.

It turns out that the US Air Force Research Lab Information Directorate has a facility in Newport, NY, that tests antenna emission patterns. On 30 Dec 1997, they started a test of a GPS antenna with a 5-watt signal, stepping through frequencies. The tests are computer- controlled, and it wasn't noticed that at the end of the testing period the transmitter had not turned itself off. The lab discovered the problem through reading message traffic reporting a GPS outage in mid-January. The jamming period ran from 30 Dec to 12 Jan 1998.

Peter Ladkin ladkin@rvs.uni-bielefeld.de http://www.rvs.uni-bielefeld.de

[Typo fixed in archive copy. PGN]

------------------------------

Date: Wed, 29 Apr 1998 11:50:05 -0400 From: Mike <John.Michael.Williams@Computer.org> Subject: Software clandestinely uploading: Intuit TurboTax?

One of the most widely used consumer programs is Intuit's TurboTax for Windows 95. In '98 ('97 tax year) I reluctantly started using it, because Intuit had bought out Parson's Personal Tax Edge, my preferred package, and discontinued it. I also use Quicken Special Edition (bundled with my Compaq tower), TurboTax For Partnership Returns (necessary for my consulting business), and Quicken Financial Planner, all promptly registered with Intuit, by postcard mostly. The TurboTax splash screens strongly warn to update the release with late forms and patches, automatically, by clicking on a button that takes one to their website on the Net. I have done this perhaps 3 or 4 times in the '97 tax season, twice getting significant (long) updates applied automatically.

I was disturbed to discover my summary tax information, not only in the TurboTax directories where it belonged, but in my Windows directory, partially encrypted in a file called INTUPROF.INI, along with registration information. Among the highly sensitive and demographically valuable fields shown there are: dependents' names, total exemptions, wages, taxable income, dividend income, business income, etc. I have attached a copy of my INTUPROF.INI for the editor to use as space permits. [The editor has removed it. It leaks too much information.]

I have not been able to reach Intuit on this or other matters: its website (www.intuit.com) has no feedback provision, it will not release any e-mail address for either feedback or Tech Support, and has interminable waits on phone calls to its HQ.

Do RISKS readers (and fellow TurboTax users) also wonder why this information is stored encrypted outside its designated area, and whether this information is being transmitted to Intuit during registration or at updates, without their consent? Do they wonder why a firm that sells its software on the net, and updates it that way, has no e-mail address?

If this is innocent, as I'd guess they claim, why do they make it so difficult to reach them to ask questions like this?

Mike Williams

------------------------------

Date: 23 Apr 1998 13:15:27 -0400 From: Tim Pierce <twp@skepsis.com> Subject: British ATMs authenticate with iris-scanning

A Reuters piece of 22 Apr 1998 announced the introduction of automated teller machines that authenticate users by scanning the customer's iris. Some details:

The manufacturers said the system, which they described as the first of its kind in the world, would be totally secure.

Customers will have a digital picture of their iris taken the first time they go to the bank.

A camera mounted on the cash machine will then scan their eye every time they want to withdraw money. Only if the iris matches the details stored in a central database will the transaction proceed.

"The system is foolproof because each person's iris is unique and above all the iris doesn't change throughout life, so it's safer than fingerprints," said Richard Lander, a spokesman for Britain's NCR Financial Solutions Group, a subsidiary of NCR Corp in the United States.

Some risks: does the iris really not change at all throughout life? [No. It can change considerably in color and blemishes. PGN] Are there circumstances under which the pattern of the iris cannot reliably be read? For example, would a customer who developed cataracts or glaucoma be able to authenticate themselves consistently, or would the condition of the eye confuse the scanning technology?

What happens to customers who lose one or both eyes, due to physical injury or illness? If a bank customer with a glass eye comes in to be scanned, could the bank mistakenly "scan" the artificial eye, and what would happen under those circumstances? Could the scanning technology injure such a customer?

Perhaps these concerns are not well founded. The point, of course, is that they need to be considered and examined, and it's not clear from this piece whether that happened. (A quick scan of some of the other wire services turned up no other reports of this item.)

This isn't the first time that biometrics have been introduced in bank-machine technology: a 1995 piece in the CNN archives reported a technology called `Fingerscan' that was being used experimentally to identify customers. That apparently went nowhere; why not? (Could NCR and Sensar, Inc. learn something from that lesson?)

"I think the new system can become popular especially when bigger sums are involved and people don't want to bother with their PIN (personal identification number)." [Richard Lander]

This may be a more troubling idea, for all the usual reasons. Is the motive for this new authentication system one of security, or one of convenience? If a deeper sense of security motivates people into using ATMs for huge transactions, it will surely provide a greater motivation to people to find a way to subvert the technology.

Tim Pierce <twp@skepsis.com>

------------------------------

Date: Wed, 29 Apr 1998 14:45:09 -0400 From: reuben.g.torrey@ac.com Subject: Re: A new kind of "sin attack" (Bostic, RISKS-19.70)

There is a distinct theological issue with the archive! The theology behind the secrecy of the confessional (which has subsequently made its way into client/attorney and patient/doctor confidentiality) is that the sins cannot be revealed because they no longer exist. Absolution not only forgives the action but, from God's not-confined-to-time perspective, makes it as if it never occurred (living/dealing with the real consequences of sin--dead bodies, destroyed lives, etc.-- is a separate issue, the reality of which is never denied). So, to maintain an archive of sins is, in a sense, to contradict God who has deleted the archive which did exist in His mind. Somehow, I don't think this is a smart thing for the penitent to do.

------------------------------

Date: Tue, 28 Apr 1998 13:11:14 -0700 From: Michael Hogsett <hogsett@warp.csl.sri.com> Subject: Re: Yes, Virginia, no classified information is leaked...

I have to wonder why they simply do not use a public-key encryption system such as PGP to encrypt their messages before transmission. It is trivial to set up, and fairly time consuming to crack.

I set up PGP on my system at home and at work in a number of minutes. My mailer (EXMH) integrates PGP when it is available. It will sign and encrypt my outgoing messages and decrypt and verify signatures on incoming messages seamlessly.

Michael Hogsett <hogsett@csl.sri.com> System Administrator, SRI Computer Science Lab

------------------------------

Date: Wed, 29 Apr 1998 03:45:59 -0400 (EDT) From: Adam Shostack <adam@homeport.org> Subject: Outrunning Bears (Cohen, 19.70)

Fred Cohen comments on the popularity of the "run-faster approach" to computer security. Unfortunately, run faster is only useful when running from bears. It doesn't do a lot of good when worried about a fellow with a machine gun. Many people are not aware of tools like Internet Probe Droid, which is an optimized scanner to find specific security problems by testing each of thousands of hosts for them. This is much closer to a machine gun than a bear.

The popularity of the run faster approach is based on faulty thinking about the problems that are out there. (I'm not accusing Fred of this thinking.)

------------------------------

Date: Thu, 23 Apr 1998 01:30:16 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Risks of assumptions (talon-owner, RISKS-19.69)

Actually, I know of *no* _personal_ computer that stores date/time info as the number of seconds from a baseline. They tend to store it in bit mapped fields. A few have already run into trouble. TRS-DOS version 6.2 will not accept a year greater than 1987, as they kept stealing "spare" bits from the datestamp field until they only had 3 left! They had to fix this by eliminating a password hash field.

MSDOS datestamps store the month day of month and year as bit mapped fields in a 16 bit variable. 7 bits are allocated to the year, which is stored as an offset from 1980. That is, 0 = 1980, 127 would equal 2107 *if* the date handling routines allowed a date past 2099, which they don't.

The risk is assuming that because the OS you are familiar with does something a certain way, so do all other OSes.

Again, the personal computers I am familiar with (mostly TRS-80, and the more recent PC compatibles) *don't* have OS or even hardware Date storage based on a count of *anything*.

The PC *does* count "timer ticks" since midnight to determine the time of day. But that's reset once a day, and is secondary to the real time clock chips in all PCs since the AT.

Leonard Erickson (aka Shadow) shadow@krypton.rain.com

------------------------------

Date: Thu, 23 Apr 1998 From: (Name withheld) Subject: Y2K Testing Bugs

There's a whole new class of problem that's been introduced with the Y2K panic: Y2K testing bugs, which are caused by people screwing around with the dates on their machines to see if anything will break when the year passes 2000. Things are breaking, not because programs can't handle the year 2000, but because they can't handle the dates on the machines jumping around.

I've seen two related cases now. In one, somebody set some machines forward to 2000, ran a program that collected data, everything worked, so they reset the clocks. Unfortunately, they forgot to get rid of the data they'd collected while the clocks were set forward, so everything ended up out of order, with the "year 2000" data showing up as the latest data collected. In the other, the machine was set to the year 2000, and then rebooted to make sure it would boot OK. After it did, the date was reset to 1998. Unfortunately, this leaves the year 2000 as the latest date in the boot log, and anything that checks to see if something has happened since the last time the machine was booted returns a false negative. Both these problems are easily fixed, but might not be easily detected. With Y2K testing being done on a large scale, I'm wondering how many stupid little problems are going to be introduced that persist until 2000.

------------------------------

Date: Thu, 30 Apr 1998 08:44:27 +1000 From: "Kuan, Chris CH" <Kuan.Chris.CH@bhp.com.au> Subject: Y2K bug and public health concerns

A report based on simulation tests of Y2K effects includes these items:

* ``Enough toxic chemicals would have been released into Coffs Harbour's water supply to kill its entire population.'' The entire chemical holdings were dumped into the water in a single shot.

* The Reserve Bank's vaults flew open.

* The Federal Government is allocating $126 million for federal agencies. The national electricity industry is spending close to $100 million, fearing widespread power blackouts and the failure of protective coats around live cables as a "worst case scenario".

* Telstra is spending almost $600 million on Australia's telecommunications.

Chris Kuan, BHP Information Technology

[Source: Y2K 'Could Kill a Town', by Darren Goodsir and Martin Chulov, *Sun-Herald*, Australia, 26 Apr 1998, p. 33. PGN Stark Abstracting]

------------------------------

Date: Thu, 23 Apr 1998 19:29:44 -0400 From: John Carr <jfc@mit.edu> Subject: Re: Going to jail innocently over a speeding ticket (RISKS-19.69)

The national driver database and interstate agreements have been mentioned before, in RISKS-14.26 and 14.27. Many states, but not all, have laws like the New Jersey law mentioned in 14.27: knowledge that one's license is invalid is not an element of the crime of driving without a license.

In this case (16.69) they found the right man. The old articles described problems caused by the database using name (or partial name) and birthdate as keys.

Mistaken identity is apparently not rare. A Boston _Globe_ article last year described a similar case. A man had his Massachusetts license suspended because Pennsylvania put a name and birthdate matching his in the national driver database. He didn't find out until he tried to renew his license. The article pointed out a bug in the system: when Massachusetts checked the national database and detected a match based on name, it filled in an empty field based on information from its own database: the Social Security Number. Now the other person's national record has his SSN.

The author of the RISKS-14.27 article said he had to convince his home state of the mistake. That was apparently too easy and the system seems to have closed the loophole. According to the _Globe_ article, the driver had to convince Pennsylvania to admit that it made a mistake.

I know a man who got into trouble because his name and birthdate matched that of someone in the database. His case proves that the database doesn't depend on gender: he got stuck with the driving record of a woman with the same name. Fortunately the judge was lenient.

I consider this primarily a social and political problem. The technology is working more or less as intended. There are minor bugs like the SSN leaking from one database to another, but the use of the SSN as a universal identifier is a choice approved by politicians who knew or should have known of the risks.

Here are the two fundamental principles of driving laws.

1: Driving is not a right so the government can take away one's "privilege" to drive essentially at will.

2: The people who make and enforce traffic laws are generally not subject to them.

The government wanted a system where any state could suspend the license or right to drive of any person in any other state (see item 1). They got it. The states designed laws based on the principle that it is better to convict an innocent man than let a traffic law violator escape "justice" (see item 2). The national database merely continues that tradition.

In other words, this is another case of bad requirements leading to bad software.

------------------------------

Date: Thu, 23 Apr 1998 14:44:10 -0400 (EDT) From: "A. Padgett Peterson" <PADGETT@hobbes.orl.lmco.com> Subject: Re: Y2K on the road (McLain, RISKS-19.69)

Computer ? 1979 Toyota ? Right. - P

[Several folks doubted that story. PGN]

------------------------------

Date: Wed, 29 Apr 1998 08:45:19 EDT From: "Kevin 'Bob' Fu" <fubob@mit.edu> Subject: Passwords

Lecturers often give computer demos during large lectures. One lecturer recently muttered this while logging in to our campus-wide system:

Lecturer: "Wrong password? ... Hm, oh! Wrong daughter."

Kevin E. Fu (fubob@mit.edu)

------------------------------

Date: Tue, 28 Apr 1998 00:38:57 GMT From: rubin@research.att.com (Avi Rubin) Subject: IEEE newsletter on Security & Privacy

This is to inform people who are interested in the IEEE Computer Society's Technical Committee on Security and Privacy's newsletter, CIPHER. The URL for the online version can be found at

http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/

------------------------------

Date: Mon, 27 Apr 1998 09:52:48 -0500 From: Gene Spafford <spaf@cs.purdue.edu> Subject: CFP: "Software Practice & Experience" on security

Call for Papers, Special issue of "Software Practice & Experience" Experiences with Computer and Network Security, Contact me (the guest editor) for details on submissions (by 1 July 1998), or to volunteer as a referee.

SP&E Special Issue Submissions c/o Prof. Eugene Spafford Department of Computer Sciences Purdue University West Lafayette, IN 47907-1398

Spaf <spaf@cs.purdue.edu>

------------------------------

Date: Tue, 28 Apr 1998 08:23:33 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Intranet Security", John Vacca

BKINTRAS.RVW 980206

"Intranet Security", John Vacca, 1997, 1-886801-56-8, U$49.95 %A John Vacca jvacca@hti.net %C 403 VFW Drive, PO Box 417, Rockland, MA 02370 %D 1997 %G 1-886801-56-8 %I Charles River Media %O U$49.95 800-382-8505 617-871-4184 fax 617-871-4376 %O chrivmedia@aol.com www.charlesriver.com %P 506 p. + CD-ROM %T "Intranet Security"

While the author seems to be sincerely motivated by a concern for security, this book badly needs more discipline, more material, and more fact checking. Not to mention a closer alignment with the stated topic.

Part one is a general guide to data security. Chapter one, although titled "Intranet Security Trends," provides an overview of vulnerabilities, means to address them, and security policies. Security policies are covered in more depth in chapter two, and then really again in chapter three, although there are slight variations in emphasis. Chapter four introduces Internet (TCP/IP) specific topics, but still is dealing at the level of policy. Part one closes with a look at hiring or being hired (it's a bit difficult to tell) for a security position.

Part two is said to address intranet security threats, but starts out with a look at security protection tools in chapter six. (More specifically, chapter six presents a kind of extended case study of the work at Portland State University.) Chapter seven discusses security applications again, in part more generally, and in part mentioning specific proprietary programs. Chapter eight does the same thing. Finally, chapter nine does look at a variety of risks associated with Internet use, although it seems to keep lapsing into a discussion of encryption as a security tool. (There is also a rather odd statement about using antiviral software to protect confidential documents.) Identification of computer viruses, in chapter ten, contains generally good advice, but some extremely suspect assertions in the background discussion. Chapter eleven is supposed to talk about antivirus software, but after a nonsensical description of an almost unknown "type" of antiviral software, the rest of the chapter meanders around oddball virus related topics without divulging too much useful information. (This emphasis on viruses is, of course, rather gratifying from my perspective, but doesn't seem to have much to do with the stated topic of intranets. In terms of intranets, the gravest viral danger is probably that of the MS Word macro viruses, which get some space, but don't seem to be a priority.)

Disaster avoidance, in part three, would seem to be what computer security is all about. The recovery part seems to be primarily physical, since chapter twelve stresses redundant hardware and hot sites.

Part four discusses development, implementation, and management of security. Chapter thirteen reprises some of the information from part one in reference to workstations. Database security is important, but chapter fourteen does not provide enough coverage to really get down to work on it. Chapter fifteen looks briefly, but not in much detail, at security for remote users. Policy is revisited in chapter sixteen.

Part five is supposed to look to the future, but chapter seventeen is little more than a collection of computer crime war stories. Chapter eighteen proposes that the Year 2000 problem might raise security issues, but is short on specifics. Internet security related issues are once again discussed briefly in chapter nineteen. Chapter twenty is supposed to be a summary and recommendations, but seems to be simply a rather random assortment of additional security related bits.

Although there is some general security related material in this book, almost nothing relates directly or particularly to intranets. The security content is not too bad as far as generic advice is concerned, but isn't anything too significant, either. Overall the book is woefully short in some areas, redundant in others, and badly disorganized. For standard security advice the reader can easily do better.

copyright Robert M. Slade, 1998 BKINTRAS.RVW 980206

------------------------------

Date: Thu, 30 Apr 1998 12:07:15 +1000 From: "Martin, Mike" <mmartin@sbnsw.com.au> Subject: "Beyond Calculation" - seeing the forest for the trees

What will be the impact of computer and communication technology on society in 25 years? In 50 years? Rob Slade's review of this book (Risks 19.70) raises the interesting issue of how to see the forest for the trees.

I don't have the answer.

However I'd like to make some suggestions as to what the question means.

A paper by Peter Drucker that appeared in the Harvard Business Review a few years ago began:

"Every few hundred years, throughout Western history, a sharp transformation has occurred. In a matter of decades, society altogether rearranges itself. Its world view, its basic values, its social and political structures, its arts and institutions. Fifty years later, a new world exists. And the people born into that world cannot even imagine the world in which their grandparents lived and into which their own parents were born.

"Our age is such a period of transition."

From memory, Drucker suggested that the current transition can be dated from around 1950 and that, in fact it may take 75 or 100 years before the full implications become apparent.

Typically, technology inventions are used at first to provide new solutions to existing problems. The horseless carriage was exactly that.

Typically also, a major technology invention fails to reach its potential until other, enabling inventions have occurred. The steam railway had only limited usefulness, until the invention of wrought iron permitted rivers and gorges to be affordably bridged.

Gutenberg invented the European version of the movable type printing press about 1450, but it was another 400 years before an industrial process was invented for making cheap paper from wood pulp.

The impact of computer and communication technology 25 or 50 years from now might turn out to be further refinement and spread of existing uses. Then again, other enabling inventions may open directions that we cannot guess at. And they won't necessarily be benign.

Suppose the advent of quantum computing allows rapid factoring of extremely large numbers. Much of today's security technology would be in immediate disarray. Or suppose widespread deployment of a secure Internet payment system puts control of the world money supply into the hands of a few maverick bankers in hitherto obscure nations.

Tomorrow may be like today, only more so. Then again, it may herald another "Druckeresque" transformation. Any suggestions about already emerging technologies that may signal the latter?

Mike Martin, Sydney, Australia mmartin@sbnsw.com.au

------------------------------

Date: 31 Mar 1998 (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 <risks-request@csl.sri.com> 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 <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.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 18" for volume 18] 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 19.71 ************************