Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: RISKS List Owner (riskocsl.sri.com)
Date: Fri Aug 10 2001 - 20:52:35 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

       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 .

    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 <hbaker1pipeline.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

    * 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

    * 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 <adamzeroknowledge.com>
    Subject: "You Can't Hide Those Lying Eyes in Tampa"

    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


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

    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 <marcwatson.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 <marcwatson.ibm.com> 914 945-4346 (Tieline 862 Fax x4425)


    Date: Thu, 9 Aug 2001 22:28:45 +0100
    From: Brian Randell <Brian.Randellnewcastle.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

    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 <geoffcs.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 geoffcs.hmc.edu http://www.cs.hmc.edu/~geoff/


    Date: Thu, 9 Aug 2001 15:11:50 -0700 (PDT)
    From: "Nicholas C. Weaver" <nweaverEECS.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!

    Nicholas Weaver, nweavercs.berkeley.edu

      [And in Case you have not heard, Code Red III is now operating. PGN]


    Date: Thu, 9 Aug 2001 13:24:49 -0700
    From: "Gunar Penikis" <gpenikisadobe.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

    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

    Gunar Penikis, Product Manager, Adobe Systems


    Date: Thu, 9 Aug 2001 22:18:57 +0200 (CEST)
    From: Bo Elkjaer <boodatashopper.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

    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 <richwwebcom.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 richwwebcom.com http://www.webcom.com/richw/


    Date: Thu, 9 Aug 2001 14:45:08 -0700
    From: Phil Kos <PhilKsolthree.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 <marctentacle.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

    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_baconemail.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!



    Date: Tue, 07 Aug 2001 21:35:02 -0400
    From: Declan McCullagh <declanwell.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

    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.



    Date: Tue, 7 Aug 2001 15:03:02 -0500
    From: TED_LEEudlp.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 <stanomeduna.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" <kucharskmac.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

    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)

    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

    William Kucharski <kucharskmac.com>


    Date: Tue, 7 Aug 2001 21:03:13 -0400 (EDT)
    From: danny burstein <dannybpanix.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


    Date: Fri, 10 Aug 2001 07:23:10 -0700 (PDT)
    From: Fred Cohen <fcall.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
    fcall.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-requestcsl.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-requestcsl.sri.com> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoCSL.sri.com .
     [If E-mail address differs from FROM: subscribe "other-address <xy>" ;
     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-requestpica.army.mil> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallnewcastle.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 risksCSL.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