Text File

precedence: bulk Subject: Risks Digest 21.06

RISKS-LIST: Risks-Forum Digest Monday 25 September 2000 Volume 21 : Issue 06

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.06.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: Australian online voting scores: no oohs 'n Oz? (Garry Allen) Youthful toothful (PGN) Concorde Problem Visibility (Peter B. Ladkin) Re: Concorde crash report (Zygo Blaxell) Ostrich Farming? (Pat St-Arnaud) Pentagon security gate goof, again (PGN) U.Wisconsin alters photo to add "diversity" to student body (PGN) Why software fails (Mike Lewis) Filtering, censorship, silence: Who owns the language? (Richard Schroeppel) Re: Decimalization and Ford Stock Splits (Timothy Prodin) Re: Identity theft (Martin Minow) Re: Qualcomm CEO's laptop vanishes (Camillo Sars) Re: Risks of using HTML Mail and HTTP proxy "censorware" together (J.D. Abolins) Artificial Intelligence strikes again (Rodger Whitlock) SBC Calling Card PIN (Conrad Heiney) Abridged info on RISKS (comp.risks)

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

Date: Thu, 21 Sep 2000 14:49:59 +1000 From: Garry Allen <GAllen@dspmedia.com.au> Subject: Australian online voting scores: no oohs 'n Oz?

The Australian Broadcasting Corporation ran a television show recently called Race Around Oz. It was a competitive documentary series where 6 competitors had to present a five minute documentary every two weeks. These were then judged by industry representatives as a story with the overall winner receiving a digital video camera and a two week stint as a producer on one of the ABC documentary shows.

There was also an audience winner. Viewers were invited to vote either by toll number or by an online voting form. The audience winner also received a video camera and a two week stint. Apparently there was nothing to stop someone voting early and voting often. The ABC also has a show looking at the media, Mediawatch. For some reason, the audience voting patterns were brought to the show's attention. The winner of the audience vote was 5 times as popular as any of the other contestants in the online votes despite her documentaries being hated by the judges. In fact, according to the program transcript, they asked the School of mathematics at the Swinburne University of technology to investigate. they found that the difference in online voting patterns being solely due to chance to be statistically significant at the 1% level, ie highly unlikely. Mediawatch did some research and has raised some questions about the results. http://www.abc.net.au/mediawatch/transcripts/s175489.htm http://www.abc.net.au/mediawatch/transcripts/s181183.htm

The comments quoted below are pertinent.

From the first show:

> ABC Online say they're working on the problem but warn: The ABC is aware > that online voting does have limitations ... such voting should never be > construed as an accurate representation of an entire audience or > population's views. (ABC Online e-mail to Media Watch 8/9/00)

> Paul Barry: And that's a warning that Race Around Oz might take on board > before they rely on their online votes again.

> As Jane put it: Thanks for coming with us for what has been the ride of a > lifetime for everyone involved with the program ... (ABCTV Race Around Oz > final episode)

> Paul Barry: Or maybe - thanks for letting us take you all for the ride of > a lifetime.

And from the second show:

> So what will the ABC be doing about this? The ABC will, of course, look > closely at the allegations and at all documentation before deciding on a > course of action. (Race Around Oz fax to Media Watch 18 Sep 2000)

> Paul Barry: Yes. And when they've worked out what to do about Stacey, > they'd better take a closer look at what to do about their own reliance on > a voting system that is so easily abused.

It is hard to believe that an online voting system could ever be manipulated like this, particularly not one associated with a reputable media organisation such as the ABC. (:-)) And no doubt the e-mails purporting to be from Stacey could have been forged. But somehow I doubt that the organisers of Race Around Oz will use a voting system like this again.

Garry Allen

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

Date: Wed, 20 Sep 2000 19:52:21 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Youthful toothful

On 20 Sep 2000, Jonathan Lebed, 15, settled a federal civil-fraud process, agreeing to pay $272,826 for perpetuating bogus information on the Internet that led to the stock fluctuations in Just Toys Inc. and The Havana Republic and profiting therefrom.

