Risks Digest 20.90

[risks@csl.sri.com]

[: hacktivism :]

RISKS-LIST: Risks-Forum Digest  Monday 5 June 2000  Volume 20 : Issue 90

   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/20.90.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
"Incompatible software" blamed for phone-book fiasco (PGN)
Remote control of your car via GM's OnStar (Armando Fox)
India plans to piggyback internet on railway control cables (R Bakowski)
Trash compactor kills shoplifter (Chris Meadows)
How not to distribute white papers (Avi Rubin)
1984 comes late to the UK (Martyn Thomas)
Social engineering in the real world (Bruce Schneier)
Computer Security: Will We Ever Learn? (Bruce Schneier)
Symantec's antiviral returns false positives on network.vbs (Richard Thieme)
Re: Junk-mail filters (Amos Shapir, Ron Bean, Ray Todd Stevens, 
    Markus Peuhkuri)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 5 Jun 2000 11:39:08 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: "Incompatible software" blamed for phone-book fiasco

Pacific Bell has apparently printed 400,000 new phone books that include
names, phone numbers, and addresses of telephone customers who are supposed
to be unlisted.  The California state public utilities commission has
granted a request from Cox Communications for a restraining order against
Pac*Bell.  Incompatible software is blamed, but perhaps it was human error
in forgetting to remove the protected fields from a retrieval request?
Perhaps one of our RISKS-reading insiders can enlighten us.

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

Date: Wed, 31 May 2000 15:33:20 -0700
From: "Armando Fox" <fox@cs.stanford.edu>
Subject: Remote control of your car via GM's OnStar

At WWW-9 in May, there was a presentation about the OnStar system which will
be standard equipment on some GM vehicles and a factory-installed option on
most others.  OnStar uses cellular telephony and GPS to provide
location-specific services to drivers; current services are provided by a
human being ("advisor") who answers the phone when you push the OnStar
button in your car, but there is provision for data services to be delivered
later.  Look at http://www.onstar.com - the system is already in production
operation in some cars.

One interesting feature is a control channel back *into* the car: the OnStar
transceiver is integrated with some of your car's control systems, so that
it can (upon receipt of the correct signal from an OnStar advisor) unlock
the doors, flash the headlights, honk the horn, etc.  Presumably some of
these features are in place to assist rescue personnel -- OnStar
automatically dials a 911 advisor if it detects you've had an accident (e.g.
if it detects that the airbag was deployed).

The obvious risk: If I were a cell phone data services hacker, I'd know what
my next project would be.  I asked the OnStar speaker what security
mechanisms were in place to prevent your car being hacked.  He assured me
that the mechanisms in place were "very secure".  I asked whether he could
describe them, but he could not because they were also "very proprietary".
*Sigh*

Armando Fox <fox@cs.stanford.edu>, Assistant Professor, Computer Science
Stanford, CA 94305-9040 +1 650 723 9558  http://gunpowder.stanford.edu/~fox

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

Date: Wed, 31 May 2000 08:05:58 -0400
From: "R Bakowski" <ron@belwood.com>
Subject: India plans to piggyback internet on railway control cables

May 30, 2000

http://news.bbc.co.uk/hi/english/world/south_asia/newsid_769000/769635.stm

As reported by the BBC today, India has embarked on a pilot project to bring
affordable Internet service to rural India by exploiting the "almost always"
available spare capacity of the electrified railway tracks' communications
and control cabling. Included in the plan are cybercafe kiosks at railway
stations along the project's initial 40km stretch of track as well as
wireless service from one of the stations to surrounding homes. There are
more than 60,000 km of railway in India.

Looks like an accident waiting for a moment to happen.

Ron Bakowski, Belwood Information Technologies Inc.  ron@belwood.com

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

Date: Wed, 31 May 2000 22:53:46 -0500
From: Robotech_Master <robotech@eyrie.org>
Subject: Trash compactor kills shoplifter

Not a risk of a computer per se, but a risk of automation.

In the tradition of the reluctant mobster's "pressing engagement" in
_Goldfinger_, it seems a hapless shoplifter, looking for a place to hide,
dived into a trash compactor...which triggered automatically, crushing her
to death.

