[risks] Risks Digest 22.51

From: RISKS List Owner (riskoat_private)
Date: Sun Jan 26 2003 - 15:52:45 PST

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

    RISKS-LIST: Risks-Forum Digest  Sunday 26 January 2003  Volume 22 : Issue 51
    
       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/22.51.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Keep it secret, stupid! (Matt Blaze)
    DoD offering admin privileges on .mil Web sites (Thomas C Greene via 
      Fuzzy Gorilla)
    A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ... (Monty Solomon)
    Drunk driver hack (David Wj Stringer-Calvert)
    TurboTax 'activation' annoys users (Monty Solomon)
    Spam continues to increase (Monty Solomon)
    Canadian Centre for Identity Theft? (Richard Akerman)
    NASTAR web site provides personal skier information to anyone 
      (Robert H'obbes' Zakon)
    Re: Hard-coded calendar dates (John Sullivan)
    REVIEW: "Internet Cryptography", Richard E. Smith (Rob Slade)
    REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Sun, 26 Jan 2003 17:46:49 -0500
    From: Matt Blaze <mabat_private>
    Subject: Keep it secret, stupid!
    
    Last year, I started wondering whether cryptologic approaches might be
    useful for the analysis of things that don't use computers.  Mechanical
    locks seemed like a natural place to start, since they provided many of the
    metaphors we used to think about computer security in the first place.
    
    So I read everything I could get my hands on about locks, which included
    most of the available open literature and at least some of the "closed"
    literature of that field.  Once I understood the basics, I quickly
    discovered, or more accurately re-discovered, a simple and practical rights
    amplification (or privilege escalation) attack to which most master-keyed
    locks are vulnerable.  The attack uses access to a single lock and key to
    get the master key to the entire system, and is very easy to perform.  For
    details, see
      http://www.crypto.com/masterkey.html
    
    I wrote up the attack, in a paper aimed more at convincing computer
    scientists that locks are worth our attention than anything else (I called
    it "Rights amplification in master-keyed mechanical locks").  As I pointed
    out in the paper, surely I could not have been the first to discover this --
    locksmiths, criminals, and college students must have figured this out long
    ago.  Indeed, several colleagues mentioned that my paper reminded them of
    their college days.  There is considerable evidence that similar methods for
    master key decoding have been discovered and rediscovered over the years,
    used illicitly and passed along as folklore (several people have unearthed
    Internet postings dating back as much as 15 years describing how to make
    master keys).  Curious college students -- and professional burglars -- have
    long been able to get their hands on master keys to the places that interest
    them.
    
    But the method does not seem to appear in the literature of locks and
    security, and certainly users of master keyed locks did not seem to know
    about this risk.  I submitted the paper to a journal and circulated it to
    colleagues in the security community.  Eventually, the paper reached the
    attention of a reporter at the New York Times, who wrote it up in a story on
    the front page of the business section last week.
    
    The response surprised me.  For a few days, my e-mail inbox was full of
    angry letters from locksmiths, the majority of which made both the point
    that I'm a moron, because everyone knew about this already, as well as the
    point that I'm irresponsible, because this method is much too dangerous to
    publish.  A few managed to also work in a third point, which is that the
    method couldn't possibly work because obviously I'm just some egghead who
    doesn't know anything about locks.
    
    Those letters, with their self-canceling inconsistency, are easy enough to
    brush aside, but there seems to be a more serious problem here, one that has
    led to a significant real-world vulnerability for lock users but that is
    sadly all too familiar to contemporary observers of computer security.
    
    The existence of this method, and the reaction of the locksmithing
    profession to it, strikes me as a classic instance of the complete failure
    of the "keep vulnerabilities secret" security model.  I'm told that the
    industry has known about this vulnerability and chosen to do nothing -- not
    even warn their customers -- for over a century.  Instead it was kept secret
    and passed along as folklore, sometimes used as a shortcut for recovering
    lost master keys for paying customers.  If at some point in the last hundred
    years this method had been documented properly, surely the threat could have
    been addressed and lock customers allowed to make informed decisions about
    their own security.
    
    The tragic part is that there are alternatives.  There are several lock
    designs that turn out to resist this threat, including master rings and
    bicentric locks.  While these designs aren't perfect, they resist completely
    the adaptive oracle attack described in my paper.  It's a pity that stronger
    alternative designs have been allowed to die a quiet death in the
    marketplace while customers, ignorant of the risks, have spent over a
    hundred years investing in inferior systems.
    
    Although a few people have confused my reporting of the vulnerability with
    causing the vulnerability itself, I can take comfort in a story that Richard
    Feynman famously told about his days on the Manhattan project.  Some simple
    vulnerabilities (and user interface problems) made it easy to open most of
    the safes in use at Los Alamos.  He eventually demonstrated the problem to
    the Army officials in charge.  Horrified, they promised to do something
    about it.  The response?  A memo ordering the staff to keep Feynman away
    from their safes.
    
    ------------------------------
    
    Date: Sun, 26 Jan 2003 14:29:34 -0500
    From: "Fuzzy Gorilla" <fuzzygorillaat_private>
    Subject: DoD offering admin privileges on .mil Web sites
    
    DoD offering admin privileges on .mil Web sites
    *The Register*, Thomas C Greene, 24 Jan 2003
    
    Care to register a .mil Web site of your own for free? The DoD has gone out 
    of its way to make it a snap. An unbelievably badly-protected admin 
    interface welcomes you to register whatever domain you please 
    (http://Rotten.mil anyone?), or edit anything they've already got. The 
    interface is so ludicrously unprotected that it's been cached by Google and 
    fails to mention that you must be authorized to muck about with it. 
    Incredibly, default passwords are cheerfully provided on the page.
    
    Following an anonymous tip from an observant Reg reader, we've encountered 
    the page in question in the Google cache, and after a bit of our own poking 
    about have also discovered an equally unprotected (and Google-cached) admin 
    interface encouraging us to add a new user, like ourselves, say, which 
    requires no authentication.
    
    All you have to do is find that page and you can set yourself up with a user
    account, manage your new .mil Web site, fiddle about with other people's
    .mil Web sites, and generally make an incredible nuisance of yourself. We
    are, of course, straining against every natural, journalistic impulse in our
    beings by neglecting to mention any useful search strings with which to find
    it.
    
    Another unprotected and cached page, this one discovered by our tipster, 
    lists traffic to a major DoD Web site by URL/IP address. This worries us 
    because it may list .mil sites and networked DoD machines that are not 
    public, not hotlinked anywhere, and which might contain (or be networked 
    with other machines that contain) sensitive data. Merely knowing that all 
    those URLs and IP addys are valid and owned by DoD would give a significant 
    advantage to attackers by narrowing their target area dramatically.
    
    We have e-mailed the person who manages these sites - twice in fact - but so 
    far have not been graced with a reply. We were hoping that they might be 
    inclined to fix this mess quickly so that we could safely include the 
    details in our report. Unfortunately we have to withhold them until we're 
    confident that these security snafus are under control.
    
    Ironically, US Defense Secretary Donald Rumsfeld recently ordered DoD to
    purge military Web sites of information that might benefit evildoers. That's
    all well and good, but it might behoove the DoD to stop offering them admin
    privileges first.
    
      http://212.100.234.54/content/55/29026.html
    
    ------------------------------
    
    Date: Fri, 24 Jan 2003 13:39:23 -0500
    From: Monty Solomon <montyat_private>
    Subject: A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ...
    
    A. Guadamuz
    Trouble with Prime Numbers: DeCSS, DVD and the Protection of 
      Proprietary Encryption Tools
    *The Journal of Information, Law and Technology* (JILT), 2002 (3)
    
    Andrés Guadamuz González
    Law Lecturer
    University of Edinburgh
    a.guadamuzat_private
    
    Abstract
    
    The DVD video format has become one of the most important developments in
    the home entertainment market since the popularisation of the magnetic video
    recording. The film industry delivered this format with a built in security
    system which was supposed to avoid illegal copying of the discs, much as
    what is taking place with the music CD and the almost indiscriminate copying
    of music into MP3 format over the Internet. This was achieved by means of
    encryption technology.
    
    This essay deals with the cracking of DVD encryption and its further
    diffusion as a computer programme named DeCSS, which has been made available
    over the Internet in various formats, including t-shirts and a numerical
    representation of the code. There are three court cases based on the online
    posting of this programme, two in the United States and one in Norway. The
    article starts by describing the technology involved, as it is felt by the
    author that some of these technical issues are of importance to the legal
    implications of the case and should be understood properly. The article then
    deals with the developments in all of the three cases up to this date. The
    essay then finishes with a look at the legal issues involved, including
    hyper-linking, trade secrets, freedom of speech and the translation of DeCSS
    into numerical format.
    
    This is a Refereed article published on 6 December 2002.
    
    http://elj.warwick.ac.uk/jilt/02-3/guadamuz.html
    
    ------------------------------
    
    Date: Wed, 22 Jan 2003 22:22:35 -0800
    From: "David Wj Stringer-Calvert" <david.stringer-calvertat_private>
    Subject: Drunk driver hack
    
    A 19-year-old in Besancon, France, was arrested for drunk driving.  Arriving
    for his court hearing, he discovered an unattended computer, and proceeded
    to erase his record -- replacing it with a winking smiley face.  The judge
    was not amused, and gave him a three-month suspended prison sentence, a $425
    fine, and a three-month suspension of his driving license.  [Source: Reuters
    item, From CNN.com, 21 Jan 2003; PGN-ed]
    
    ------------------------------
    
    Date: Sun, 26 Jan 2003 00:25:26 -0500
    From: Monty Solomon <montyat_private>
    Subject: TurboTax 'activation' annoys users
    
    A new "product activation" system in many 2003 editions of Intuit Inc.'s
    TurboTax software prevents people from letting anyone else use the CD-ROM
    on another computer in anything other than trial mode.
    [Source: Mike Musgrove, *The Washington Post*, 26 Jan 2003]
      http://www.washingtonpost.com/wp-dyn/articles/A40873-2003Jan24.html
    
    ------------------------------
    
    Date: Thu, 16 Jan 2003 22:38:57 -0500
    From: Monty Solomon <montyat_private>
    Subject: Spam continues to increase
    
    The number of spam messages sent increased nearly 300 percent from 2001 to
    2002 -- from 14,078,511 to 55,683,103, according to e-mail filtering company
    Brightmail.  If you think you're getting more spam than ever, you're
    right. Spam has dramatically increased in the past year.  And next year will
    be even worse.  One new report says that by July, the volume of spam sent to
    business e-mail addresses will exceed the amount of regular e-mail.
    [Source: *Newsfactor.com*, Janet Kornblum, 13 Jan 2003; PGN-ed]
      http://www.newsfactor.com/perl/story/20447.html
    
    ------------------------------
    
    Date: Wed, 15 Jan 2003 06:50:45 -0500
    From: Richard Akerman <rakermanat_private>
    Subject: Canadian Centre for Identity Theft?
    
    The National Archives of Canada already provide some Genealogy Research
    links and services 
    
    http://www.archives.ca/02/020202_e.html
    
    They are polling, as part of the Canadian Genealogy Centre initiative
    
    http://cgc-ccg.archives.ca/
    
    Earlier poll results have been released
    
    http://www.globeandmail.com/servlet/ArticleNews/PEstory/TGAM/20030106/UFAMIO
    Q/national/national/national_temp/3/3/14/
    
    http://www.canada.com/ottawa/story.asp?id=%7B64AA74C1-25C8-415A-8574-5EA6499
    47708%7D
    
    "Exactly half of those surveyed said they were either very interested (21
    per cent) or somewhat interested (29 per cent) in being able to search for
    all Canadian genealogical information on a single Internet site."
    
    Considering that most online and telephone credit card security consists of
    "shared secrets" such as: your name, address, phone number plus date of
    birth and mother's maiden name, this new Centre would seem to be an identity
    thief's paradise.
    
    Just to make things even easier, the current Archives Genealogy FAQ points
    people at telephone directories, which can fill in the name-phone-address
    triplet:
    
    http://www.archives.ca/02/02020201_e.html#8
    
    I don't see that any consideration of this risk has been taken into account.
    
    ------------------------------
    
    Date: Thu, 16 Jan 2003 13:56:44 -0500
    From: "Robert H'obbes' Zakon" <Robertat_private>
    Subject: NASTAR web site provides personal skier information to anyone
    
    NASTAR, the largest organization tracking amateur and professional ski races,
    is kind enough to post race results on its web site.  You can even search for a
    ski racer by name.
    
    By clicking on the ski racer's name, you get a page stating "I am <ski racer
    name> and I would like to login! [Click Here]".  If the skier has not done so
    before (and most probably don't even know about it), you are prompted to
    *create* a password, and can then access a page containing the racer's full
    home address and birth date!
    
    Seeing as NASTAR tracks not only professional racers, but amateur and community
    racers as well, they have quite an extensive database of individuals.
    
    After noticing the above behavior during last year's ski season, I e-mailed
    NASTAR and notified the local ski resort I race at.  Of course I never heard
    back from NASTAR, and could only hope their system would have been fixed for
    
    And I thought I just had to look out for trees...  No such luck though.
    
    ------------------------------
    
    Date: Mon, 6 Jan 2003 14:46:45 +0000
    From: John Sullivan <john.sullivanat_private>
    Subject: Re: Hard-coded calendar dates
    
    It's OK now though - they've fixed the JavaScript to read:
    
        document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2003");
    
    I'm stunned. There are just so many things wrong with this. First of all I
    can't see any benefit to using a client generated date string anyway - why
    not just get the server to fill it in - one assumes amongst other things
    the server's clock is going to be more reliable than any random client's,
    plus I think it really should be tied to the time of the last update
    rather than whatever time it happens to be read at.
    
    Second, the code immediately preceding initialises a variable called year
    - why, if they're just going to hard code the year as a string anyway? I
    suspect they had trouble deciding whether to add 1900 to the number
    returned from getYear or not. JS treatment of this varies between browser
    versions, and support for the improved getFullYear method may be patchy,
    but again a server filled date would solve this. (Actually, getFullYear is
    now sufficiently old for cross-browser support to be probably good enough.)
    
    Thirdly, if you're doing it on the client, why not just use the Date
    object's own string formatting capability? The paper is English language
    only and none of the rest of the site is going to respond to the client's
    locale settings so I can see a stylistic point to fixing the date to the
    paper's own preferred format, but at least the Date object would get the
    year right without additional hackery.
    
    ------------------------------
    
    Date: Tue, 21 Jan 2003 08:14:34 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Internet Cryptography", Richard E. Smith
    
    BKINTCRP.RVW   20021215
    
    "Internet Cryptography", Richard E. Smith, 1997, 0-201-92480-3,
    U$29.95/C$44.95
    %A   Richard E. Smith internet-cryptoat_private
    %C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
    %D   1997
    %G   0-201-92480-3
    %I   Addison-Wesley Publishing Co.
    %O   U$29.95/C$44.95 416-447-5101 fax: 416-443-0948 bkexpressat_private
    %O  http://www.amazon.com/exec/obidos/ASIN/0201924803/robsladesinterne
    %P   356 p.
    %T   "Internet Cryptography"
    
    According to the preface, this book is aimed at non-specialists who
    need to know just enough about cryptography to make informed technical
    decisions.  As an example, Smith suggests systems administrators and
    managers who, while not formally charged with security, still have to
    use cryptographic techniques to secure their networks or
    transmissions.
    
    Chapter one is an introduction, contrasting what we want; secure
    communications; with the environment we have to work in; a wide open
    Internet.  The text also looks at the balance that must be maintained
    between convenience and requirements.  Encryption basics, in chapter
    two, presents the concepts of symmetric cryptography, use, and choice. 
    There is a clear explanation of the ideas without overwhelming
    technical details.  (It is interesting to note how quickly the
    cryptographic technology changes: SKIPJACK and ITAR were still
    important when the book was written, and are now basically
    irrelevant.)  Some random thoughts on network implementation of
    encryption are given in chapter three.  Managing secret keys, in
    chapter four, provides good conceptual coverage of generation and
    management, although the discussion of the problems of key escrow is
    weak.  Because of the requirements for technical details when
    discussing protocols, chapter five, on IPSec, is different from other
    material in the book.  It also includes a brief mention of other
    protocols.  Chapter six discusses the use of IPSec in virtual private
    networks, while seven examines IPSec in terms of remote access. 
    Chapter eight looks at IPSec in relation to firewalls, but it is
    difficult to see how this would be used in an actual application.
    
    Chapter nine reviews public key encryption and SSL (Secure Sockets
    Layer).  The basic concepts of asymmetric cryptography are presented
    well, but may be unconvincing due to the lack of mathematical support
    and details.  While there is an introduction to the related idea of
    digital signatures, SSL is really only barely mentioned.  World Wide
    Web transaction security, in chapter ten, provides practical examples
    of the technologies discussed.  The same is true of email, in chapter
    eleven, but digital signatures get a bit more explanation.  Chapter
    twelve builds on the signature concept to introduce PKI (Public Key
    Infrastructure) notions.
    
    The fundamentals are written clearly and well, and are quite suitable
    for managers and users.  Despite the lack of detail, the text may even
    be suitable for some security professionals who need a rough
    background without needing to work with the technology itself.  The
    work is easy to read, although the idiosyncratic structure may be
    confusing, and the value of some chapters questionable.
    
    copyright Robert M. Slade, 2002   BKINTCRP.RVW   20021215
    
    
    ======================  (quote inserted randomly by Pegasus Mailer)
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    A fanatic is one who can't change his mind and won't change the
    subject.                                         - Winston Churchill
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: Wed, 22 Jan 2003 08:24:16 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker
    
    BKCRPDEC.RVW   20021215
    
    "Cryptography Decrypted", H. X. Mel/Doris Baker, 2001, 0-201-61647-5,
    U$29.95/C$44.95
    %A   H. X. Mel www.hxmel.com
    %A   Doris Baker
    %C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
    %D   2001
    %G   0-201-61647-5
    %I   Addison-Wesley Publishing Co.
    %O   U$29.95/C$44.95 800-822-6339 fax 617-944-7273 bkexpressat_private
    %O  http://www.amazon.com/exec/obidos/ASIN/0201616475/robsladesinterne
    %P   352 p.
    %T   "Cryptography Decrypted"
    
    The book seems to be rather ambitious, since the preface says that it
    is addressed to any (and therefore all) audience(s), without any
    limitation on the stated purpose.  In general, it is an attempt to
    portray the basic concepts of cryptography, without getting too far
    into technical details.  Many other books have tried to do the same
    thing, and signally failed.  Mel and Baker by and large succeed.
    
    Part one addressed secret key (symmetric) cryptography.  Chapter one
    tries to draw an analogy between locks and encryption, although the
    relation is strained at best.  Substitution, frequency analysis, and
    polyalphabetic ciphers are covered in chapter two.  Chapter three
    introduces transposition.  The Polybius square is used, in chapter
    four, as an example of the combination of substitution and
    transposition.  For those in the know, this leads nicely into the
    discussion of DES (Data Encryption Standard), in chapter five,
    although the neat segue would be lost on most readers, since the
    details of DES are not given.  The history of cryptography appears
    rather abruptly in chapter six.  Chapter seven covers the attempts to
    use cryptographic methods for confidentiality, integrity,
    authentication, and non-repudiation, and shows that the last point is
    not possible with purely symmetric cryptography.  A simplistic
    examination of key exchange is given in chapter eight.
    
    Part two deals with public key (asymmetric) encryption.  Chapter nine
    is a confusing introduction using the Merkle puzzle space (with some
    mention of Diffie-Hellman) as the example.  A simplistic review of
    public key encryption is in chapter ten.  Math tricks, in chapter
    eleven, seems pointless as it begins, but the development to the
    examples of modular inverses do provide both a basic form of
    asymmetric cryptography, and a demonstration of the mathematical
    concepts underlying more advanced cryptographic algorithms.  Chapter
    twelve introduces authentication and digital signatures, with hashes
    and message digests in chapter thirteen, and a discussion of digest
    assurances (reviewing collisions and encrypted message authentication
    codes) in fourteen.  A comparison of cryptographic strength and speed
    (between symmetric and asymmetric systems) is in chapter fifteen.
    
    Part three covers the distribution of public keys, and introduces some
    of the concepts of PKI (Public Key Infrastructure).  Chapter sixteen
    deals with certificates.  The title of chapter seventeen relates to
    the X.509 certificate structure, but the topics covered mostly concern
    hierarchical certificate authorities.  PGP (Pretty Good Privacy) and
    the "Web of Trust" model are explained in chapter eighteen.
    
    Part four looks at real world systems and actual applications. 
    Chapter nineteen explains email security, but in a generic fashion. 
    SSL (Secure Sockets Layer) is clearly described in chapter twenty,
    but, given the lack of detail in the rest of the book, the technical
    material is rather odd.  IPSec, in chapter twenty one, is presented in
    a confused manner.  Various problems of, and attacks against,
    cryptography are outlined in chapter twenty two.  The final chapter is
    a simplistic review of the storage of cryptographic keys on smart
    cards.
    
    This book does present most of the core concepts in cryptography.  The
    text is readable, and, within the limited scope of the material,
    generally accurate.  For non-specialists, it is a reasonable
    introduction to the topic.  This might even include security
    professionals who are not directly involved with cryptographic
    systems.  However, the lack of detail in the explanations of the
    theory is a weakness, since the text would be more convincing with
    more background.
    
    copyright Robert M. Slade, 2002   BKCRPDEC.RVW   20021215
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 29 Mar 2002 (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 Majordomo balks when you send your accept, please forward to risks.
     [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 21" for volume 21]
     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 22.51
    ************************
    



    This archive was generated by hypermail 2b30 : Sun Jan 26 2003 - 21:13:30 PST