On 21 Sep 2000, Jonathan James (cOmrade), 16, pleaded guilty to two counts of juvenile delinquency and was sentenced to six months detention for having penetrated DoD and NASA computer systems, intercepting 3,300 e-mail messages and stealing passwords. (He was 15 at the time. If he had been an adult, he reportedly would have received a sentence of at least 10 years.)

On 21 Sep 2000, Jason Diekman, 20, was charged with cracking into university (including Harvard, Stanford, and Cornell) and NASA computer systems, and stealing hundreds of credit-card numbers to buy thousands of dollars of clothing, stereo equipment, and computer hardware.

(Also, the Emulex stock manipulation case was noted in RISKS-21.02.)

[Sources include an article by David Stout, *The New York Times*, 23 Sep 2000, National Edition A9, plus AP item 22 Sep 2000.]

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

Date: Thu, 21 Sep 2000 11:14:39 +0200 From: "Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de> Subject: Concorde Problem Visibility (Kaiser, RISKS-21.05)

> Undoubtedly the passengers on the left side of the plane could see > the flames and the disintegration of the left wing.

Let me doubt it. The fuel leak came from under the wing approximately adjacent to the main gear and streamed backwards, burning in the process. The Concorde wing is a delta (unique among in-service passenger transports) and extends some meters rear of the last passenger cabin window. Airflow under the wing is rearward during takeoff, flight and landing; in particular it may be seen on the still pictures and video how the burning fuel streamed.

As far as I know, the left wing did not "disintegrate" until impact (but that depends on what "disintegrate" means).

These observations, however, go to substantiate Kaiser's point that the evidence of the problem was sparse to those on board.

Kaiser recounts the retrieval of evidence from various recorders. The issues concerning installation and use of recorders are broadly thus. Recorders are fallible devices, depending on what happens in the accident. More recorders mean more complex devices to go wrong, potentially hindering normal operations (fully working recorders are required for any normal operations); and more complex devices to attempt to analyse in a partly-destroyed state; finally, more discrepancies to resolve if their readings don't all cohere. External video recorders have been proposed, mainly to help resolve gear problems and other problems the pilots can't see (1979 DC-10 in Chicago; Concorde). Cockpit video recorders (which I call CVidR) have been proposed, and recommended by certain safety watchdog authorities. While they may have some benefits in identifying what was actually on frangible CRT displays at the time of an incident (2000 Crossair crash in Zuerich), pilots are concerned that the presence of CVidR may hinder their competent conduct of the flight in normal operations as well as in emergency situations; not only that, but that CVidR evidence could broaden the possibilities for civil litigation in directions detrimental to air travel as a whole.

Peter Ladkin

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

Date: 21 Sep 2000 19:50:53 -0400 From: uryse0d5@umail.furryterror.org (Zygo Blaxell) Subject: Re: Concorde crash report (Kaiser, RISKS-21.05)

> No one had ever before tried to recover one of these memory units live > from a damaged recorder ... they managed to move it intact and operational > to a working card.

I hope that "no one had ever before" refers to retrieving data from that specific type of memory unit or from that specific type of recorder, because anything less specific is inaccurate. ;-) I know of at least two previous incidents of flight data extracted from memory devices on crashed aircraft.

One company was able to extract engine data from a memory device on the same aircraft, but unfortunately the only press copy available to the public I can find for that device isn't very specific:

http://www.airdisaster.com/news/0500/25/news3.html

In the other case the circuitry around the memory was damaged, and it was necessary to repair this damage (microsurgery with an FIB) without disturbing the contents of the memory:

http://www.chipworks.com/News/11Swissair.htm

> So the flight data recorder didn't survive the crash unharmed, but a > perfect recording was recovered from the volatile digital medium within an > unprotected, vibration-sensitive, optional recorder.