The whole story is at
<URL:http://www.cnn.com/2000/US/05/31/compactor.death.ap/index.html> but
particularly noteworthy is the line, "The compactor starts automatically
when it senses a certain weight, [Police Officer Glen Woods] said."  The
risk inherent in such a weight-related trigger should be readily apparent.

Chris Meadows aka Robotech_Master   <URL:http://www.eyrie.org/~robotech/>
robotech@eyrie.org  robotech@jurai.net  ICQ UIN: 5477383 

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

Date: Thu, 1 Jun 2000 17:45:34 GMT
From: rubin@research.att.com (Avi Rubin)
Subject: How not to distribute white papers

I was reading a white paper from Microsoft about Windows 2000 security.
In particular, I am interested in how the Encrypted File System (EFS)
works. Someone at Microsoft informed me that there was a new version of
the white paper available at
  http://www.microsoft.com/windows2000/library/howitworks/security/encrypt.asp

Great. I went to that site, and I found a copy of the introduction and a
link to the paper. The only catch was that the only way to download the
paper is to download a file called encrypt.exe. Once you download this file,
you can run the program, which unzips a word file. Obviously, Microsoft is
doing this to save storage space on their server and to reduce latency on
the downloads.

Of all companies, Microsoft should be the last one to encourage users to get
into the habit of downloading .exe programs and running them. The way I
handled it was to download the file to a sacrificial machine that I use for
this purpose. Then, I took it off the network and ran the program. I then
physically copied the .doc file to a floppy and transfered it using
sneakernet to my regular PC. Of course, I was still taking a chance. If the
downloaded program were malicious, then it could do its damage the next time
I connect the machine to the network. The problem is that it is very
difficult to know that a program is harmless, just because it does something
that you expect it to do. I could not believe that this is how Microsoft
distributes its white papers. It is beyond comprehension.

Avi Rubin

http://avirubin.com/

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

Date: Mon, 29 May 2000 23:10:35 +0100
From: "Martyn Thomas" <mct@hollylaw.demon.co.uk>
Subject: 1984 comes late to the UK

The Regulation of Investigatory Powers Bill has just been passed by the UK
House of Commons.

Amongst other provisions, the Bill contains powers to force all ISPs to
introduce mechanisms to copy all internet traffic to a Government
interception agency in real time. Whilst the data should only be disclosed
to a limited set of agencies following senior authorisation (itself a
profound erosion of civil liberty) the "traffic data" (defined to include
the URLs of pages accessed) is available to any public authority for almost
any purpose it considers part of its normal business.

Encryption? The Bill gives the police and security services the power to
demand keys. You've lost them? Prove it [how?] or go to jail for 2 years.

Want to complain? You can be served with a gagging order that requires that
you tell no-one that your keys (or their keys) have been compromised, on
penalty of five years in jail.

The Bill starts in the House of Lords in two weeks time, but seems likely to
pass without substantial weakening.

The risk? Why would any business (or anyone else) want to use any UK-based
ISP under these circumstances?

Martyn Thomas, Holly Lawn, Prospect Place, Bath BA2 4QP UK  01225 335649 

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

Date: Tue, 30 May 2000 22:14:02 -0500
From: Bruce Schneier <schneier@counterpane.com>
Subject: Social engineering in the real world

http://www.cnn.com/2000/US/05/25/security.breaches.01/index.html

The best line is:

"I think any time you expose vulnerabilities it's a good thing," said 
Attorney General Janet Reno....

This, of course, means that she is in favor of full disclosure of network
vulnerabilities.

Bruce Schneier, CTO, Counterpane Internet Security, Inc.  Ph: 408-556-2401
3031 Tisch Way, 100 Plaza East, San Jose, CA 95128       Fax: 408-556-0889

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

