[risks] Risks Digest 21.64

From: RISKS List Owner (riskoat_private)
Date: Sat Sep 01 2001 - 14:47:58 PDT

  • Next message: RISKS List Owner: "[risks] Risks Digest 21.65"

    RISKS-LIST: Risks-Forum Digest  Saturday 1 September 2001  Volume 21 : Issue 64
       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.64.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Temelin nuclear plant software problem (Pete Mellor)
    Blame the victim: vandalized Web sites may be liable for damages (NewsScan)
    More risks when driving (Martin Cohen)
    Risks of "pre-owned" computers (Nick Brown)
    Microsoft Reader e-books broken (David Farber)
    AOL silently dropping mail (Simon Waters)
    eBay fails to protect email addresses of users (Vassilis Prevelakis)
    Re: Avoiding prosecution of the DMCA (A J Stiles)
    Risks and madness on the BT Cellnet site (Mike Perry)
    Not such an equal opportunity (Bill Lamb)
    Re: Code Red 9? Code Crimson (Bob Frankston)
    Risks of outsourced check verification (Peter Simpson)
    Can't hold room, but can bill (Sandy Antunes)
    Caller ID vs. ANI confusion, again (William Kucharski)
    Re: Mixing advertising and credit-card activation (John Clarke)
    REVIEW: "Information Security Management Handbook", Tipton/Krause (Rob Slade)
    Abridged info on RISKS (comp.risks)
    Date: Mon, 27 Aug 2001 15:04:35 +0100 (BST)
    From: Pete Mellor <pmat_private>
    Subject: Temelin nuclear plant software problem 
    The following is one item from the regular news digest produced 
    by the students of Charles University, Prague:- 
      CAROLINA No 429, 24 Aug 2001
      FROM THE EVENTS OF THE PAST TWO WEEKS (August 9 - August 22)
    Temelin up Again, down Again
    The Temelin nuclear power plant was activated again 12 Aug 2001 after three
    months of repairs to a vibrating turbine (see Carolina 428). The relaunch of
    Temelin provoked hostile reactions from some Austrian politicians and
    anti-nuclear and environment activists.
    News leaked 15 Aug about new vibrations in the turbine, which caused an
    18-hour shutdown.  However, plant officials claimed the shutdown was used to
    "balance a rotary part in the turbine." The reactor 19 Aug was automatically
    switched off due to a software error in a steam-delivery regulator.
    Temelin opponents claimed this shutdown was the 23rd since the beginning of
    operating tests.  According to Temelin management, the shutdowns are a
    normal part of the testing procedure and are not related to nuclear safety
    problems. Temelin CEO Frantisek Hezoucky said Temelin is exceptional only in
    one respect: it is the very first nuclear power plant where its testing is
    broadcast live to the public.
    Charles University in Prague, Faculty of Social Sciences
    Smetanovo nabr. 6,  110 01 Prague 1, Czech Republic
    e-mail: CAROLINAat_private ISSN 121-5040
    tel: (+4202) 22112252, fax: (+4202) 22112219
    Date: Mon, 27 Aug 2001 11:00:13 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Blame the victim: vandalized Web sites may be liable for damages
    Some legal scholars are suggesting that a Web site vandalized by hacker
    attacks may itself be legally liable if its customers suffer damages and if
    the site was negligent in maintaining security. Law professor Margaret Jane
    Radin of Stanford University predicts: "A court is going to say it is
    negligent of you not to implement preventative measures if they are
    reasonably effective and affordable." No reported court decisions have dealt
    with the issue, but Radin says that lawsuits in the near future are highly
    likely to be lodged against companies and network providers targeted by
    "denial of service" attacks.  [*The New York Times*, 24 Aug 2001; NewsScan
    Daily, 27 August 2001
    Date: Sat, 18 Aug 2001 01:31:48 GMT
    From: Martin Cohen <mjcohenat_private>
    Subject: More risks when driving
    *The New York Times* e-mail version contained an ad offering to teach you a
    language while you are driving.  Imaging trying to learn an irregular verb
    while negotiating difficult traffic.  
      [You might drive right through a subjunction.  Incidentally, someone was
      jogging toward me this morning when his cell phone rang.  At least he had
      the good sense to stop running.  PGN]
    Date: Sat, 1 Sep 2001 13:55:20 +0200 
    From: BROWN Nick <Nick.BROWNat_private>
    Subject: Risks of "pre-owned" computers
    The BBC reports that "confidential files containing the identities of
    alleged paedophiles and their victims were found on a second-hand computer
    bought from Bristol University".
    Full story at http://news.bbc.co.uk/hi/english/uk/newsid_1519000/1519889.stm
    Not a new RISK, but the first time I've seen this particular combination.
    Does *your* local social welfare department, public hospital, or police
    station have a statutory duty (in the interest of the taxpayers) to sell,
    rather than destroy, old equipment ?  And if so, is there a mandatory
    procedure for securely erasing the hard disk first ?
    Nick Brown, Strasbourg, France.
    Date: Fri, 31 Aug 2001 23:51:19 -0400
    From: David Farber <daveat_private>
    Subject: Microsoft Reader e-books broken
    An anonymous programmer has found a way to decrypt Microsoft Reader 
    e-books on Windows PCs, but has not released it.
      [Source: Breaking Microsoft's e-Book Code, By Wade Roush, Technology Review,
      30 Aug 2001, http://www.technologyreview.com/web/roush/roush083001.asp;
      PGN-ed; Dave has been predicting this, but then all lame protection seems
      to be easily broken, relying on the DMCA for protection.  Dave's archives 
      are at http://www.interesting-people.org/ .  PGN]
    Date: Sat, 25 Aug 2001 23:49:09 +0100
    From: Simon Waters <Simonat_private>
    Subject: AOL silently dropping mail
    I received reports from an AOL user of e-mail's not getting through.
    Checking log files show that AOL's mail server had received all the messages
    Queries to AOL's postmaster account received no response.
    Web pages run by AOL users suggest the cause of this is that I may have
    triggered a "suspicious relaying" trap with the AOL server.
    Assuming this is the case it is interesting that AOL choose to drop the mail
    silently, when all the information required to make such a decision is
    available to the mail transport agent before the body of the mail is
    sent. Thus AOL could choose to refuse the mail politely, using less
    bandwidth, and informing the sender of a problem, but prefer to waste
    bandwidth and delete the e-mail silently.
    The Risk? Assuming AOL cares enough about their subscribers e-mail not to
    delete it without notifying sender or recipient, or answer questions on the
    topic. The only way I can see to mitigate the risk is to switch to another
    +44(0)1395 232769 
    Moderated discussion of teleworking at news:uk.business.telework
    Date: Sun, 26 Aug 2001 18:01:09 -0400 (EDT)
    From: Vassilis Prevelakis <vassilipat_private>
    Subject: eBay fails to protect email addresses of users
    Normally eBay will not disclose the email addresses of its users. When you
    wish to send email to an eBay user, eBay provides a proxy service accepting
    the email and then forwarding it to the recipient.
    However, if the mailhost for the recipient is down or unavailable, the
    sender will get a warning email saying that the original message could not
    be delivered but the system will go on trying, WITH THE E-MAIL ADDRESS OF
    Another example of not thinking things through.
    Vassilis Prevelakis, Distributed Systems Laboratory, Univ. of Pennsylvania
    Philadelphia, PA 19104-6389  +1 215 898 0375 vassilipat_private 
    Date: Sun, 26 Aug 2001 11:59:03 +0100
    From: "A J Stiles" <ajs2at_private>
    Subject: Re: Avoiding prosecution of the DMCA (Re: Petrou, RISKS-21.62)
    But you are forgetting the law of Dual Criminality.  A person can only be
    extradited from one country to another if what the person did was recognised
    as a criminal offence in the country where they did it.  Since pointing out
    a security vulnerability is not a criminal offence in most countries,
    extradition can be refused.  (Otherwise anyone who drinks alcohol could be
    extradited to any muslim country and executed!)
    Of course, the USA could act illegally (as it has done on many occasions
    in the past).  That would technically be an act of war .....
    A J Stiles <ajs2at_private>  http://pages.zoom.co.uk/~nineladies/
    Date: Fri, 24 Aug 2001 18:39:42 +0100
    From: "Mike Perry" <PERRYMat_private>
    Subject: Risks and madness on the BT Cellnet site
    I've just registered with the BT Cellnet site in order to be able to view
    my mobile phone bill online.  I had to choose some authentication items,
    and I quote here from the website:
      For security purposes our on-line services are password protected -- in
      order to use them you need to register by providing a username, password,
      a memorable item, and a password hint.
      Your Username and Password must be unique to yourself. Try to use
      something memorable - you will need to use these every time you logon.
      Your Password will expire every 90 days and you will be required to choose
      a new one. You will be automatically prompted to change your password
      whenever you logon after the 90 day period has expired. To make your
      password easier to remember you can use the same password but add a
      different number each time a change is needed. For example password1,
      password2, password3 and so on.
    Looks like a well-known risk is not as widely-known as we might hope.
    But wait -- it now leaves the realm of "bad", and enters the "mad":
      The Password Hint is a word or phrase that you can choose to remind you of
      your password should you forget it. For example if your password is your
      pet's name then the password hint could be 'pet's name'.
      The Memorable Item is something that you will need to supply whenever you
      need to see your Password Hint. Again try use something that is linked to,
      and therefore will remind you of, your password and password hint.
    The usual way that Web sites provide for forgotten passwords is to set up a
    challenge-response, where the user gives a question that should be asked if
    they forget their password, and the answer they will give to prove who they
    are.  So you can pick things which you are (fairly) sure wouldn't be known
    by a miscreant, such as "what's the serial number on the back of your
    watch?" or "what was the name of your first girl/boyfriend?".  This has
    always seemed to me to be a secure enough system where you don't fear
    network snooping etc.
    But how am I expected to remember "something that is linked to, and
    therefore will remind you of, your password and password hint" in order to
    help me when I've forgotten my password?
    I know - maybe I'll write it down......
    Mike Perry, IBM UK Webserver Group
    Date: Fri, 17 Aug 2001 17:22:30 -0500
    From: Bill Lamb <blamat_private>
    Subject: Not such an equal opportunity
    I recently attempted to apply online for a position with Tarrant County
    College in Fort Worth, Texas.
    The first screen in the Web form was for Affirmative Action purposes and
    required such items as full name, address and Social Security number.
    Fortunately, I noticed there was no indication the connection had been
    secured: no warning from my browser and no "locked" icon in the browser
    window. I quit the site and e-mailed the school's HR department to report
    the problem and ask for a "snail mail" address to which to send my resume.
    Later that day I received a response from an HR employee stating the school
    accepts applications _only_ via the online forms, but they are indeed
    secure. Alternatively, I was welcome to visit the school's library to apply
    online using one of their machines if I still felt uncomfortable in doing so
    over the Internet.
    I again e-mailed, restating the problem with their supposedly secure
    connection, and noting that since I lived more than a hundred miles away I
    wasn't likely to visit the campus simply to fill out a form.
    Two days later I received a reply stating a "supervisor" would contact me
    shortly. That was five days ago. No supervisor yet.
    The risks of such a Web connection that may or may not be secure are
    obvious. But the hidden - and greater - risk here lies in the institution's
    apparent blind slavery to this new technology. While no doubt making their
    jobs easier, the policy of only accepting applications online closes off
    employment opportunities to an untold number of people simply because they
    may not have access to the Internet or live within bus, car or walking
    distance of the campus.
    Not such an Equal Opportunity Employer, after all, though I know that wasn't
    their intent.
    Bill Lamb   blamat_private  www.wmlc.net
    Date: Sat, 25 Aug 2001 19:07:02 -0400
    From: "Bob Frankston" <rmf2gRisksat_private>
    Subject: Re: Code Red 9? Code Crimson (McDonald, RISKS-21.62)
    By this reasoning, one shouldn't buy software from companies that write
    software in languages that don't make buffer-length checking the norm such
    as C and it's variants including C++. Languages such as Java, C# and PL/1
    don't suffer this unless programmers get too clever and try to squeeze out
    that extra nanosecond that an indirection may entail.  Remember that a
    computron saved means hours wasted!
    [Yes, I know this is a more complicated topic, but a vow of poverty isn't
    the answer to all problems -- not that I like being put in the position of
    defending Microsoft.]
    Date: Tue, 14 Aug 2001 07:32:12 -0400
    From: Peter_Simpsonat_private
    Subject: Risks of outsourced check verification
    I recently tried to pay for some clothing with a personal check at a large,
    national clothing store.  I was asked for a driver's license, which I
    produced, and the sale went through normally.
    I then went to a different department, and, again, tried to pay for more
    clothing with a check.  Produced my license.  The clerk told me the
    "transaction had been declined".  I asked why, and she handed me a cash
    register receipt with a code number and an 800 number.  I asked her if I
    could use her phone to call the number (hoping to straighten out whatever
    the problem was) and was told they could not use it to call outside numbers.
    When I got home, I called the number.  It was a third party check approval
    service.  The person on the other end of the line asked for my ID (license)
    number.  She then told me that the transaction had been declined because of
    "unusual check-writing activity".  I asked her exactly what that meant.  She
    told me that they had just approved my check number 202 and then tried to
    use check number 221.  The first clerk had transposed two digits while
    manually entering the check number.
    So, my second check was declined.  Of course, this "wasn't their fault", and
    "wasn't the first clerk's fault, either...people make mistakes".  My comment
    that this mistake could easily have been cleared up if I had been allowed to
    know why the check had been declined fell on deaf and uncaring ears.
    I liked it better when the manager was called and scribbled his initials on
    the check.
    Peter Simpson
    Date: Fri, 17 Aug 2001 16:03:58 -0400
    From: Sandy Antunes <sandyat_private>
    Subject: Can't hold room, but can bill
    I had a reservation (via phone) with the Hyatt for a trade show.
    Later I cancelled the credit card used to reserve it, so I called
    the Hyatt to give them a new card number.
    Problem 1: I couldn't find the confirmation number they'd given me.
    Problem 2: They couldn't find a reservation for me, and insisted I did
    	not have one.  And the hotel was booked for the entire trade show.
    Solution (mine): Booked at another hotel.
    ... time passes ...
    I get a statement from the _cancelled_ credit card, listing a charge by
    the Hyatt for 1 day's stay.  Oh oh.  I call the Hyatt.  The clerk is
    easily able to call up my record using the credit card number and
    verify that yes, I had a reservation and yes, I hadn't called to cancel
    it so I had to pay for 1 night.
    Oh, and they'd mistyped my name.  Which to me explained why they'd 'lost'
    my reservation in the first place.  He got manager approval to refund the
    credit charge because it lacked a "Cancellation Number", and it'll be at
    least one billing cycle before it goes through.
    So they couldn't find my information when I wanted to stay, but could find
    it to bill.
    Risks?  Reservation clerks not believing customer, inconsistent procedures
    and lookups, inaccurate data entry still being accepted by credit card
    company, cancelled card not rejecting charges, probably others.
    Sandy Antunes <aantunesat_private>
    Date: Sat, 18 Aug 2001 01:50:02 -0600
    From: "William Kucharski" <kucharskat_private>
    Subject: Caller ID vs. ANI confusion, again
    In Risks-21.57, Mike Tuffs writes about his credit-card company getting his
    phone number despite his having Caller ID blocked.
    Once again, there are two distinct and COMPLETELY SEPARATE systems that
    deliver calling phone numbers information to recipients.  The system used for
    toll-free numbers (which the author undoubtedly used to call his credit card
    company) as well as for long-distance call billing and for 911 services is
    called ANI.
    ANI CANNOT be blocked, at least not without making a significant (and likely
    questionably legal) effort to thwart the telephone system.
    I suspect the answer about ignoring the "ignore" bit is just a script they
    give the customer service people, or the agent was just making it up.
    The bottom line is that your calling number is delivered to the recipient of
    any toll-free call you make, whether in real time or via a billing statement,
    REGARDLESS of whether you have Caller ID blocked or not.
    William Kucharski <kucharskat_private>
      [Noted by quite a few readers, including the following.  TNX.  PGN]
    Date: Fri, 17 Aug 2001 16:44:13 -0400
    From: "John Clarke" <jclarkeat_private>
    Subject: Re: Mixing advertising and credit-card activation
    An interesting story, and possibly an urban legend, about ANI.  When
    computerized call centers were becoming the norm, a major credit-card
    company decided to use ANI to help the operators handle customer calls in a
    more friendly manner.  When a customer called from their home number, the
    computers would automatically match the number to the account holders name,
    even before the operator had picked up the call.  The operator would then,
    upon hearing the callers voice, respond with <Mr., Ms.> Account Name, how
    can I help you?
    Callers were so disturbed by the fact that the operator knew who they were
    before they had identified themselves that the credit-card company
    eventually told the operators to stop using this technique.  They still know
    who you are (or are likely to be), but withhold the info and allow you to
    provide it before they use it.  Customers are much happier with this method.
    When you call an 800 number and reach a call center, your file has likely
    already appeared on the agent's computer screen, whether they let you know
    that or not.
    Date: Mon, 27 Aug 2001 12:08:32 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Information Security Management Handbook", Tipton/Krause
    BKINSCMH.RVW   20010609
    "Information Security Management Handbook", Harold F. Tipton/Micki
    Krause, 2000, 0-8493-9829-0/0-8493-0800-3, U$155.00
    %E   Harold F. Tipton haltipat_private
    %E   Micki Krause Micki.Krauseat_private
    %C   2000 Corporate Blvd. NW, Boca Raton, FL   33431
    %D   2000
    %G   0-8493-9829-0, 0-8493-0800-3
    %I   Auerbach Publications
    %O   U$155.00 800-272-7737 auerbachat_private slintonat_private
    %O   available separately 0-8493-9829-0 $95.00 0-8493-0800-3 $59.95
    %P   2 vol., 711 p. + 626 p.
    %T   "Information Security Management Handbook, Fourth Edition"
    As an overview for the CISSP (Certified Information System Security
    Professional) CBK (Common Body of Knowledge), this work covers a vast range
    of topics.  The CBK, and the book, is divided into ten domains, covering
    access control systems, telecommunications, security management, systems
    development, cryptography, security architecture, operations security,
    business continuity, law and ethics, and physical security.  The text
    provides some excellent articles, some of which are general but detailed
    overviews, and others that address particular problems or new technologies.
    However, even with fifty nine articles and over thirteen hundred pages there
    are gaps, some surprisingly basic.
    The quality of the articles can vary widely.  The first essay, on
    biometrics, provides an admirable review of the subject, as well as some
    solid, practical, and useful detail information.  The next paper is a rather
    odd treatment of single sign-on, addressing the concepts well, but in a
    disjointed manner that makes reading or studying difficult.  Following those
    comes a paper ostensibly dealing with securing connections to external
    networks.  It collates some generic and vague descriptions of a variety of
    topics, none of which are particularly informative or reliable.  (A two-page
    section on computer viruses contains numerous glaring and significant
    errors.  Personally, I continue to find it appalling that general security
    texts deal so poorly with this topic.)
    Other areas covered are firewalls (terse), perimeter security for the
    Internet (again, but this time with excellent technical information on
    TCP/IP specifics), extranets (doctrinaire), firewall management (very useful
    for planning), the OSI (Open Systems Interconnections) network layer
    security model (questionable utility), the OSI transport layer security
    model (not much better), application layer security (interesting but
    undetailed), communications and security protocols (broad overview, concise
    but fills in some common gaps), security awareness training (reasonable
    points for success), security architecture (brief but basic), IPsec (good
    overview), risk analysis (thorough but perhaps a trifle pedantic), trade
    secret protection (an interesting twist), information security for
    healthcare (a tad verbose and US-centric), security for object-oriented
    databases (listing proposals), fundamentals of cryptography (very clear
    explanations of the math involved), key management (great review of
    principles, and amusing anecdotes from history of the *wrong* ways to manage
    keys), Kerberos (extensive coverage of both details and concepts), PKI
    (Public Key Infrastructure, a quick guide to the basics), microcomputer and
    LAN security (good concepts, overly optimistic, oddities in details),
    trapping intruders (quick concepts), Java security (quick basics), business
    continuity planning (a new process), restoration after disaster (general
    review), computer crime investigation (good coverage of many aspects),
    Internet ethics (emphasis on privacy), jurisdictional issues
    (miscellaneous), intrusion detection (concepts and evaluation points),
    single sign-on (opinion this time), authentication services (concepts and
    amusing overview), email security (concept review), ATM (Asynchronous
    Transfer Mode) security (without really discussing security), remote access
    (background fundamentals), sniffers (concepts and details), enclaves
    (firewalls within), IPsec (good details), penetration testing (very basic
    policies), policy (some good points but quite random), the security business
    case (opinion), PeopleSoft security (as for any major database), World Wide
    Web application security (reiteration of general security planning with a
    few Web specifics), common system design flaws (an important set), data
    warehouses (standard system development advice with limited security
    relevance), PKI (simplistic), introduction to encryption (a good one), new
    models for cryptography application (useful for planning), cryptanalysis
    (decent review of terminology), message authentication (detailed), UNIX
    security (concepts and tools), hacker tools (not very detailed), malicious
    code (theoretical and incomplete), business impact assessment (after Y2K),
    computer crime investigation (document everything), computer incident
    response teams (CIRTs, vague), intrusion detection (vague and repetitious),
    and operational forensics (retain evidence and data).
    Observant readers will have noted a fair amount of duplication in that list.
    In fact, the reiteration of content is worse than appears here, since many
    topics rely on others, and certain basic ideas (Kerberos operations, the
    Diffie-Hellman public key system, and risk management, for three examples)
    recur in a variety of other discussions, with differing levels of detail.
    As in any work this size a number of outright bizarre mistakes have
    occurred, like the table showing the file structure of an authentication
    database, which has been swapped with the structural diagram of a completely
    different authentication system.
    This is the closest thing there is to a textbook for the CISSP exam.  It is
    fairly easy to see which sections have been reproduced in the ISC(2)
    (International Information System Security Certification Consortium) course
    (in some cases complete down to specific errors).  Intriguingly, there are
    sections of the course that previously were covered by the third edition,
    and which do not appear in any significant form in this work.  (An example
    is the discussion of the standard formal security models, such as Bell-La
    Padula and Clark-Wilson.)
    It should be noted that there is a significant difference in character
    between the two volumes.  The first volume deals with topics that are closer
    to the heart of security, and the essays are generally more valuable to the
    practitioner.  Volume two contains papers over a wider range of subjects,
    many of which (with the notable exception of the pieces on cryptography)
    have little or no relevance to security beyond fundamental concerns that are
    well covered elsewhere.  Book one will be useful to the CISSP candidate and
    any specialty security worker: book two may be of interest to a narrower
    group of senior security executives and theorists, and, ironically, a wider
    audience of those interested in newer technologies in general.
    The quantity of good information that is contained in the work is
    definitely worth the price, but there could easily be a wholesale
    pruning of deadwood.
    copyright Robert M. Slade, 2001   BKINSCMH.RVW   20010609
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    Date: 12 Feb 2001 (LAST-MODIFIED)
    From: RISKS-requestat_private
    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-requestat_private> with one-line body
       subscribe [OR unsubscribe] 
     which requires your ANSWERing confirmation to majordomoat_private .  
     [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-requestat_private> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallat_private>.
    => 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 risksat_private 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.64

    This archive was generated by hypermail 2b30 : Sat Sep 01 2001 - 15:05:02 PDT