It just goes to show that more is usually better when it comes to redundant storage devices on mission-critical systems. ;-)

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

Date: Thu, 21 Sep 2000 14:20:42 -0400 From: Pat <pat@machome.com> Subject: Ostrich Farming?

I would find it funny if it was not so scary: I thought I was doing the responsible thing when I sent a special notification to our subscribers, an article and link to a recent CERT advisory bulletin regarding a potential upcoming DDoS, and what to look for in a server audit. Albeit I knew there was many readers to whom this would not be of any use, we also have a lot of system managers on board. I felt ready and able to answer a predicted flood of questions this would generate. I was actually glad of the opportunity to sensitize some people to the issue of network security.

What I DIDN'T EXPECT were the numerous flames that would follow!

I was called by all possible names, accused of sending SPAM or disseminating rumors.

Six months have elapsed since last February's massive distributed denial-of-service attacks, yet the following article reports that there are still over 100,000 vulnerable computers all around. With billions of dollars of lost business, one would think people would take the issue more seriously!

See <http://www.internetnews.com/bus-news/article/0,2171,3_436031,00.html>

Pat St-Arnaud, Editor, MacHome Journal's Hot Tips Weekly pat@machome.com www.machome.com

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

Date: Sun, 24 Sep 2000 11:46:52 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Pentagon security gate goof, again

In RISKS-19.97, we reported on a Pentagon security system that injured the visiting Japanese Defense Minister and five others when a barricade was raised at the wrong time, in September 1998. That accident was attributed to a faulty sensor, and resulted in the installation of a new barricade control system.

On 5 Aug 2000, the same barricade sprang up under the German Defense Minister, who -- arriving for a Pentagon honors ceremony -- was injured and briefly hospitalized, along with the German defense attache' and an American security aide. [Source: Reuters item in *The New York Times*, 6 Sep 2000]

[Conspiracy in Artificial Intelligence?]

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

Date: Wed, 20 Sep 2000 21:08:09 -0700 (PDT) From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: U.Wisconsin alters photo to add "diversity" to student body