Date: Mon, 15 May 2000 15:06:31 -0500
From: Bruce Schneier <schneier@counterpane.com>
Subject: Computer Security: Will We Ever Learn? (CRYPTO-GRAM, May 15, 2000)

  [From CRYPTO-GRAM, May 15, 2000, in RISKS with permission, by Bruce
  Schneier, Counterpane Internet Security, Inc. <schneier@counterpane.com>
  See Bruce's free Internet security newsletter: http://www.counterpane.com]

     Computer Security: Will We Ever Learn?

If we've learned anything from the past couple of years, it's that computer 
security flaws are inevitable.  Systems break, vulnerabilities are reported 
in the press, and still many people put their faith in the next product, or 
the next upgrade, or the next patch.  "This time it's secure," they 
say.  So far, it hasn't been.

Security is a process, not a product.  Products provide some protection, 
but the only way to effectively do business in an insecure world is to put 
processes in place that recognize the inherent insecurity in the 
products.  The trick is to reduce your risk of exposure regardless of the 
products or patches.

Consider denial-of-service attacks.  DoS attacks are some of the oldest and 
easiest attacks in the book.  Even so, in February 2000, coordinated, 
distributed DoS attacks easily brought down several high-traffic Web sites, 
including Yahoo, eBay, Amazon.com and CNN.

Consider buffer overflow attacks.  They were first talked about as early as 
the 1960s -- time-sharing systems suffered from the problem -- and were 
known by the security literati even earlier than that.  In the 1970s, they 
were often used as a point of attack against early networked computers.  In 
1988, the Morris Worm exploited a buffer overflow in the Unix fingerd 
daemon: a very public use of this type of attack.

Today, over a decade after Morris and about 35 years after these attacks 
were first discovered, you'd think the security community would have solved 
the problem of security vulnerabilities based on buffer overflows.  Think 
again.  Over two-thirds of all CERT advisories in 1998 were for 
vulnerabilities caused by buffer overflows.  During an average week in 
1999, buffer overflow vulnerabilities were found in the RSAREF 
cryptographic toolkit (oops), HP's operating system, the Solaris operating 
system, Microsoft IIS 4.0 and Site Server 3.0, Windows NT, and Internet 
Explorer.  A recent study named buffer overflows as the most common 
security problem.

Consider encryption algorithms.  Proprietary secret algorithms are 
regularly published and broken.  Again and again, the marketplace learns 
that proprietary secret algorithms are a bad idea.  But companies and 
industries -- like Microsoft, the DVD consortium, cellular phone providers, 
and so on -- continue to choose proprietary algorithms over public, free 
alternatives.

Is Anyone Paying Attention?

Sadly, the answer to this question is: not really.  Or at least, there are 
far fewer people paying attention than should be.  And the enormous need 
for digital security products necessitates people to design, develop and 
implement them.  The resultant dearth of experts means that the percentage 
of people paying attention will get even smaller.

Most products that use security are not designed by anyone with security 
expertise.  Even security products are generally designed and implemented 
by people who have only limited security expertise.  Security cannot be 
functionality tested -- no amount of beta testing will uncover security 
flaws -- so the flaws end up in fielded products.

I'm constantly amazed by the kinds of things that break security 
products.  I've seen a file encryption product with a user interface that 
accidentally saves the key in the clear.  I've seen VPNs where the 
telephone configuration file accidentally allows a random person to 
authenticate himself to the server, or that allows one remote client to 
view the files of another remote client.  There are a zillion ways to make 
a product insecure, and manufacturers manage to stumble on a lot of those 
ways again and again.

No one is paying attention because no one has to.

Computer security products, like software in general, have a very odd 
product quality model.  It's unlike an automobile, a skyscraper, or a box 
of fried chicken.  If you buy a product, and get harmed because of a 
manufacturer's defect, you can sue...and you'll win.  Car-makers can't get 
away with building cars that explode on impact; chicken shops can't get 
away with selling buckets of fried chicken with the odd rat mixed in.  It 
just wouldn't do for building contractors to say thing like, 
"Whoops.  There goes another one.  Sorry.  But just wait for Skyscraper 
1.1; it'll be 100% collapse-free!"

Software is different.  It is sold without any claims whatsoever.  Your 
accounts receivable database can crash, taking your company down with it, 
and you have no claim against the software company.  Your word processor 
can accidentally corrupt your files and you have no recourse.  Your 
firewall can turn out to be completely ineffectual -- hardly better than 
having nothing at all -- and yet it's your fault.  Microsoft fielded 
Hotmail with a bug that allowed anyone to read the accounts of 40 or so 
million subscribers, password or no password, and never bothered to apologize.

Software manufacturers don't have to produce a quality product because 
there is no liability if they don't.  And the effect of this for security 
products is that manufacturers don't have to produce products that are 
actually secure, because no one can sue them if they make a bunch of false 
claims of security.

The upshot of this is that the marketplace does not reward real 
security.  Real security is harder, slower, and more expensive, both to 
design and to implement.  Since the buying public has no way to 
differentiate real security from bad security, the way to win in this 
marketplace is to design software that is as insecure as you can possibly 
get away with.

Microsoft knows that reliable software is not cost effective.  According to 
studies, 90% to 95% of all bugs are harmless.  They're never discovered by 
users, and they don't affect performance.  It's much cheaper to release 
buggy software and fix the 5% to 10% of bugs people find and complain about.

Microsoft also knows that real security is not cost-effective.  They get 
whacked with a new security vulnerability several times a week.  They fix 
the ones they can, write misleading press releases about the ones they 
can't, and wait for the press fervor to die down (which it always 
does).  And six months later they issue the next software version with new 
features and all sorts of new insecurities, because users prefer cool 
features to security.

