[risks] Risks Digest 21.69

From: RISKS List Owner (riskoat_private)
Date: Mon Oct 15 2001 - 06:16:00 PDT

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

    RISKS-LIST: Risks-Forum Digest  Monday 15 October 2001  Volume 21 : Issue 69
       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.69.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    New class of wireless attacks (Gary McGraw)
    Reducing risks to hospital patients (Mike Martin)
    Ukraine missile apparently downs Russian airliner (Hanan Cohen)
    SirCam redux (Gavin Scott)
    A risk from Excel and Outlook (Will Middelaer)
    Outlook for Thanksgiving (Patrick Lincoln)
    Billion-seconds bug (Massimo Dal Zotto)
    Risks of undocumented 'standards' (Lloyd Wood)
    Re: Ham radios in the aftermath of 11 September 2001 (Todd Jonz,
      Mitch Collinsworth)
    Re: Remote control of airliners (Alan Wexelblat)
    Re: Sincerely yours, *Not* Osama bin Laden? (Nick Brown)
    Re: TurboMedical (Dick Karpinski)
    Public information campaign on privacy (Ben Hutchings)
    Re: Hackers and others win big in Net casino attacks (R.S. Heuman)
    REVIEW: "The CERT Guide to System and Network Security Practices", J.H. Allen
      (Rob Slade)
    Abridged info on RISKS (comp.risks)
    Date: Mon, 15 Oct 2001 08:30:07 -0400
    From: Gary McGraw <gemat_private>
    Subject: New class of wireless attacks
    Bob Fleck, a security consultant at Cigital, working with Jordan Dimov, has
    discovered new class of wireless attacks that  can be used to gain
    unauthorized access to normally-protected machines on a standard wire-based
    internal network.   Wireless networks involve installation of a wireless
    Access Point on a normal internal network.  This Access Point is  usually
    connected to the wired network through a switch or a hub.  The attacks
    discovered by Cigital are based on an  adaptation of a well understood
    network attack from the non-wireless world known as ARP cache poisoning.
    This  emphasizes the importance of re-considering old risks in light of new
    technologies, something that is especially important in  software-based
    The new class of attacks encompasses:
    1) the ability to monitor and manipulate traffic between two wired
       hosts behind a firewall
    2) the ability to monitor and manipulate traffic between a wired host
       and a wireless host
    3) the ability to compromise roaming wireless clients attached to
       different Access Points
    4) the ability to monitor and manipulate traffic between two wireless clients
    Previous wireless attacks have demonstrated that wireless traffic on an
    802.11b network is vulnerable to monitoring and manipulation, even when it
    is "protected" with WEP encryption.  This new class of attacks discovered by
    Cigital is based on abusing the Address Resolution Protocol (ARP) which
    binds internal IP addresses to ethernet addresses.
    Mitigating the risks of these attacks is possible.  The best fix involves
    placing a technical barrier between the wireless network and the normal
    wired network.  This provides only a partial solution that leaves the
    wireless network in a compromised state, though it protects against the
    worst of the attack class Cigital discovered.  Further risks can be
    mitigated through advanced design of any and all software applications that
    make use of the wireless network.
    Bob Fleck (fleckat_private) and Gary McGraw (gemat_private)
    For more, see:
    Date: Fri, 5 Oct 2001 15:06:50 +1000 
    From: "Martin, Mike" <mike.martinat_private>
    Subject: Reducing risks to hospital patients
    Spectacular accidents to hospital patients are always newsworthy.
    Recent cases include a patient in the UK who died after the wrong kidney was
    removed, and a boy killed by a flying oxygen cylinder (RISKS 21.55). But
    according to Dr Brent James, Executive Director of Intermountain Health Care
    in Utah, the overwhelming majority of cases of patient harm are from
    mundane, and preventable, causes.
    Interviewed recently on Australia's Radio National by Dr Norman Swan,
    <http://www.abc.net.au/rn/talks/8.30/helthrpt/stories/s380415.htm> , James
    said that of 3996 cases of moderate or severe adverse drug events that his
    organisation identified over a ten year period, only 3.5 per cent resulted
    from a human error. The rest of the confirmed 4155 human errors over the
    period "were caught before they actually led to injury, or the patient
    suffered such a minor consequence that it wasn't classified as an injury".
    In other words, concentrating on human error will cause 96.5 per cent of
    injuries to be overlooked.
    Furthermore, James said that the majority of adverse drug events were not
    reported through the voluntary reporting system on which most hospitals
    depend, and indeed many are not being even recognised by patient care staff.
    Using a computer-based system to detect evidence of morphine overdoses,
    James found that 80 (yes, eighty) times as many events were occurring as
    were being reported. By using a computer system containing information about
    drugs' potential for allergy reactions, and that tailored drug doses
    specifically to each patient, his organisation has been able to cut the
    adverse drug event rate associated with such reactions by more than 50 per
    A simple systems change in treatment of patients with congestive heart
    failure in his organisation means, James estimates, that 310 lives are being
    saved each year, patients who otherwise would have died.
    It seems people in the health system are beginning to apply principles long
    used by safety analysts in aviation and other industries. (James was a
    member of the Quality of Health Care in America Committee of the Institute
    of Medicine that created the 1999 report, "To Err is Human". Its executive
    summary noted, "Health care is a decade or more behind other high-risk
    industries in its attention to ensuring basic safety.")
    The key principles in James's attack on the problem appear to be: 
    *	focus on injuries, rather than human errors;
    *	encourage (and indeed reward) injury reporting (and protect from
    *	improve systems so that it's easy to do things right and hard to do
    them wrong;
    *	assign accountability for safety improvement;
    *	measure outcomes.
    Use of computer technology is key to collecting and using data and
    instituting process control to support these principles.
    On top of improving patient experience and saving lives, James said, "...
    the old belief that quality means spare no expense, just turned out not to
    be a good model. A better model is do it right the first time. It looks like
    that could save as much as 15% to 25% of our total cost of operations."
    Mike Martin  Sydney <mike_martinat_private>
    Date: Sat, 13 Oct 2001 06:47:31 -0700 (PDT)
    From: Hanan Cohen <hanan_cohenat_private>
    Subject: Ukraine missile apparently downs Russian airliner
    While searching for early information on the Sibir Airlines TU-154 crash, 
    I went to the website of Russian newspaper Pravda and was surprised to see 
    that they have a special section for accidents.
    I think the editors of Pravda are RISKS readers!
    Ukraine Admits Missile Might Have Downed Airliner
      ``The cause may have been an accidental hit from an S200 rocket fired
      during Ukrainian exercises,'' Evhen Marchuk, head of Ukraine's National
      Security Council, told a news conference to present crash investigators'
      preliminary findings.
    The plane crash would be the second time in 18 months that Ukraine's armed
    forces have lost control of a live missile.  Last year, four people were
    killed in the town of Brovary when a rocket plowed into their apartment
    block. The defense ministry denied responsibility for several days until
    rescue workers found missile parts in the rubble.
    Date: Tue, 9 Oct 2001 14:46:34 -0700
    From: "Gavin Scott" <gavinat_private>
    Subject: SirCam redux
    For the past week I've been receiving hundreds of e-mails from a user
    apparently infected with the "SirCam" virus.
    Ho-hum, old risk, nothing new.
    But in this case the virus has included an interesting document scavenged
    from the user's computer.  The infected machine appears to belong to a
    Clinical Assistant Professor at the UCLA Department of Radiation Oncology,
    and the document is a 13 page Word .DOC form titled:
      (Human Use)
    and includes fields for the name, SSN, and Date-of-birth of all the
    personnel involved, radioactive compounds to be used, their dosages, whether
    the Principal Investigator has graduated from High School, and so on.
    Fortunately in this case the document is not filled out, and the SirCam
    virus is apparently "defective" in that each time it runs it is selecting
    the same document to send out, but of course it's not much of a stretch to
    imagine even more sensitive medical documents being sprayed across the
    Internet indiscriminately.
    Another example of an organization which Ought To Know Better failing in
    basic security, and of the tenacity of recent viruses (or perhaps the
    stubbornness of end-users) as UCLA's people have been unable to stem the
    tide of e-mail from the virus five days after having been informed of the
    problem (though their security people were quick to respond to an e-mail
    suggesting that medical documents were being distributed).
    P.S. 22 more copies of the virus arrived during the composing of this
    message.  Oops, 27 now.
      [This risk certainly needs to be SirCamVented.  PGN]
    Date: Mon, 8 Oct 2001 13:05:38 -0700 (PDT)
    From: Will Middelaer <betamaleat_private>
    Subject: A risk from Excel and Outlook
    I stumbled across this risk when an astute coworker wondered why opening an
    apparently short e-mail took an inordinate amount of time to open, even for
    our slow connection to a remote outlook server.  I sent him an e-mail
    composed of one short sentence of plain text followed by (what I thought
    was) a two column by ten row grid of excel cells.  I put the cells into the
    e-mail by highlighting them in Excel, then copying and pasting them into an
    What I did not know was that the e-mail message actually contained the
    entire 12,000 plus cells of the spreadsheet including formatting and
    formulas.  Though it appears to contain only the 20 cells that I intended to
    send him, double clicking the cells in the e-mail launched Excel, which
    opened with a complete version of the spreadsheet from which I had selected
    the cells to send him.  The only piece of information missing seems to be
    the name of the file, as it opens with a generic name.
    The risk: releasing quite a bit more information (plus structure of the
    spreadsheet itself) to an e-mail recipient to whom you intended to send only
    part of the spreadsheet, and the risk of an application being a bit too
    (Versions are Outlook 2000 Corporate or Workgroup, Excel 2000.)
    Will Middelaer <will.removeat_private>
    Date: Wed, 10 Oct 2001 07:34:46 -0700
    From: Patrick Lincoln <lincolnat_private>
    Subject: Outlook for Thanksgiving 
    It seems that in some versions of Microsoft Outlook, Thanksgiving 2001 is
    marked as 29 Nov.  In fact, Thanksgiving is early this year, on 22 Nov.
    Date: Thu, 11 Oct 2001 19:56:58 +0200 (MEST)
    From: Massimo Dal Zotto <dzat_private>
    Subject: Billion-seconds bug
    As everybody knows, on Sep 09 01:46:40 2001 GMT the system clock of every
    UNIX system made the transition from 999999999 seconds to 1000000000.  After
    having survived the millennium bug we believed that the "billion seconds bug"
    wouldn't happen, since the UNIX time is stored as a 32-bit integer.
    I have, however, been witness of a real "billion seconds bug" that hit a
    medical application distributed by a top company in the medical sector.  (No,
    I won't name the company.)
    On September 11, a colleague told me that he and other technicians were
    having strange problems with an archiving application that was unable to
    initialize new cdroms. After a quick investigation, we discovered that the
    automatically generated cd label contained a UNIX timestamp that after Sep
    09 01:46:40 passed from 9 to 10 characters, resulting in an invalid label
    not recognized by the application that was expecting a fixed-length label.
    An interesting side effect of this has been a sudden rise in orders of cd-rw
    drives that were initially blamed as the cause of the problem.
    Massimo Dal Zotto, Via Marconi, 141,  38057 Pergine Valsugana (TN) Italy
     ++39-0461534251  www: http://www.cs.unitn.it/~dz/  dzat_private
    Date: Tue, 9 Oct 2001 17:17:23 +0100 (BST)
    From: Lloyd Wood <eep1lwat_private>
    Subject: Risks of undocumented 'standards'
    Andrew Tridgell is quoted as saying of the SMB protocol
      The protocol is so incredibly convoluted and bloated and badly designed --
      there are ten ways of doing everything. You end up with these massive
      exchanges going on the wire between Windows 95 and NT, just because they
      are trying to work out exactly which sets of bugs the other guy has so
      they can figure out how to actually stat a file or find its size or date
      or something. And we've found from talking to people who work at Microsoft
      how much of a headache it is to maintain the damned thing and keep it
      secure. So, they've got to be thinking of dropping it at some stage.
    As also shown by Microsoft's office document formats (RISKS passim), the
    risk here is that an unpublished design with gradual increments and a focus
    on implementation interoperability at all costs leads to baroque, complex
    implementations, a shifting feature set, and emergent, undesirable side
    effects. It's like building on sand; eventually you spend all your time just
    shoring up the existing structure.
    There's a lot to be said for having published, fixed revisions of documented
    standards, for implementations to adhere to, in minimising such risky
    Date: Fri, 12 Oct 2001 22:28:33 -0700
    From: Todd Jonz <toddat_private>
    Subject: Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68)
    In RISKS 21.68 Richard Murnane <RichardMat_private> writes:
    	> 570 Amateur (ham) Radio operators from 35 states and two
    	> Canadian provinces provided auxiliary radio communications...
    What Richard's message didn't mention are the numerous pressures,
    particularly in the U.S., that put volunteer communications services like
    these at risk.
    In the U.S. the radio spectrum used for these communications is either
    dedicated to the Amateur Radio Service, or shared with other services.  But
    a variety of commercial interests, from cellular telephone companies to
    package shippers to low earth orbit satellites operators, have had their eye
    on this spectrum for quite some time and never miss an opportunity to
    attempt a "land grab."  Unfortunately, sometimes they are successful.  In
    this age of spectrum auctions that generate revenue for the federal
    government, the amateur radio community must continually struggle to retain
    its spectrum allocations.
    Identical bills in the House of Representatives (HR 817) and the Senate (S
    549) known as The Amateur Radio Spectrum Protection Act of 2001 would
    protect these allocations.  These bills have a broad base of bipartisan
    support, with 44 co-sponsors in the House and seven in the Senate.
    Nevertheless, although these bills have been introduced in previous sessions
    of Congress, they have never made it to a floor vote in either house.
    Additional information about The Amateur Radio Spectrum Protection Act of
    2001 can be found at:
    RISKS readers who feel inclined to contact their Congressional
    representatives in support of these bills will have my gratitude and, I'm
    sure, the gratitude of the entire amateur radio community.
    Todd Jonz, KB6JXT <toddat_private>
    When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
    Date: Sat, 13 Oct 2001 14:33:55 -0400 (EDT)
    From: Mitch Collinsworth <mitchat_private>
    Subject: Re: Ham radios in the aftermath of 11 September 2001 (Murnane, R-21.68)
    And the RISK that this points out is that if local government regulations,
    restrictive covenants, and tenant organization rules continue to make it
    more and more difficult/impossible for Amateur Radio operators to put up
    antennas for their stations, the day will eventually come when this nearly
    free backup communication system will no longer be available in times of
    Hams have "been there" for their communities, nations, neighbor communities,
    and neighbor nations in times of trouble for many, many years.  The value of
    their service needs to be recognized, and their right to assemble functional
    radio stations needs to be guaranteed rather than restricted.
    Mitch Collinsworth, K2VD
    Date: Tue, 9 Oct 2001 13:09:51 -0400
    From: Graystreak <wexat_private>
    Subject: Re: Remote control of airliners (Bellovin, RISKS-21.68)
    NPR had a fairly extensive discussion of the alternate-control proposal.
    One key element of the scheme being proposed is a weighted voting system,
    with weights assigned based on degree of deviation from preapproved flight
    I regret not writing down the name of the expert interviewed (though writing
    while driving has its own risks :).  He seemed quite reasonable and spent a
    good portion of the interview discussing possible failure scenarios.
    He noted that ground facilities such as control towers and transmission
    facilities are in fixed locations that are easier to secure, easier to
    harden, and easier to retake in the event of hostile takeover than an
    airplane cockpit.
    If all else fails, the control signal could be sent from an alternate ground
    site, and this is where the discussion of the deviation-from- flight-plan
    algorithm came in.  In essence, if the plane's control computers received
    conflicting signals (say, from cockpit controls and from a ground station)
    they would give more weight to those signals closer to the original flight
    The criminal acts of 11 Sep required significant deviation from flight plans
    over an extended period of time.  If an order to take such a significant
    deviation can be overridden by another order saying "stick to plan; fly to
    LAX; land normally there" then you reduce the number of possible disaster
    scenarios significantly.
    Of course, this is not a total solution - we can all easily think of
    sequences of events that would lead to this kind of system failing.  In
    addition, the system would need good specification in order not to interfere
    in standard emergency situations (onboard fire, engine failure, passenger
    with heart attack, etc).  But a system of this sort raises the bar to
    hijacking substantially, requiring the acquisition and use of much higher
    levels of technology than simple 'box cutters.'  Such technology and
    training is clearly not out of the reach of all criminals, but it is out of
    the reach of most.
    I am in favor of continuing investigation and testing of such systems, as
    they seem more directly focused on preventing known bad scenarios.  By
    contrast, most of the responses proposed so far by the FAA and Congress seem
    to have little bearing on the scenarios as we understand them at this point.
    Alan Wexelblat <wexat_private>  http://wex.www.media.mit.edu/people/wex/
    CHI'02 Panels Chair 		moderator, rec.arts.sf.reviews
    Date: Thu, 11 Oct 2001 14:24:04 +0200
    From: Nick Brown <Nick.BROWNat_private>
    Subject: Re: Sincerely yours, *Not* Osama bin Laden? (RISKs 21.68)
    >A Filipino in Belgium ended up in jail after *receiving* a joke e-mail
    It turns out on reading the article that the message in question was an SMS
    text message sent on a GSM phone.  I cannot believe that the people who (in
    the name of freedom of course) monitor telephone traffic are grepping SMS
    messages for "Osama bin Laden", on the off chance that he signs them
    himself.  But if they are doing so, I guess they're reading this too, so "hi
    guys" !
    Nick Brown, Strasbourg, France
    Date: Tue, 9 Oct 2001 00:56:09 -0700 (PDT)
    From: Dick Karpinski <dickat_private>
    Subject: Re: TurboMedical (RISKS-21.68)
    The RISK I noticed in TurboMedical (sm) is that it instructs the applicant
    in exactly what lies to tell the FAA to get through. Thus it may be a RISK
    of FAA practices rather than of the use of computers.
    Date: Fri, 5 Oct 2001 20:04:45 +0100
    From: Ben Hutchings <benat_private>
    Subject: Public information campaign on privacy
    The UK's Information Commissioner, a part of the government with which
    databases of personal information are supposed to be registered, is running
    a series of poster ads encouraging people to be careful with their personal
    information. For example, one ad says "When your bank rings you up asking
    questions, do you ever make sure it really is the bank?"
    While the message may be familiar to RISKS readers, it's heartening to see
    it brought to public attention - and somewhat surprising to those of us who
    consider the current government to have little regard for personal privacy.
    Ben Hutchings <benat_private>  http://womble.decadentplace.org.uk
    Date: Tue, 02 Oct 2001 10:32:58 -0400
    From: rshat_private
    Subject: Re: Hackers and others win big in Net casino attacks (RISKS-21.67)
    Your added statement to Ken Nitz' item about illegal Internet gambling
    parlours ignores the simple fact that they are NOT illegal in many
    jurisdictions outside the US, and that US law does not apply outside the
    US. [Also, it was two of their sites that had been hacked, not one...]
    An example of the latter statement is:
    which is an interesting risk of publishing on the Internet where US law is
    NOT accepted as primary.
    R.S. (Bob) Heuman, Toronto, ON, Canada
    Date: Wed, 10 Oct 2001 07:54:02 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "The CERT Guide to System and Network Security Practices", Julia H. Allen
    BKCGSNSP.RVW   20010728
    "The CERT Guide to System and Network Security Practices", Julia H.
    Allen, 2001, 0-201-73723-X, U$39.99/C$59.95
    %A   Julia H. Allen
    %C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
    %D   2001
    %G   0-201-73723-X
    %I   Addison-Wesley Publishing Co.
    %O   U$39.99/C$59.95 416-447-5101 fax: 416-443-0948 bkexpressat_private
    %P   447 p.
    %T   "The CERT Guide to System and Network Security Practices"
    The preface states that the intended audience for this work is the mid-level
    system and network administrator.  Actually, it uses the plural, giving the
    first indication that this text is only intended for those working in very
    large organizations.  Chapter one is an overview of the structure of the
    book, along with a listing of some other resources, and a few general
    security definitions.
    Part one deals with securing or hardening computers against attack.  Chapter
    two lists good practices for servers and workstations, providing basic
    guidelines.  There is something of a detailed breakdown of these
    conventions, as well as considerations that might be useful in policy
    discussions.  However, these are not procedures, and there is very little in
    the way of system detail.  The reader is advised to limit services running
    on computers.  This is a good practice, but there is nothing to indicate how
    to find out what services are running, nor how to limit or eliminate them
    once they are found.  A number of assumptions have been implicitly made, for
    example about centralized administration policy, so even the material that
    is included may not be suitable for all environments.  The explanations are
    reasonable, but rather pedestrian, and there is a great deal of duplication
    of material (the sections dealing with limiting services running on servers
    and workstations, for example, are almost identical.)  Much the same is true
    of securing public web servers, in chapter three.  Some material is quite
    specific (specifying the Common Log Format, CLF, for activity files) while
    other recommendations are vague.  Deploying firewalls, in chapter four, is a
    bit different, in that it does contain some explanation of firewall types
    and architectures.  Unfortunately, this text is very brief, and is padded
    out with unilluminating illustrations.
    Part two examines intrusion detection practices.  Chapter five covers the
    preparation and setup of intrusion detection, chapter six the actual
    detection of intrusions, and chapter seven outlines responses to intrusions.
    Overall, part two is more useful than part one, since intrusion detection is
    a newer field, and general concepts are still helpful even if specific
    details are lacking.
    Given the complaints I have made about the lack of details, some will
    respond that I have, heretofore, ignored the fact that there are two
    appendices in the book, dealing with security implementations and practices.
    True, these documents exist.  In terms of the security implementations, if
    you are using Solaris 2.x, Tripwire, Logsurfer, and Snort, the additional
    material may be very useful.  Otherwise, it still doesn't address the lack
    of specifics in the book.
    This work does provide the security specialist, faced with responsibility
    for policy creation or maintenance, a handy set of checklists and some
    framework for the policy process.  Use of the text will help remind the
    professional of areas to be addressed, and prevent certain aspects from
    slipping between the cracks.  The advanced and experienced system
    administrator may also benefit from the volume, since he or she will likely
    already know system specifics for a number of the functions required, and
    probably has some idea of where to find information about others.  However,
    intermediate sysadmins, with an "engineer" level certificate and a few
    years' work experience, are unlikely to know the details of security
    operations that have, usually, been seen as a specialty area.  Therefore,
    the audience which will find this book to be useful is a rather narrow one.
    copyright Robert M. Slade, 2001   BKCGSNSP.RVW   20010728
    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.69

    This archive was generated by hypermail 2b30 : Mon Oct 15 2001 - 07:08:27 PDT