The University of Wisconsin has owned up to altering a 1993 photo of a crowd of white football fans, inserting the face of a 1994 black senior in an effort to have their brochure illustrate the diversity of the student body. [Digital editing capabilities of course make such manipulations ever easier, as we have noted here many times.] (For old-time programmers, this might make the fight song "On Wisconsin" be interpreted as a PL/I ON-condition.) [Source: AP item, *Palo Alto Daily News*, 21 Sep 2000. See also http://www.cnn.com/2000/US/09/20/photo.fix.ap/index.html.]

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

Date: Tuesday, September 19, 2000 6:15 PM From: Mike Lewis <mglewis@uswest.net> Subject: Why software fails

As is well known, entropy is a measure of the extent to which energy can be lost in statistical systems. It appears in many equations, particularly two

G = U - T * S, a thermodynamic equation, and

S = - k * log (p), the equation used to describe the entropy of information, that is, of files.

In these, S is the entropy, G is the Gibbs Free Energy, T is temperature, and U is internal energy; k is Boltzmann's constant and p is the probability.

In systems, the semantic and philosophical and epistemological boundaries two seemingly different forms of entropy inevitably become uncertain, they overlap, and the difference gradually becomes degenerate. That's when much software fails or becomes obsolete.

Software is very complex systems and it can readily be demonstrated that a well written, strong program competing for control of hardware against a badly written program can usually get control of the machine. This happens all the time as different software designers write their very best code to get control of the processor as quickly as possible in the face of competing software from other manufacturers. In short, software is vulnerable to statistical failures as well as to outright bugs or errors in coding, bad logic, etc. This problem is not very much discussed yet, but one supposes it will be in time.

An example might be a financial program. Ostensibly it has nothing explicitly related to thermodynamics, but the dimension of entropy appears both in software and in thermodynamics which occurs in winter in heating a house and in summer, cooling it. The financial program is required to have a sensible relation to income and expense, while the flow of enthalpy into and out from the house reverses direction each winter and summer. I have thought for a long time, after first seeing the connection, for a good example of a case in which we do not yet define how to predict just where the system will fail, and this is about the best I can propose.

I think that software's statistical entropy tends to drift around in the environment's thermodynamic entropy and this is one of the reasons why some failures are not yet completely understood--the entropy dimension is not taken explicitly into account in designing systems, except in the solid state quantum mechanics of the CPU and other chips in the machine.

Solutions to this problem will require the assumption, in early planning of the system, that eventually the software file entropy, the electron entropy of the silicon, and the environment's thermodynamic and other statistical entropy will always inevitably become indistinct, and then plan the system knowing they cannot be held absolutely distinct from the outset.

It should be noted that the word "environment" is extremely general, and includes that of the climate, as well as of the surroundings of the planet. Also, the time scale is very general, ranging from the geological time scale of the evolution of life, to the very short durations of time found in computers. This is because thermodynamic spectra, for instance contain and are sensitive to energy-stable terms, which do not vary in time where they are involved with immediate electronic transitions in atoms and molecules.

Interesting speculations may be found on, for instance, the burning of fossil fuels to put carbon back into circulation, because early life forms--mainly plants--from which these deposits were formed, were apparently not able to measure or control the dimension of entropy. Are we recirculating all that carbon now because we can deal now with entropy? That is, though, beyond the scope of my intention here.

Mike Lewis <mglewis@uswest.net>

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

Date: Thu, 21 Sep 2000 09:16:31 -0700 (MST) From: Richard Schroeppel <rcs@baskerville.CS.Arizona.EDU> Subject: Filtering, censorship, silence: Who owns the language?

> Subject: OPEC site hacked > ... > when I say to you guys to get your collective a**es in gear with the crude > ... > [http://dailynews.yahoo.com/h/nm/20000913/od/website_dc_1.html, PGN-ed > with ** filtering]

Peter, does this mean that you've decided to accommodate to filtering software as the "lesser evil"? [See NOTE] I think this issue deserves more discussion with your audience. We probably won't be talking about b****t cancer, but we've already seen too many amusing examples of filters gone am*k.

What are the issues when persons impose communications restrictions by threatening to cutoff communications (or doing it) that don't adhere to policy? Typically the person defining the restrictions is inaccessible to reason, being buried within a large impersonal organization. Often the restrictions are a trade secret. The rejected mail gives no particular notice to either the intended recipient or the sender -- the discard is silent.

I operate a couple of "ascii text only, please" mailing lists, but it's a struggle to maintain what's become a minority format.

Most of the NIST AES documents are in PDF-only, and not readable by a text-based terminal. (From a standards organization!) The IRS tax forms and instructions aren't available as text. The instructions should be grep-able, but aren't. And so on.

This seems like a losing battle to me, but I still think a general discussion is long overdue of the consequences that follow from "I'll only communicate in my special language." I've always assumed that the pressure was toward a common language, but the business interests of Microsoft, Adobe, IBM &c seem to operate in the other direction.

We might require by law that govt stuff be available as text (where possible), but that's only part of the larger issue: "Who controls the terms of communication?"

Rich Schroeppel rcs@cs.arizona.edu

[NOTE: Actually, no. In this case there is no lesser of weevils. Sometimes I get many filtering bounces because I have let challenging words go through. But I have also been assiduously informing RISKS recipients that their filtering is stupidly overaggressive in response to all of the bounces I receive each time I send out an issue. PGN]

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

Date: Thu, 21 Sep 2000 11:28:58 -0400 From: "Prodin, Timothy (T.R.)" <tprodin@ford.com> Subject: Re: Decimalization and Ford Stock Splits (Carroll, RISKS-21.05)

On 7 Aug 2000, Ford completed its Value Enhancement Plan, a somewhat complicated stock transaction where Ford created a new company (Ford Value Company) and issued a new stock. Ford Stock holders of record on July 27th had the option of taking the new common or Class B stock plus 1) $20 per share, 2) a fraction of the new common stock that would be the equivalent of $20, or 3) a fraction of cash and fractional shares that would maintain their percentage ownership of all outstanding shares constant.