The only solution is to look for security processes.

There's no such thing as perfect security.  Interestingly enough, that's 
not necessarily a problem.  In the U.S. alone, the credit card industry 
loses $10 billion to fraud per year; neither Visa nor MasterCard is showing 
any sign of going out of business.  Shoplifting estimates in the U.S. are 
currently between $9.5 billion and $11 billion per year, but you never see 
"shrinkage" (as it is called) cited as the cause when a store goes out of 
business.  Recently, I needed to notarize a document.  That is about the 
stupidest security protocol I've ever seen.  Still, it works fine for what 
it is.

Security does not have to be perfect, but the risks have to be 
manageable.  The credit card industry understands this.  They know how to 
estimate the losses due to fraud.  Their problem is that losses from phone 
credit card transactions are about five times the losses from face-to-face 
transactions (when the card is present).  Losses from Internet transactions 
are many times those of phone transactions, and are the driving force 
behind SET.

My primary fear about cyberspace is that people don't understand the risks, 
and they are putting too much faith in technology's ability to obviate 
them.  Products alone cannot solve security problems.

The digital security industry is in desperate need of a perceptual 
shift.  Countermeasures are sold as ways to counter threats.  Good 
encryption is sold as a way to prevent eavesdropping.  A good firewall is a 
way to prevent network attacks.  PKI is sold as trust management, so you 
can avoid mistakenly trusting people you really don't.  And so on.

This type of thinking is completely backward.  Security is old, older than 
computers.  And the old-guard security industry thinks of countermeasures 
not as ways to counter threats, but as ways to avoid risk.  This 
distinction is enormous.  Avoiding threats is black and white: either you 
avoid the threat, or you don't.  Avoiding risk is continuous: there is some 
amount of risk you can accept, and some amount you can't.

Security processes are how you avoid risk.  Just as businesses use the 
processes of double-entry bookkeeping, internal audits, and external audits 
to secure their financials, businesses need to use a series of security 
processes to protect their networks.

Security processes are not a replacement for products; they're a way of 
using security products effectively.  They can help mitigate the 
risks.  Network security products will have flaws; processes are necessary 
to catch attackers exploiting those flaws, and to fix the flaws once they 
become public.  Insider attacks will occur; processes are necessary to 
detect the attacks, repair the damages, and prosecute the attackers.  Large 
systemwide flaws will compromise entire products and services (think 
digital cell phones, Microsoft Windows NT password protocols, or DVD); 
processes are necessary to recover from the compromise and stay in business.

Here are two examples of how to focus on process in enterprise network 
security:

