Text File

precedence: bulk Subject: RISKS DIGEST 19.60

RISKS-LIST: Risks-Forum Digest Friday 27 February 1998 Volume 19 : Issue 60

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: [Running way behind.] CyberAttack on the Pentagon (PGN) Former Director of the NSA says "no" to key escrow (PGN) Year 2100 compliance? (Tsutomu Shimomura) COMPAQ usability problem (Pete Mellor) Shuttle conversation; April already? (PGN) First Cybersex Pregnancy (Anthony E. Scandora Jr.) A little accidental porn-in-the-morn (PGN) DES-II-1 challenge cracked (David McNett) Re: Markus Kuhn and Ross Anderson's Soft Tempest (Lloyd Wood) Risk: Massive NT Outage due to Registry corruption (Mike Andrews) Airport Big Brother Blocks Buggies (Marcus J. Ranum) Dennings' "Internet Besieged: Countering Cyberspace Scofflaws" (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Fri, 27 Feb 1998 10:25:49 PST From: "Peter G. Neumann" <neumann@chiron.csl.sri.com> Subject: CyberAttack on the Pentagon

[This is pretty much what I said earlier this morning in an interview with James Glave of Wired News (something is expected to appear at http://www.wired.com), although I have extended it somewhat for RISKS. PGN]

The operative phrase seems to be ``smoke and mirrors'' in the case of the Pentagon HackAttack. Yesterday we were told by John Hamre (Deputy Secretary of Defense) that this attack was ``the most organized and systematic the Pentagon has seen to date''. Today we are told that it was just a bright high-school kid (or maybe a few) who was able to penetrate so many systems. Given the incredible collection of breaches of so-called secure systems over the past few years, one can conclude only that the computer-communication infrastructure stinks, and that the U.S. Government is foolish to believe or pretend that it is secure in the first place. And if unclassified are so weak, what should we expect of the classified systems?

On the *other* hand, perhaps this is a con game. You put out a system with miserable protection and hope that someone breaks it. Then you can ask for millions of dollars more to perform further palliative protections, rather than getting to the core of the problem -- significantly ratcheting up the security of the infrastructure. Or perhaps it is just another bogus argument for mandatory key escrow or whatever else it might euphemistically be called (currently, ``key recovery'' a.k.a. ``sound key management''). The real irony of is that we are continually told that there are no undue risks in key-recovery crypto systems. But, if our infrastructure is *this* bad, how can anyone hope to protect what is perhaps most critical, namely, the crypto keys!

[On the *OTHER* other hand, if the Y2K problem is causing the Government so much grief, how can anyone expect them to do security properly? Date arithmetic is not difficult if you know what you are doing. Security is much harder. Although, I note that in date arithmetic you are often dependent on other systems, not just your own. The same is true of security.]

[Check out my own URL for a bunch of related items on this subject, including House and Senate testimonies on the allegedly secure infrastructure (http://www.csl.sri.com/neumann/).]

[By the way, there's *is* good stuff in the research community, such as the Rivest-Lampson Simple Distributed Security Infrastructure (SDSI) (http://theory.lcs.mit.edu/~rivest/sdsi) as just one example. It is high time some decent authentication with strong encryption found its way more vitally into commercial systems. Which gets us back to crypto policy as well as legislative attempts to link certificate keys and key recovery! But technology is not enough. Sanity and common sense are also necessary.]

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

Date: Fri, 13 Feb 98 10:16:45 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Former Director of the NSA says "no" to key escrow, TTP etc

http://www.us.net/softwar/mcc.html This is a snip from an interview of Adm. Mike McConnell - former Director of the NSA under Presidents Bush and Clinton:

SOFTWAR: What is your view of the Clinton administration's current export restrictions on encryption?

McConnell: It was our view in the 80s that strong crypto will happen. The export restrictions were only meant to slow down foreign development. It was a matter of national security. Today, it is not a matter of national security. The FBI Director has made it a law enforcement issue involving domestic controls. The Department of Justice and the FBI are still seeking to "mandate" key escrow.

SOFTWAR: The Clinton Administration is pushing KEY RECOVERY encryption as a tool to catch criminals and terrorists. Could this type of software be abused by foreign powers or dictators to persecute dissidents and political opponents?

McConnell: Can Key Recovery be used against dissidents and political opponents? In a word, YES.

[See SOFTWAR http://www.us.net/softwar ; the interview is at http://www.us.net/softwar/mcc.html and it it is fascinating. PGN]

[BTW, how many third parties will YOU trust? PGN]

[redundant incorrect URL fixed in Archive copy.]

[inadvertent stray text removed in ARCHIVE COPY. PGN]

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

Date: Sat, 21 Feb 1998 19:06:26 -0800 (PST) From: Tsutomu Shimomura <tsutomu@ariel.sdsc.edu> Subject: Year 2100 compliance?

Excerpted from the American Megatrends ("the world's premier BIOS provider") web site: http://www.amibios.com/support/2000.html

> Year 2000 compliance means that the internal BIOS date and time clock will > continue above the date 1999. It will not reset it self after 1999 to the > date of 1980. It will continue to the date of 2099 before resetting to 1980.

Tsutomu Shimomura tsutomu@ucsd.edu +1 619 534 5050 University of California at San Diego/San Diego Supercomputer Center, USA

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

Date: Sat, 21 Feb 1998 13:02:20 +0000 (GMT) From: Pete Mellor <pm@csr.city.ac.uk> Subject: COMPAQ usability problem

COMPAQ is replacing the on-screen instruction "Press any key" with "Press the return key", in an attempt to reduce the flood of telephone calls to their help desk asking where the "Any" key is.

[Source: UK press, quoted on "The News Quiz", BBC Radio 4, 21st Feb. 1998]

Pete Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB

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

Date: Thu, 19 Feb 98 9:15:19 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Shuttle conversation; April already?

[Note: The last previous Friday the 24th was in October 1997, and the next one, ominously, is in April 1998.]

From THE WEEKLY UNIX NEWSPAPER, London, 16-20 Feb 1998, Issue Number 667

On Friday the 24th, I was watching the NASA Channel on cable TV to see how the experiments and Shuttle crew were doing. The men on board needed to send some adjusting instructions to the automated setups doing experiments in the cargo bay, and they were using a laptop to do the sending. As some of you may have heard, there was a "computer problem" on board as reported by CNN. The dialog between the crew and the Johnson Space Center (JSC) went something like this:

Crew: Urgent, Johnson, we can't get a DOS prompt! JSC: Press "C:<enter>". Crew: Heck, we're not familiar with all this. JSC: What screen are you looking at? Crew: It says "My Computer", and, er, various other icons. JSC: Click on "Start", and then "Shutdown". Crew: You click the "Start" button to shut down? JSC: Yeah. Isn't it obvious? Crew: Somebody get me an aspirin. JSC: Just hit the damn "Start" button. Crew: We can't do that. It didn't load a mouse. JSC: Didn't load any mouse at all? Crew: Well, yeah, a PS/2 or something. But we don't have one of those. JSC: Okay. Press Alt + Esc. Crew: And what does that do? JSC: It should help. Crew: Negative. JSC: Stand by, will attempt to replicate the problem down here. Crew: Roger.

<Long Pause>

JSC: Okay then. Double-click on the MS-DOS icon. Crew: I don't have a mouse. JSC: Go to the backup plan. Crew: Which is what? JSC: Dock with the Russians. They have a Unix workstation you can borrow.

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

Date: Tue, 3 Feb 1998 17:45:40 -0600 From: "Scandora, Anthony E., Jr." <scandora@cmt.anl.gov> Subject: First Cybersex Pregnancy

My favorite newspaper, the *Weekly World News*, in last week's (27 Jan 1998?) issue, reported that a woman who has been having an intimate relationship via the Internet with a man she has never physically met is with child. She is considering a paternity suit.

Tony Scandora, Argonne National Lab, 630-252-7541 <scandora@cmt.anl.gov>

[Remember, please, this is a newspaper that apparently uses a computer to generate the plot lines for its stories. PGN]

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

Date: Fri, 27 Feb 1998 10:25:49 PST From: "Peter G. Neumann" <neumann@chiron.csl.sri.com> Subject: A little accidental porn-in-the-morn

From at least 1 Feb 1998 until it was fixed on 10 Feb, at 5:20am each morning TCI gave San Francisco's Channel 27 viewers 40 minutes of free porn from the Adam-and-Eve network on its pay-per-view preview channel. (However, there were interruptions for commercials advertising similar stuff.) The glitch was attributed to the computer system turning off the masking supposedly provided by the scrambler, ahead of schedule. [Premature emasculation?]

[PGN Stark Abstracting from Nando.net Scripps-McClatchy Western item, by Anastasia Hendrix in the San Francisco Examiner, 12 Feb 1998, http://www.techserver.com/newsroom/ntn/info/021298/info23_29316_noframes.html Thanks to Aydin Edguer <edguer@MorningStar.Com> for noting this one.]

[No telling what we'll see when Y2K hits their computer -- perhaps total unscrambling!]

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

Date: Tue, 24 Feb 1998 23:38:58 -0600 From: David McNett <nugget@slacker.com> Subject: DES-II-1 challenge cracked

[Sent to RISKS courtesy of Dave Farber's IP list.]

Original-Subject: [RC5] [ADMIN] The secret message is...

[http://www.distributed.net/des/nugget.txt]

Once again I have the great privilege of coming to you with good news.

It is with great pleasure (and a sigh of relief) that I can now inform you that the DES-II-1 challenge has been successfully met by distributed.net.

The winning key to the challenge was detected and submitted to RSA Labs at 02:26 GMT on Monday, 23-Feb-1998.

The correct key, 76 9E 8C D9 F2 2F 5D EA, revealed the words which we've been anticipating these past 39 days:

"The secret message is: Many hands make light work."

(If you ask me, this is a nice nod in our direction. Thanks, RSA Labs!)

In addition to proving that 56-bit DES is no longer sufficient for protecting valuable information, we've now also proved that blind luck need not be a factor in brute-force decryption attacks. The original DES Challenge and the more recent RC5-56 wins were fortunate and did not have to sweep a significant portion of the keyspace. This time around, however, we managed to complete almost 90% of the keyspace and have now proven that even when the law of averages chooses to catch up to us and forces us to pay our dues, we are still an unstoppable force. Our collective victory is all the more impressive when you consider what we had to accomplish to achieve it.

We tested sixty-three quadrillion keys. That number is simply staggering.

Assuming *0* growth between now and July, we'll be able to sweep the entire DES-II-2 keyspace in just under 29 days. That's assuming that we do not recruit another person, don't add any more machines, and are even more unlucky next time. I daresay at least one of those assumptions is probably false.

I'd invite all of you to join us in IRC (efnet, #distributed) for a rowdy victory party. Take a breather. Sit back and watch your clients automatically roll over to RC5-64.

The only other issue at hand is *who* found the key. The person who found the winning key has politely asked to remain anonymous. Rest assured, I've been in contact with them and they know they've won. They will be receiving their full share of the prize and are quite excited about the victory. All I'd ask is that we all respect this person's wishes and not bother the list with public speculation as to their identity. I'm sure we all appreciate just how important privacy and anonymity can be.

Here are some numbers to chew on while the stats are down:

Project statistics: Start of contest: January 13, 1998 at 09:00 PST Start of distributed.net effort: January 13, 1998 at 09:08 PST End of Contest: February 23, 1998 at 02:26 PST

Size of keyspace: 72,057,594,037,927,936 Approximate keys tested: 63,686,000,000,000,000

Number of 2^30 (average) keyblocks: 67,108,864 Number of keys in average keyblock: 1,073,741,824 Peak blocks per day: 5,540,982 Peak keys per second: 34,430,460,000

The unencrypted message: Many hands make light work

Computing equivalents:

Distributed.net is equivalent in processing power to:

11,264 DEC Alpha 21064 533s 15,316 Sun Ultra I 167s 22,393 Intel Pentium II 333s 68,859 Macintosh PowerPC 604e/200s. 41,712 Intel Pentium 166s 399,374 Intel 486DX2/66s 7,446,033 Intel 386SX/20s

(based solely on DES client performance)

Prospective:

If Keys were dollars, we could pay off the U.S. National Debt in 6.25 minutes

If Keys were pennies, we could buy 536249385 Mazda Miatas each day.

If Keys were pennies, we could buy 256728249 Jeep Cherokees each day!

If you printed a single page to represent each key block as it was checked and placed those pages in a stack, it would grow 12.83 inches taller every minute.

If blocks were liters of Dr. Pepper, we could produce 6381493 six-packs each day.

If Key Blocks were cheeseburgers, fries, and a large Dr. Pepper, we could feed the entire city of Toronto, Ontario lunch each day.

(On a personal note, It sure feels nice to be doing RC5 blocks again. I feel like I've just slipped on an old, comfortable pair of loafers that were lost in the attic for two months.)

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

Date: Fri, 13 Feb 1998 20:39:04 +0000 (GMT) From: Lloyd Wood <L.Wood@surrey.ac.uk> Subject: Re: Markus Kuhn and Ross Anderson's Soft Tempest (RISKS-19.59)

In RISKS-19.59 Ross Anderson is quoted by Minow et al. as saying: > <http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf> > In its simplest form, our technique uses specially designed `Tempest > fonts' to make the text on your screen invisible to the spooks.

Specially designed fonts as such aren't required; with the advent of routines to generate smoothed anti-aliased fonts on personal computers, the detection of text on a CRT as discussed by Anderson et al is made slightly more difficult as the edges are already smoothed, removing high-frequency signal components.

Modifying the system bitmap text anti-aliasing routines, rather than the display drivers as the paper suggests, to 'lowpass-buffer-alias' (for lack of a better term) all output fonts as directed is rather easier than redesign of individual fonts. It offers more transparent results, and the resulting security solution is more easily distributed to and accepted by users than a host of new fonts or a replacement display driver would be.

On the Macintosh, you'd generate lowpass-buffer-aliased SoftTempest fonts by modifying the source to Landweber's "Greg's Hack", now his shareware SmoothType (source and pointers to antialiasing algorithms available from http://www.kaleidoscope.net/greg/smoothtype.html [CORRECTED IN ARCHIVE.]

On Windows, Microsoft's own antialiasing routines - a later product, also called Smoothtype - are included in their Plus! Pack and with Explorer 4.0. [previously noted by bos, RISKS 19.42]

I'd worry about a Tempest virus that polled a personal computer's CD-ROM drive to pulse the motor as a signalling method:

* Modern high-speed CD-ROM drive motors are both acoustically and electrically noisy, giving you two attack methods for the price of one;

* Laptop computer users without CRTs, and the PC users that can afford large LCD screens instead of CRTs, often have CD-ROM drives;

* Users are getting quite used to sitting patiently while their CD-ROM drives grind away for no visibly obvious reason (but that's quite enough about the widespread installs of software from Microsoft CD-ROMs that prompted Kuhn's investigation in the first place.)

<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641

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

Date: Thu, 12 Feb 1998 11:23:36 -0500 From: mandrews@fd9ns01.okladot.state.ok.us Subject: Risk: Massive NT Outage due to Registry corruption

[This was sent me by someone at a Fortune-100 manufacturer, and is anonymized and sanitized at the original sender's request. It is genuine.]

> The recent power fluctuations here in [placename] corrupted the NT > registries in our [server-community-names]. As a result, our entire NT > network (>10K machines) is down, and has been since 5 am this > morning. (I'm doing direct IP to [product-name] to do mail. Thank God.) > Once the registries got corrupted, the databases of user signons went, > too. And, of course, the tape backups won't load because NT requires a > timestamp somewhere in the guts that the tape image doesn't match to the > clock. So every NT server, and most NT workstations, won't do anything > except local work.

> If this were just office workers, it would be annoying enough. But the > [product name] servers require such close tie-ins to the machine accounts > that they are dead -- guess what helps run our factories? Can you say loss > of $1M+ per hour?"

> Why am I telling you? Because our NT guys have suddenly realized that this > is a good candidate for a denial of service attack: once the registries > get corrupted, the entire resource domain has to be reloaded by hand -- > and that apparently includes desktops. If you have ideas on how to go > check the registries on your NT servers, I'd suggest you go do so.

In another letter, the original sender elaborates:

> If you are recovering from this, every desktop user will have to > delete/disable their <user>.pwl file to be able to get back on the > network, because that file hardcodes which domain server they are > on. HOWEVER, if they do that, they can then not get into any other service > on their desktop for which they've stored the password, because they're > all in that file. if the user doesn't remember the password, they're SOL, > because the latest patch from MS keeps the *.pwl files from being hackable > by the "standard" hacker and pwledit tools -- but it is also rendered > unreadable to the MS standard pwl editor, too.

The total outage was in excess of 12 hours, and the loss-of-revenue from the outage is estimated to be more than $10 million.

Mike Andrews, D.P. Director, Okla. Dept. of Transportation mandrews@fd9ns01.okladot.state.ok.us

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

Date: Mon, 09 Feb 1998 17:10:27 -0500 From: "Marcus J. Ranum" <mjr@nfr.net> Subject: Airport Big Brother Blocks Buggies

Baltimore Washington International Airport recently installed a system "for my protection" "with my tax dollars" which delayed me considerably in getting home one night.

About a month ago, I noticed small video cameras appearing at the exit lanes of the parking lot. I assumed that they were to record license plates in the event of someone trying to skip paying, or using a stolen credit card. Since my car is kind of short, they've already had to ask me several times to back up so that the camera could get my plate. I usually pay with a credit card so I didn't think this was an especially big deal. Now, I'm not so sure at all.

The other night I got back from a late trip, and when I came to pay the lady apologized and explained that there were some delays "because the system is running slow." I said that was no problem because I was paying cash, handed her exact change, and waited for the bar to go up. She was still fiddling with a computer and I began to get irritated and asked her to let me leave. "I can't do that, the state police computer has to clear your tag, first!"

I sat there for quite a while, and while I was waiting (maybe a total of 10 minutes) I got more details from her. It seems that "to protect us" Maryland's State Police established the system. Either she was no rocket scientist, or someone had lied to her about the purpose of the system, because she was convinced it was to prevent theft of vehicles. I tried some logic: "if someone was stealing my car from the lot, I would still be away on my business trip, so I wouldn't have reported it stolen, yet." I suppose that a stupid criminal who was going to rob cars would car-pool into the lot with a buddy, but I have to wonder who/what they are really trying to track. My paranoia was heightened by the state police cruiser that was idling in the vacant lot just across the access road.

As a computer security guy, I worry about these things more than most people. But, I suppose that the presence of this system means there is a record someplace of who and when people went to a major airport. Since it's presumably not "sensitive" information, the security on that record is probably lousy. (I've seen how government agencies usually handle any computer records that are not CLEARLY sensitive) :( I guess the technology will appear elsewhere - perhaps at stop lights in major intersections "to protect us" by detecting cars that have somehow been identified as "worth catching."

When you go to the airport they ask you "has any unknown person asked you to carry anything in your bags?" I guess the savvy frequent flier will make sure they never travel to BWI with an unknown person or in an unknown car -- I am just Real Happy that the police computer didn't have my tag number in its database as a dangerous, armed felon. I see all kinds of potential for disaster in the event of a license tag confusion. I got off lucky because all Big Brother did that evening was waste 15 minutes of my time and give me a good cardiovascular workout by raising my blood pressure a notch. It's nice to see my "tax dollars at work." :-P

Marcus J. Ranum, CEO, Network Flight Recorder, Inc. http://www.nfr.net home - http://www.clark.net/pub/mjr

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

Date: Fri, 20 Feb 1998 08:28:41 -0800 From: "Rob Slade" <rslade@sprint.ca> Subject: Dennings' "Internet Besieged: Countering Cyberspace Scofflaws"

BKINBSGD.RVW 971120

"Internet Besieged: Countering Cyberspace Scofflaws", Dorothy E. Denning/Peter J. Denning, 1998, 0-201-30820-7 %A Dorothy E. Denning denning@cs.georgetown.edu %A Peter J. Denning %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1998 %G 0-201-30820-7 %I Addison-Wesley Publishing Co. %O 416-447-5101 fax: 416-443-0948 800-822-6339 617-944-3700 %O Fax: (617) 944-7273 bkexpress@aw.com %P 547 p. %T "Internet Besieged: Countering Cyberspace Scofflaws"

As with the earlier "Computers Under Attack" (cf. BKDENING.RVW), this book is a collection of papers related to the titular topic. This text is not just an updating of the earlier work, although some of the same papers appear, having been revised and updated. It is also more narrowly focussed, with sections discussing the worldwide network, Internet security, cryptography, secure electronic commerce, and finally dealing with law, policy, and education. The anthology style is well suited to a constantly changing and still emergent field.

Under the scope of the worldwide network, there is an initial review of the history of the net by Peter Denning. Dorothy Denning follows up with an overview of system security breaking methods over networks. (While it is a fine and readable piece of work, the essay is not quite as riveting as the interview with a system cracker in "Computer Under Attack.") As usual, the most interesting papers deal with real case studies, such as the attack on Rome Labs. Peter Neumann's brief piece on the RISKS-FORUM archives indicates the value that the net can be in protecting itself, since RISKS acts as a kind of repository memory of attacks and weaknesses. The even briefer article on securing the information infrastructure is a kind of call to arms to pay attention to security in important control systems. Part one is finished off with Eugene Spafford's computer virus paper; by now the classic short work in the field.

Part two, specifically looking at Internet security, starts with another case study; that of the Berferd attack on Bell Labs. This is followed by an overview of network security threats and protective tools. Two articles look at specific types of assaults: "sniffing", which works because of the broadcast nature of many means of media access, and "spoofing", which works because of the automatic configuration and repair protocols intended to provide reliability. An overview of password use looks primarily at technologies to make password cracking more difficult. Four security tools are introduced, a GPS (Global Positioning System) based authentication scheme, Tripwire, DIDS (Distributed Intrusion Detection System), and SATAN (Security Administrator Tool for Analyzing Networks). Java security also gets a thorough examination.

The section on cryptography starts with the development of the Data Encryption Standard. (It is indicative of the rate of change in this field that the following article, looking at the breaking of two recent cryptographic systems, doesn't cover the cracking of DES. The book was published just before that happened.) There is a detailed essay on the Internet Privacy Enhanced Mail (PEM) protocol, and a more conceptual paper on authentication for distributed networks. There is also a taxonomy, or method of classifying, for key recovery encryption systems.

Security of electronic commerce covers electronic commerce itself, atomicity in electronic commerce (which determines the general usefulness of a system), another overview of Internet security vulnerabilities, digital forms of money and cash, ad identify misuse and fraud.

The final part looks at social issues. The law enforcement in cyberspace address, coming as it does from a US federal agency, is unsurprising in its call for key escrow. Dorothy Denning follows up with a more reasoned review of the market forces. Bruce Sterling gets two cracks at computers and privacy. Eugene Spafford gets the hardest job--looking at computer ethics--and does a decent and practical job. There are two examples of use policies from universities, and a final, very interesting, article on the inclusion of data security topics and activities in the teaching of computer science concepts (rather than the other way around).

Even within this limited frame of reference, the book cannot be exhaustive. When you start to consider the gaps that are missing, like the international nature of many activities that make them essentially immune to legal remedies, you also find that whole fronts of the Internet siege are unmentioned, or only tangentially referred to. Spam, fraudulent scams, and chain letters claim many more victims than do system crackers.

Still, this work is both interesting and valuable. It should be of particular use to the student or teacher of data security, although there is much to hold the attention of any interested individual.

copyright Robert M. Slade, 1997 BKINBSGD.RVW 971120

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

Date: 1 Apr 1997 (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 <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] => 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.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.60 ************************