For the last two options; the fraction of cash and fraction of shares depended on the total number of outstanding shares of the old company.

At the end of the exchange and disbursement; the new company transformed back into the old company; and trades on the NYSE as F.

The final numbers wound up such that if you took the full fractional new share with your matching full share; you received an additional 0.748 additional share.

Tim Prodin

[Also commented upon by various other readers. Many thanks to you all for helping correct the record. PGN]

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

Date: Wed, 20 Sep 2000 20:08:29 -0700 From: Martin Minow <minow@pobox.com> Subject: Re: Identity theft (Ellison, RISKS-21.05)

> Now -- how do we get consumer protection laws that make it clear that a > consumer is not liable for any debts incurred by someone claiming to be > him/her ...

Having recently been on the receiving end of identity theft, I'm a bit more optimistic than Carl. I solved my problem by reading the back page of the credit report, where it provided addresses of the federal agencies that regulate collection bureaus, banks, and similar organizations. Letters to the agencies resulted in one "opening a case" and, eventually, a letter of apology from the bank in question (who hadn't answered my previous requests/complaints). I used an account record book -- a bound notebook with numbered pages -- that had dated notes of every interaction I had with the banks and credit card agencies, interspersed with software notes, interesting URL's, telemarketing caller numbers, and other scribbles. This let me document my complaints with the specific dates and times that I attempted to resolve the problem.

Martin Minow minow@pobox.com

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

Date: 21 Sep 2000 11:43:47 +0300 From: Camillo.Sars@F-Secure.com Subject: Re: Qualcomm CEO's laptop vanishes (Lesher, RISKS-21.05)

As I have some experience in the field, having lead the development of one of the tools David is referring to, I'd like to point out a few other risks associated with this issue.

Using real (and real-time!) encryption on data files does help against the threat of unauthorized information disclosure. Which is good. But, as usual, increased security in one field can lead to increased risk in another. Encrypted files are subject to several threats.

The primary risk is threats against integrity. Tweak a bit in an encrypted file, and at least an entire block is corrupted *). Usually the entire file can be considered lost, and a backup needs to be restored. I will not go into the discussion about how to properly encrypt backups here.

Another threat is the risk caused by loss of the encryption key. Strong encryption has the nice property that nobody can get the data without the correct key. Strong encryption has the less nice property that not even the owner of the information can get the data without the correct key. I have seen this happen. It is not a nice situation.

> It's also a message to crypto companies. Create real tools for this task, > ones that even C[E,F,T]O's can grok how to use {1}. A recent USENIX study > reported that a large percentage of users failed to use PGP correctly.

I have come to the conclusion that persons that are not trained in security must rarely or never be called upon to make security-related decisions. As Ross Anderson put it in his paper "Why Cryptosystems Fail": ..."most security failures are due to implementation and management errors." I have taken to interpreting this in a very broad sense.

> {1: Getting them to follow practices is the 2nd half of the problem; as the > Deutch case demonstrates....}

Thus, I second Ross Anderson's view that a paradigm shift is required. Let's not only make systems that are easier to use correctly. Let's make systems that are difficult to use incorrectly.

Camillo Sars

*) Tweaking a bit in an encrypted file should invalidate data. If it does not, the system is vulnerable to replacement attacks. E.g. copying the encrypted salary of the CEO and pasting it over the encrypted salary on your own paycheck. Which would be nice.

Camillo Sars <Camillo.Sars@F-Secure.com> http://www.iki.fi/ged/ Researcher, F-Secure Corporation http://www.F-Secure.com

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

