Risks Digest 21.59

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Friday 10 August 2001  Volume 21 : Issue 59

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

  Contents:
Laser eye surgery (Henry Baker)
"You Can't Hide Those Lying Eyes in Tampa" (Adam Shostack)
The Internet park bench (Richard Jay Solomon via Dave Farber)
PDF backward compatibility failures (Marc Auslander)
A lucrative fiasco (Brian Randell)
Risks of automatic verification (Geoff Kuenning)
Possibility of a Warhol Worm: Complete infection in 15 minutes! 
  (Nicholas C. Weaver)
Adobe clarification on spyware article (Gunar Penikis)
Danish police: Safeguard Easy not broken; passwords were weak (Bo Elkjaer)
Re: OT: rot13, practical uses of (Rich Wales)
Re: Georgia scholarship info exposed (Phil Kos)
Re: Freeware app to retrieve passwords from Internet Explorer (Marc Roessler)
Mutual authentication - not! (Michael Bacon)
Re: What is your area code, really? ((Declan McCullagh)
Is your phone bill private?  Think again... (Ted Lee)
Re: Firefighter's phone lines disrupted ... SMS hoax (Stanislav Meduna)
Caller ID "hack" not a hack at all (William Kucharski)
ANI is NOT Caller ID (Danny Burstein)
DoCoMo thttpd is not all.net thttpd (Fred Cohen)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 09 Aug 2001 13:52:21 -0700
From: Henry Baker <hbaker1 () pipeline com>
Subject: Laser eye surgery

Someone close to me had laser eye surgery to correct significant
near-sightedness two days ago.  The surgery apparently went very well, but
as I watched the procedure being performed, I was horrified to see two
things:

* the use of Windows as the major interface for this system
  (www.ladarvision.com), both for the output of the real-time video of the
  eye, both the tracked and the untracked views, as well as for the entry
  and display of the parameters.  Based on my personal experience with
  Windows (I reboot on the average of 3-4X per day), I find it almost
  inconceivable that someone would trust their eyesight to such a software
  disaster area.  I wasn't aware that _anyone_ had done any source checking
  of the Windows system to make sure that the numbers typed in were properly
  interpreted in all cases.  Furthermore, even if someone had done such a
  check, it is inconceivable that such checks would remain valid for more
  than one version of the software.  (Getting input routines correct isn't
  easy -- I'm aware of popular software systems (non-Windows) that still
  contained the same input conversion bugs after almost ten years and 5
  versions.)

* during the entry of parameters, the technician quickly "clicked
  away"/dismissed a number of error windows of the form "parameter out of
  bounds" -- seemingly on almost every number entered.  When error windows
  of this type pop up so frequently and are routinely dismissed, it is like
  crying "wolf" -- eventually, no one listens even when there is a really
  bad problem.

I was, however, very impressed with the quality of the eye-tracking system,
which keeps the laser locked onto the pupil for upwards of 2.5 minutes, with
_no_ noticeable jitter (I would estimate that the jitter was well under a
single pixel out of an image probably 640 pixels wide).

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

Date: Wed, 8 Aug 2001 13:03:34 -0400
From: Adam Shostack <adam () zeroknowledge com>
Subject: "You Can't Hide Those Lying Eyes in Tampa"

http://www.sptimes.com/News/080801/TampaBay/_They_made_me_feel_li.shtml 
is the story of Rob Milliron, whose picture, captured from Ybor city
surveillance cameras, was published in US News and World Report.  A woman in
Tulsa saw his picture and (incorrectly) identifying him as her ex-husband,
called the police.

Many of the risks are generally familiar, issues like mis-identification.
Worth asking is why didn't they choose the picture of a criminal who was
actually caught?  Perhaps because the system does not function as
advertised?

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

Date: Fri, 10 Aug 2001 13:35:01 -0400
From: Richard Jay Solomon <rsolomon () dsl cis upenn edu>
Subject: The Internet park bench (From Dave Farber's IP list)

> http://news.bbc.co.uk/hi/english/sci/tech/newsid_1481000/1481783.stm
Thursday, 9 August, 2001, 13:44 GMT 14:44 UK

Bad start for Internet bench: The teenagers took advantage of the free service

Two teenagers discovered the world's first Internet bench could be used to
make free international telephone calls.  The cyber-seat, which is based in
a public park in Suffolk, UK, went online on Monday.  Neil Woodman and Dan
Sanderson, both 17, took a normal telephone handset along to the bench,
which was created by Microsoft's MSN service in partnership with the local
council.  The pair cheekily phoned St Edmondsbury Council to warn them of
the problem and then tried to call Microsoft boss, Bill Gates.

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

Date: 10 Aug 2001 16:50:56 -0400
From: Marc Auslander <marc () watson ibm com>
Subject: PDF backward compatibility failures

I can't read my Vanguard statements (back to 1998) with Acrobat 5.0.  In
looking at the Adobe site, this is not the only backward compatibility
failure reported.

So what has become a defacto document storage standard may in fact leave us
with documents we can't read!

Marc Auslander   <marc () watson ibm com>   914 945-4346  (Tieline 862 Fax x4425)

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

Date: Thu, 9 Aug 2001 22:28:45 +0100
From: Brian Randell <Brian.Randell () newcastle ac uk>
Subject: A lucrative fiasco

Magistrates courts staff are having to work with two computers on their
desks instead of one after being presented with new PCs which do not have
the software to do the main job they were bought for.  In the latest in a
long line of government IT humiliations, the Lord Chancellor's Department is
pressing ahead with the installation of new computers in 400 magistrates
courts even though delivery of the core application, a new case management
system, has been indefinitely delayed.  The result is that staff still rely
on their old computers - installed 10 years ago - to access the casework
system, while using the new PCs only for basic functions such as word
processing and e-mail.  An investigation by *Computer Weekly* has
established that by installing the computers, the contractor ICL is now
entitled to be paid more than half the contract's 319,000,000 pounds value,
despite its failure to deliver the core application.  [Source: Court staff
hit by IT fiasco; software snag hits magistrates computer project, Stuart
Millar, (UK) *The Guardian*, 9 Aug 2001]

Full story at
  http://www.guardian.co.uk/internetnews/story/0,7369,534162,00.html

Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne,
NE1 7RU, UK  +44 191 222 7923   http://www.cs.ncl.ac.uk/~brian.randell/

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

Date: Tue, 7 Aug 2001 17:24:17 -0700
From: Geoff Kuenning <geoff () cs hmc edu>
Subject: Risks of automatic verification

In the past year or so, a lot of e-shopping sites have installed
fraud-prevention software that attempts to verify that you aren't using a
stolen credit card.  These systems generally operate by comparing the
billing address for the card with an address provided by the shopper or with
the shipping address for the merchandise.

These systems have caused me endless headaches, because my billing address
is a P.O. box in a different state.  For some reason, the automated
verification system insists on rejecting me with a message indicating that
my information doesn't match what's in my bank's records -- despite the fact
that I have spoken with the bank to make sure that it is the same.  On more
than one occasion, I have been forced to resort to telephone calls to get my
transaction to go through.

But my favorite was when one site gave me a reject message, so I retried
with a slight variation on the address.  After a second reject, I got on the
phone and straightened it out (without any particular verification
requirement, I might add).

That evening, the bank called to ask why I had three charges from the same
Web site...

The RISK: programmers who assume that everyone runs their lives the same way
the programmer does.  There's an incompetent-programmer RISK here too, but
what else is new?

Geoff Kuenning   geoff () cs hmc edu   http://www.cs.hmc.edu/~geoff/

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

Date: Thu, 9 Aug 2001 15:11:50 -0700 (PDT)
From: "Nicholas C. Weaver" <nweaver () EECS Berkeley EDU>
Subject: Possibility of a Warhol Worm: Complete infection in 15 minutes!

Michael Constant and I have performed a basic analysis of a possible
worst-case virulence for an active worm like Code Red.  By simply changing
the infection strategy, a "Warhol Worm" could be developed, able to infect
all vulnerable machines in 15 minutes from the moment of initial infection
of a single machine!

http://www.cs.berkeley.edu/~nweaver/warhol.html
Nicholas Weaver, nweaver () cs berkeley edu

  [And in Case you have not heard, Code Red III is now operating.  PGN]
     http://news.cnet.com/news/0-1003-200-6835996.html

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

Date: Thu, 9 Aug 2001 13:24:49 -0700
From: "Gunar Penikis" <gpenikis () adobe com>
Subject: Adobe clarification on spyware article (Maggard, RISKS-21.56)

This is in response to Michael F. Maggard's posting in RISKS-21.56.

I would like to clarify some misconceptions and misinformation that was
posted regarding Adobe applications "phoning home".  The component in
question is AOM, Adobe Online Manager which is included in most Adobe
applications.

1. AOM does not scan your computer for registration and product information.

AOM runs concurrently with most applications, it's purpose is NOT to scan
for registration and product information and phone home to Adobe.
Registration information such as serial number, product name is ONLY sent
from the product when the user selects the Registration menu item in the
product. This launches the default browser to the registration web page that
has product and registration information pre-filled as a convenience (so the
customer doesn't have to find the product box, etc.) The serial number is
obfuscated in this transaction to protect our customers and Adobe from
piracy.  Alternatively, customers can print out a registration form, use the
registration card, or register via the Adobe.com and type in the product
information manually.

2. AOM only sends registration information when you select Online Registration

As I mentioned above, we only send registration information when the user
clicks the Registration menu in the product.  It is never sent at any other
time or with any other interaction.

3. Removing any components is NOT recommended.

We highly suggest NOT removing AOM or other files since these components are
critical to functionality of the connectivity, collaboration and support
features of the product.  As part of the regular updates to the products, we
are investigating eliminating the dependency of AOM.  In the meanwhile, we
suggest that users of older products update their version of AOM by
selecting Adobe Online and clicking the refresh or update button.  Newer
product should select the Downloadables or Updates menu item to check for
product updates.

What is AOM used for anyway?

AOM stand for Adobe Online Manager.  It is core component that coordinates
the online interaction between Adobe products.  When customers request
updated information from within Adobe products by selecting Adobe Online or
Updates/Downloadables, AOM processes these requests so that collisions do
not occur and the appropriate information is displayed to the user.

I hope this helps clarify some of the concerns your readers have
encountered.

Gunar Penikis, Product Manager, Adobe Systems

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

Date: Thu, 9 Aug 2001 22:18:57 +0200 (CEST)
From: Bo Elkjaer <boo () datashopper dk>
Subject: Danish police: Safeguard Easy not broken; weak passwords (R 21 58)

This is to elaborate and correct the initial mentioning of Safeguard Easy
in RISKS-21.58.

It was reported in national media - including tv - that the police had
successfully broken the encryption. This, it seems, is not the case. The
police have managed to find the passwords of the five encrypted computers.
The information concerning the successful decryption of the five computers
protected with Safeguard Easy was presented in court by chief prosecutor
Poul Gade. Investigation is lead by chief of police in Holstebro, Jens
Kaasgaard. 

I have just interviewed Jens Kaasgaard. He says: 
'To avoid misunderstandings, we haven't broken Safeguard by technically
breaking down the encryption. We have located the passwords in different
ways. We have done it like any hacker would have done, by trying to figure
out the most probable passwords. This has payed success in five cases.' 
'After doing that we entered the document-parts, the harddisk of the
computer. Here we found some of the files unencrypted and other files
further encrypted.' 
'When you use Safeguard you put a sort of shell around your data. This is
the first part you need to enter. This is what is claimed to be
impossible. It is impossible. We have had six private companies looking at
this, and they have all failed.' 
'We have used completely ordinary police investigation methods. We know
precisely who have had access to the encrypted machines. Then we can start
assessing probabilities and calculate upon this and set up models for how,
if you were a hacker, you'd find your way into the machines.  That's what
we have done.' 
You did this yourself? 
'Yes. We did this inside the police system.' 

To conclude: Be careful when you choose your password. 

Bo Elkjaer

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

Date: Thu, 9 Aug 2001 17:06:52 -0700 (PDT)
From: Rich Wales <richw () webcom com>
Subject: Re: OT: rot13, practical uses of (Manfre, RISKS-21.58)

Let's not forget, of course, that when the US Army decided to get serious
about enforcing a "no encryption software" policy on the SIMTEL20 archive
back in 1990, one of the programs that was kicked off the site was ... you
guessed it ... a ROT13 utility.

Rich Wales      richw () webcom com      http://www.webcom.com/richw/

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

Date: Thu, 9 Aug 2001 14:45:08 -0700 
From: Phil Kos <PhilK () solthree com>
Subject: Re: Georgia scholarship info exposed (Slatkin, RISKS-21.58)

> the security file was wiped out, exposing other files.

I think I would be a bit ticked off if my IT people decided that one of my
web servers should automatically be "cleaned" of not-recently-used files,
but let's not let that distract us from the real issue.

Rachel hopes that the "security file" was .htaccess. While I can't disagree,
I think that it misses the point. Frankly, even .htaccess is not sufficient
to protect passwords stored in plain text on an unsecured web server. This
is the real problem here. Storing passwords in plain text is an even
better-known bad idea than using unchecked buffers on the stack frame, and I
hope the person responsible for this piece of phenomenally bad design gets
the blame due them.

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

Date: Wed, 8 Aug 2001 17:45:08 +0200
From: Marc Roessler <marc () tentacle franken de>
Subject: Re: Freeware app to retrieve passwords from Internet Explorer

Now this is interesting.  I remember seeing something similar about three or
four years ago, named "Snadboy Revelation" back then, worked fine with
win95.

I had expected MS to make this more difficult after seeing such a tool..
The RISKs of using password remembering functions are well known, but making
revelation of passwords that easy borders the laughable.

Of course, displaying an asterisk for each character of the password is
another RISK in itself since it leaks information on the length of the
password.. Standard UNIX login does not echo anything at the Password prompt
for a reason..

Marc Roessler

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

Date: Tue, 7 Aug 2001 18:58:38 +0100
From: "Michael (Streaky) Bacon" <streaky_bacon () email msn com>
Subject: Mutual authentication - not!

I recently received a telephone call from the fraud department at my bank.
I had recently been using a card that I don't normally use and they were
just checking that it was still in my possession.

The fraud department asked me to identify myself by giving them my date of
birth and 'secret code' that I had supplied years beforehand.  They told me
what the question was, so I remembered the answer.  I declined, and asked
them to positively identify themselves to me before I would give them the
information.  "But we only need to confirm it, I have it on my screen", the
lady said.  "OK, you tell me what it is and if I agree that's what I told
you then I've authenticated you", said I - knowing that it should fail, but
hoping that it wouldn't.  "Then you can authenticate me."

After much discussion and calling two supervisors, we agreed that they would
tell me the last two purchases I had made on that card (approximately 1 hour
and 20 minutes beforehand respectively from two different stores).  If they
could, then they were probably from the bank, and I would authenticate
myself to them.  All three people I spoke to said that, "No-one has ever
asked us to identify ourselves!"

The RISKS are clear.  You supply some 'secret' data to the bank so that they
can authenticate you when you call them.  But there is no simple way to
authenticate the bank when it calls you.  You can't ask for the number and
call them back, because you have no way of authenticating the number given.
They're ex-directory, so you can't confirm it through Enquiries, and they
withhold the number so the CLI doesn't show!  If you blindly supply the data
(as clearly many people do), then you may be divulging to a crook the
'secrets' necessary to authenticate yourself to the bank.  The bank has not
thought to provide any means of authenticating themselves.  I suspect this
to be endemic.

Oh, and when I asked what would happen if I refused to authenticate myself
-- they said that my card would be suspended "As a precaution."  So at least
I would know then that it had been the bank I hung up on!

Streaky

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

Date: Tue, 07 Aug 2001 21:35:02 -0400
From: Declan McCullagh <declan () well com>
Subject: Re: What is your area code, really? ((Koenig, RISKS-21.57)

> Five minutes later, two police officers showed up at my door, saying
> that they had received a 911 (emergency) call from my home.

I had a similar problem this week. I was visiting my parents and helping my 
mother configure a PC that was last used on a university campus. The PC was 
still configured for the old area code, and that combined with the "9" 
prefix that was required to connect to an off-campus dialup gave a dial 
prefix of "911". (That's the police emergency number, for non-U.S. readers.)

Without knowing how to change the default location -- not a trivial task 
for a Windows novice -- a person using the computer would have had to edit 
the dial string every time they tried to connect. Eventually, no doubt, 
someone would have neglected to do so with results similar to what Andrew 
experienced.

The risks here are obvious. Unfortunately the obvious fix -- a prompt 
saying "Do you really wish to dial 911 and call police?" if the location is 
in the U.S. -- might come as a mild surprise if the user is connecting via 
an unusual PBX system that may require a "911" prefix.

Declan

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

Date: Tue, 7 Aug 2001 15:03:02 -0500
From: TED_LEE () udlp com
Subject: Is your phone bill private?  Think again...

I suppose this has already shown up and I missed it, but we'll see.  I just
called ATT's customer service line with a question about my bill.  (I don't
recall how many menus deep I had to go to get the answer, and even though it
was too many, that's not my point.)  Somewhere in the process I was asked if
I was calling from the number I was calling about and since I wasn't (I was
at work) I was then asked to enter the number -- and immediately it came
back with a statement about what my bill was and when I'd paid the last one.
I have to wonder what other information I might have been able to get
without having to authenticate myself in any way.

Ted Lee, Minnetonka, MN

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

Date: Fri, 10 Aug 2001 08:06:33 +0200
From: Stanislav Meduna <stano () meduna org>
Subject: Re: Firefighter's phone lines disrupted ... SMS hoax (RISKS-21.55)

> The cause was a hoax SMS spreading in the network of one of the GSM
> operators stating that it is possible to make free calls using this
> number.

Slowly the details of the case have emerged and - not surprisingly -
revealed another common risk - a risk of not assessing the effects of a
software change, even if it is fixing a simple bug.

There really _was_ the possibility to make free calls. Let zzz be the
emergency number. If you called zzz, the call was properly routed.  If you
called zzzyyyyyy, a software bug caused zzz to be stripped and the call was
routed to yyyyyy instead. Charging software looks at the beginning of the
number and have seen an emergency number, so such call was not billed.

Then the operator fixed the bug and the fix was analogous to plain old
telephone - ignore remaining digits. Suddenly, all of such calls ended at
the firefighters.

So we are back to software development basics: specify handling of an
invalid input, test the handling and think before you make a fix public. The
fix was good enough for the billing department, but caused massive problems
somewhere else.

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

Date: Mon, 23 Jul 2001 22:52:16 -0600
From: "William Kucharski" <kucharsk () mac com>
Subject: Caller ID "hack" not a hack at all (RISKS-21.51)

In Risks 21.51, Alexandre Pechtchanski wrote of receiving a phone call with
"hacked" Caller ID information.  In fact, it is likely no such "hack"
occurred, nor is a hack necessary.

Caller ID, (actually CNID, Calling Number ID), is based on data that is sent
on trunk lines along with other SS7 signalling data in a phone system. For
home users, this information is normally the originating phone number for
the call, as that is how your local telco has their switches set up.

Things are a bit different for PBX (Private Branch Exchange) systems,
typically found in businesses. They feed directly into telco trunk lines,
and the systems are responsible for feeding their own CNID information into
the telephone network.

Most newer PBXs can be programmed to either send along the originating phone
number of a call or to send a single pre-programmed piece of information. As
an example, a company may want the same information sent (say the company
name and their main incoming phone number) on all outgoing lines so those
receiving calls from the company see the company name and number rather than
the number corresponding to the actual outgoing phone line used to place the
call.

This is all perfectly OK, as CNID data is not and was never designed to be
secure, and is not used for anything but caller ID services.

In Alexandre's case, it's likely a telemarketer either just programmed a
nonsense number into their PBX, or perhaps their PBX came preprogrammed from
the vendor with a "sample" phone number in place (e.g. "John Doe (212)
555-1212".)

Note that there is a completely different system, ANI (Automatic Number
Identification), that is used when it is important a caller be properly
identified.  It is ANI information that is used to generate phone
billing records and to provide calling number identification for 911 services.

(For the security conscious, ANI information is also NOT blockable, and
most phone companies offer real-time ANI to their toll-free customers. This
means that even if you have "Caller ID blocking," if you call a company
using their toll-free number, they will have your phone number pop up
on their screen when the phone rings on their end or will receive it in their
end-of-month statement.  This has been ruled fair, as THEY are paying for the
phone call, thus they have a right to know who is calling them.)

The real RISK here is trusting a system that was never designed to be even
remotely secure as a source of accurate information as to the identity of a
caller...

William Kucharski <kucharsk () mac com>

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

Date: Tue, 7 Aug 2001 21:03:13 -0400 (EDT)
From: danny burstein <dannyb () panix com>
Subject: ANI is NOT Caller ID (Re: Green, RISKS-21.57)

This brings up the reminder that Caller Name/Number ID (CNID) is NOT the
same thing as Automatic Name/Number Identification (ANI).

The former, which is what is used by (the vast majority of) homes and
"regular" (non "800") business lines, can be blocked by the caller on
either a permanent per-line basis, or as a choice per-call. (Usually by
prepending a special code, generally "*70", before dialing out).

The latter, which is in use internally by the telcos and by businesses
with (so-called) toll-free (1-800/888/877/866, and soon 855) numbers, can
NOT be blocked  by the caller. Adding in the blocking prepend will NOT
have any effect.

So... whenever you reach out to a tollfree number, the recipient of that
call *will* get your phone number. Which, of course, lets them kick it
through a database for all sorts of other purposes. Sometimes, as in this
case, namely credit card receipt verification, a perfectly valid and
legitimate one.

The RISK: having just enough knowledge (about blocking CNID) to believe
you're keeping info (your phone number) private when no such thing is
happening.

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

Date: Fri, 10 Aug 2001 07:23:10 -0700 (PDT)
From: Fred Cohen <fc () all net>
Subject: DoCoMo thttpd is not all.net thttpd (Re: Poskanzer, RISKS-21.58)

It should be noted that this is not the 'thttpd' from all.net that provides
secure Web services...

Fred Cohen              Fred Cohen & Associates.........tel/fax:925-454-0171
fc () all net           The University of New Haven.....http://www.unhca.com/
http://all.net/         Sandia National Laboratories....tel:925-294-2087

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

Date: 12 Feb 2001 (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 e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe] 
 which requires your ANSWERing confirmation to majordomo () CSL sri com .  
 [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
 this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
 Lower-case only in address may get around a confirmation match glitch.
   INFO     [for unabridged version of RISKS information]
 There seems to be an occasional glitch in the confirmation process, in which
 case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
   .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].
   Lindsay Marshall has also added to the Newcastle catless site a 
   palmtop version of the most recent RISKS issue and a WAP version that
   works for many but not all telephones: http://catless.ncl.ac.uk/w/r
 http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
 http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    http://www.csl.sri.com/illustrative.html for browsing, 
    http://www.csl.sri.com/illustrative.pdf or .ps for printing

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

End of RISKS-FORUM Digest 21.59
************************