1.  Watch for known vulnerabilities.  Most successful network-security 
attacks target known vulnerabilities for which patches already 
exist.  Why?  Because network administrators either didn't install the 
patches, or because users reinstalled the vulnerable systems.  It's easy to 
be smart about the former, but just as important to be vigilant about the 
latter.  There are many ways to check for known vulnerabilities.  Network 
vulnerability scanners like Netect and SATAN test for them.  Phone scanners 
like PhoneSweep check for rogue modems inside your corporation.  Other 
scanners look for Web site vulnerabilities.  Use these sorts of products 
regularly, and pay attention to the results.

2.  Continuously monitor your network products.  Almost everything on your 
network produces a continuous stream of audit information: firewalls, 
intrusion detection systems, routers, servers, printers, etc.  Most of it 
is irrelevant, but some of it contains footprints from successful 
attacks.  Watching it all is vital for security, because an attack that 
bypassed one product might be picked up by another.  For example, an 
attacker might exploit a flaw in a firewall and bypass an IDS, but his 
attempts to get root access on an internal server will appear in that 
server's audit logs.  If you have a process in place to watch those logs, 
you'll catch the intrusion in progress.

In this newsletter and elsewhere I have written pessimistically about the 
future of computer security.  The future of computers is complexity, and 
complexity is anathema to security.  The only reasonable thing to do is to 
reduce your risk as much as possible.  We can't avoid threats, but we can 
reduce risk.

Nowhere else in society do we put so much faith in technology.  No one has 
ever said, "This door lock is so effective that we don't need police 
protection, or breaking-and-entering laws."  Products work to a certain 
extent, but you need processes in place to leverage their effectiveness.