Date: Thu, 21 Sep 2000 11:02:37 -0400 (EDT) From: "J.D. Abolins" <jda-ir@pluto.njcc.com> Subject: Re: Risks of using HTML Mail and HTTP proxy "censorware" together

This risk underscores monitoring tools' user to realize that their tools have limitations. The assumption may be that a "hit"on a forbidden site means that a particular user willfully went there. Wrong, as Dan Birchall's posting shows.

I have been testing the recently reported MS Office document Web bugs to see if they can be used to rack up hits on workplace HTTP "censorware." The tests aren't finished but here's the concept. Insert spacer gif URLs from a banned site in an "appropriate for the workplace" Word document, Excel spreadsheet, or PowerPoint presentation. When the document is opened, it should attempt to pull the graphic form the "banned" Web site and, thus, score hits on the "censorware." A document could be loaded with multiple bugs, each from a different banned site.

It is also possible to resize a URL-based image so it is hard to see. So it might not be only transparent gifs that could be (mis)used in this manner.

People investigating hits on banned sites should look for other evidence besides the "censorware" logs and not assume automatic guilt.

Beside nearly invisible graphics in the HTML e-mail, there is the risk of spoofed links. The e-mail text says the link goes to one place while the underlying HTML gives a different HREF. This has been reported elsewhere. A variant can be to use the file:// type of URL to bring up locally accessible files. Sometimes this is used as a Web joke where a visitor is convinced that the Web site can see her C: drive or /etc/passwd file. If the sender of HTML e-mail has a good idea of the systems used by the recipient, the spoofed links can be tailored to use the file:// URLs or the res:// URL.

J.D. Abolins, Meyda Online -- Infosec & Privacy Studies http://www.meydabbs.com

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

Date: Sat, 23 Sep 2000 12:33:58 GMT From: totototo@mail.pacificcoast.net (Rodger Whitlock) Subject: Artificial Intelligence strikes again

One of our secretaries at work related an interesting tale: she and her husband went to buy gasoline, using their Visa card at the pump. It was rejected. They tried another station. Same thing. They tried to buy flowers for an aged relative. Same thing.

She phoned the issuer (Canadian Imperial Bank of Commerce - CIBC) and asked what was going on.

The response was that the computer had detected an "unusual pattern of purchases" and put a freeze on the card. The unusual pattern was the use of the card to pay a ferry fare to Vancouver and when Visa phoned to double check, there was no one home to answer the phone. Naturally: the whole family was on the ferry!

As this secretary said, what would have happened if the card got frozen after flying to Europe? Badly thought-out computer wonkism strikes again.

Regular RISKS readers probably recognize the syndrome.

Rodger Whitlock, Victoria, British Columbia, Canada

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

Date: Sat, 23 Sep 2000 14:02:43 -0700 From: "Conrad Heiney" <conrad@fringehead.org> Subject: SBC Calling Card PIN

SBC Communications, through my local telephone company (Pacific Bell) has reissued their telephone "Calling Card" telephone cards. The new cards are intended to be used worldwide and to replace previous local cards.

The card is marked with the subscriber's name and telephone number. There is also a Personal Identification Number which is provided separately, the idea being that both the telephone number and the PIN need to be present for authentication.

However, there is a space on the card for your PIN, and you are instructed to immediately write the PIN on this space so you won't forget it.

This contradicts the policy of bank ATM cards and other PIN-based systems, in which the PIN is intended to be memorized and customers are instructed in large capital letters not to write the PIN on the card or store it with the card.

The risks here are twofold:

1) The PIN is useless if the card is lost or stolen 2) Consumers will be confused by contradictory policies from different organizations and will likely write their PIN on every card they use.

Two cheers for self-sabotaging authentication systems!

Conrad Heiney conrad@fringehead.org http://fringehead.org/

[Several other messages relating to credit cards per se are not included here. PGN]

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

Date: 15 Aug 2000 (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 20" for volume 20] 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 21.06 ************************