Copyright (c) 2000 by Counterpane Internet Security, Inc.
Bruce Schneier, CTO, Counterpane Internet Security, Inc.  Ph: 408-556-2401
3031 Tisch Way, 100 Plaza East, San Jose, CA 95128       Fax: 408-556-0889

  [A version of this essay originally appeared in the April issue of 
  *Information Security* magazine.
    <http://www.infosecuritymag.com/apr2000/cryptorhythms.htm>]

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

Date: Tue, 30 May 2000 11:44:34 -0500
From: Richard Thieme <rthieme@thiemeworks.com>
Subject: Symantec's antiviral returns false positives on network.vbs

And that's just the beginning.

When the alert from Symantec's Systemworks 2000 Anti Virus told me an e-mail
carried the network.vbs worm, I followed steps to quarantine the file. By
the time the alert sounded again - on another email - I realized that it was
detecting not the worm itself but the source code for the worm which was
included in e-mails on a security list to which I subscribe. The first alert
had isolated the entire e-mail box on Eudora Pro to which a filter directed
that e-mail. The second time, it would have done the same to my inbox, with
all of the stored e-mail in it. I copied the e-mail out of my inbox, deleted
and recreated an inbox, then rebooted and transferred the e-mail back to the
inbox. But that other mailbox was in quarantine. I struggled in vain to
reach someone at Symantec - they want $30 up front to tell them that they
made a mistake - so I tried their web site response forms. That of course
brought me nothing but a rash of documents sent by automated processes about
all the recent .vbs worms but of course not one answered my question, i.e.,
how can I get my e-mail box out of quarantine?  So I sent the quarantined
"file" to Symantec with a note asking for the contents of the e-mail box
back. No human being read that note either - I received an automated reply
telling me that the file was a clean text file with no virus (duh), and when
I finally was able to contact a human being after more hours of voice mail
and round-about calls, I reached a "help technician" who had no idea what to
do ("the guy who knows these things isn't here today") so he asked around
until he could tell me that the file was destroyed - like that village in
Viet Nam - in order to save it. I asked what one had to do to get the
contents of a quarantined file back and he said no one ever requested that
before.

Procedural errors, inadequate training, human mistakes, automated replies
that are irrelevant, voice mail hell, screw-the-customer costs ,
it's-your-problem-not-ours -- it's all here in this scenario, my e-mail file
is gone, and now when I am now told by Symantec Anti Virus that e-mail has
arrived with network.vbs on it, I know that I should -- do what, exactly?

Richard Thieme, ThiemeWorks, PO Box 170737, Milwaukee Wisconsin 53217-8061
1-414.351.2321  cell: 1-414.704.4598  http://www.thiemeworks.com            

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

Date: Wed, 31 May 2000 18:16:31 IDT
From: amos@nsof.co.il
Subject: Re: Junk-mail filters (Cattarin, RISKS-20.89)

>     Body contains [...]

Ooops! 

>   [Your moderator chose to create a supplemental issue,
>      RISKS-20.89x

Too late...  The first line I quoted above was probably the reason why
this issue of RISKS was not posted on the news server I use (and of
course neither was the 20.89x issue), so I had to pull them directly off
your site by FTP.  I hope this message goes through!  

Amos Shapir, nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552  

  [Also noted by Timothy Prodin.
  NOTE TO READERS: If you did not receive RISKS-20.89, it was
  undoubtedly the victim of filtering.  Try the archives.  PGN]

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

Date: Thu, 1 Jun 2000 10:09:18 -0500 (CDT)
From: "Ron Bean" <rbean@execpc.com>
Subject: Re: Junk-mail filters (Cattarin, RISKS-20.89)

A couple of years ago I put together a procmail filter using similar kinds
of rules. However, the first rule I used was to delete any Bcc: mail that
comes from an unknown source (ie, a From: address that's not on a list of
friends, relatives, business contacts, subscribed mailing lists, etc). My
log files showed that 96% of the spam was being deleted by the Bcc: filter
and not even getting to the "clever" ones. So I just kept the Bcc: filter
and dumped most of the rest (actually it looks for messages that *don't*
have my address in some *other* header line, ie, To: or Cc:).

I've only had a couple of false positives, and none were on the Bcc:
filter-- Bcc: mail almost never comes from an *unknown* source. Of course I
have to turn the filter off temporarily any time I subscribe to a mailing
list, until I can see a couple of sample messages and find something in the
header for the filter to look for.

The real risk is letting someone else define spam for you, without
explaining their methods.

(Do they have an option to automatically accept e-mail from anyone in your
address book file? Or to build some other kind of exception file? Seems like
an obvious thing to do...)

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

Date: Sat, 3 Jun 2000 19:09:57 -0500
From: "Ray Todd Stevens" <raytodd@kiva.net>
Subject: Re: Junk-mail filters (Cattarin, RISKS-20.89)

It sounds to me that a need feature is missing for the filtering.  It 
would seem that an important question for this type of filtering is "is 
this someone I e-mail a lot".  Maybe this is a risk of building very 
complicated systems on top of a weak foundation.

Ray Todd Stevens, Senior Consultant, Stevens Services, R.R. # 14 Box 1400
  Apt 21, Bedford, IN 47421  (812) 279-9394  Raytodd@tima.com

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

Date: 31 May 2000 15:42:46 +0300
From: Markus Peuhkuri <puhuri@ws18.tct.hut.fi>
Subject: Re: Junk-mail filters (Cattarin, RISKS-20.89)

While automatic junk mail identification would be useful, I can't recommend
word based filtering because of too many false positives.  Swedish for "six"
(i->e) can be a bit problematic word.  Maybe they should use "five and one
more".

A few years ago I lost some US$20 because of Subject-words filter; (the
mail was stored in a junk folder which I checked every now and then -- too
late in that case).

Currently, I do filtering based on To: and From: fields

* mail must be addressed to some of my addresses (mail list
  traffic is separated before)
* sender must be someone I know (I've sent mail to)

If both conditions are satisfied, then mail is accepted to my
primary inbox, otherwise it is put in low-priority folder.
 
Markus Peuhkuri        ! http://www.iki.fi/puhuri/

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

Date: 13 Dec 1999 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)

 The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) 
 if possible and convenient for you.  Alternatively, via majordomo, 
 SEND DIRECT E-MAIL REQUESTS to <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 19" for volume 19]
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
 http://the.wiretapped.net/security/textfiles/risks-digest/ .
==> PostScript copy of PGN's comprehensive historical summary of one liners:
    illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 20.90
************************


[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]