[risks] Risks Digest 21.80

From: RISKS List Owner (riskoat_private)
Date: Sat Dec 01 2001 - 12:04:43 PST

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

    RISKS-LIST: Risks-Forum Digest  Saturday 1 December 2001  Volume 21 : Issue 80
       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.80.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Badtrans "worm" can capture keystrokes (NewsScan)
    Records stolen in Auckland (Richard A. O'Keefe)
    Calif info: Ask and you shall be removed ... but you've got to ask (NewsScan)
    "Light turnout" for election (G R Rhodes)
    The destruction of 7 WTC (Jacob Harris)
    Connecticut Attorney General website wants Microsoft browsers? (Ed Ravin)
    How to crash a phone by SMS (Monty Solomon)
    The Web Never Forgets (Monty Solomon)
    Risks of computer security education (David Friedman)
    Re: Let's get really paranoid about e-mail and spam (Walter Dnes,
      Jason Bennett)
    Re: Risks of the space in Unix filenames (David A. Moon, Richard A. O'Keefe)
    REVIEW: "Hackers Beware", Eric Cole (Rob Slade)
    Abridged info on RISKS (comp.risks)
    Date: Tue, 27 Nov 2001 08:28:53 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Badtrans "worm" can capture keystrokes
    A malicious program called Badtrans is moving around the Internet and
    worming itself into vulnerable computers and using a keystroke logger to
    surreptitiously record passwords, credit data, and other information.  A
    virus manager at the security firm McAfee says that the worm "does no damage
    to files but does drop a backdoor trojan on the machine which would allow a
    hacker to come back and access personal information."  Badtrans spreads
    through Microsoft's Outlook or Outlook Express e-mail programs and arrives
    with an attachment that can be executed simply by reading or previewing it
    and doesn't need to be double-clicked or opened separately.  [Reuters/*San
    Jose Mercury News*, 27 Nov 2001; NewsScan Daily, 27 Nov 2001]
      [Incidentally, we received a lot of e-mail on Magic Lantern.  Let me
      summarize a little.  Rob Slade questioned whether it was a virus in
      RISKS-21.78.  This is an old battle, because "virus" has become
      overloaded.  Peter da Silva and PGN both insist it is a Trojan Horse.
      Let's get on with it, and use the terminology correctly.  There was some
      discussion on whether or not McAfee et al. will suppress detection of an
      FBI-planted virus, vague denials.  There were some comments about ML being
      used only against bad guys, so what's the problem (slippery slope there).
      Tony Harminc remarked that collection need not be real-time if a Trojan
      horse is collecting the info for later dissemination.  Dave Farber
      wondered about the possibility of disguising a really nasty virus so that
      it would slip through the mechanism that intentionally failed to detect
      ML.  Several folks resurrected the old argument that the ability to insert
      malware actually weakens security.  PGN]
    Date: Thu, 29 Nov 2001 14:24:35 +1300
    From: "Dr Richard A. O'Keefe" <okat_private>
    Subject: Records stolen in Auckland
      Thousands of people's financial details have been stolen in a myster
      burglary in Auckland.  Burglars broke through 24-hour security at New
      Zealand Funds Management's offices in the ANZ Centre the weekend before
      last.  They stole computer tapes with clients' names, addresses, bank
      account numbers, how much they had invested, as well as financial
      advisers' computer passwords.
      NZ Funds Management has about 25 000 clients throughout New Zealand, with
      about NZD 1.6 billion (about UDS 670 million) invested.  The high-rise
      centre has swipe-card access, video security cameras, and security guards
      24 hours a day, but the burglars got in at 4am the Saturday before last.
      They got away with computer taps holding the client information.  Only one
      office was broken into and only the computer tapes stolen.  Left behind
      were laptop computers and other equipment. ---NZPA  
      [Source: *Otago Daily Times*, 26 Nov 2001, p. 28]
    Strong cryptography wouldn't have helped.  Completely avoiding the use of
    virus-friendly software wouldn't have helped.  As for physical security,
    they had it.  And the information was stolen anyway.  Without knowing
    anything about the people involved, or having any expertise beyond that
    common to all readers of detective stories, I must say that it looks
    uncommonly like an insider job.
    The distributed techniques that have been worked out in response to the
    Napster case, could they help to protect against loss of records like this?
    But wouldn't having businesses distributed their data over thousands of
    other business's machines create RISKS of its own?
    Date: Fri, 30 Nov 2001 09:05:04 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Calif info: Ask and you shall be removed ... but you've got to ask
    Responding to complaints by consumers and privacy advocates who protested
    California's legal sale to the Web genealogy company RootsWeb.com of public
    information containing such personal data as people's birth dates and their
    mothers' maiden names, the company now says it will remove from its Web site
    the names of anyone who makes a specific request.  A spokesman for the
    company said: "The mission of our company is to create places to help people
    reconnect with their families. We're not in any way doing anything except
    helping our customers and if a customer is concerned about it, it doesn't do
    any good to leave them up on the site."  A legal council for the Electronic
    Privacy Information Center says that California's sale of data to the
    genealogy Web site "a situation where all the residents of California have
    now been exposed to a new risk of identity theft." [*San Jose Mercury News
    30 Nov 2001*; NewsScan Daily, 30 Nov 2001]
      [The birth records of more than 24 million Californians are involved.  PGN]
    Date: Wed, 28 Nov 2001 16:45:55 -0500
    From: grr/sll <grrhodesat_private>
    Subject: "Light turnout" for election
    During the recent election (November) here, a power outage occurred during
    voting hours. It lasted several hours and affected an estimated 10,000
    people in portions of northern Allegheny and adjacent counties (north of
    Pittsburgh, Pennsylvania, USA). Initial news reports noted concerns that the
    voting machines would not work without electricity. From what I've gathered,
    most of the machines were lever-style machines, and had a provision for
    manual power (i.e., a crank) to tally the votes and reset the levers after
    each voter.
    But what would have happened if they had used computer or other electronic
    voting, or another machine that required electricity to work? It seems
    dubious that backup power systems (15+ hour capacity) would be provided for
    all the polling places. How would the election process be affected, and when
    would the "powerless" voters vote? Would the election results be held up for
    this? -- it seems that they would have to be. [Of course, no one can predict
    how this might affect, or not, any election in Florida.  ;-)]
    Coincidentally, it was a relatively "minor" election, with few major offices
    or issues at stake, so fewer voters than normal showed up to vote. Around
    here, that's called a "light turnout" of voters. But, as they read their
    copy describing the local voting predictions and the "light turnout," not
    one of the newscasters gave any sign that they understood the pun.
      [And yet it is not difficult to have a shocking experience even when there 
      is no electricity!  PGN]
    Date: Fri, 30 Nov 2001 10:06:24 -0500
    From: "Jacob Harris" <jacob.harrisat_private>
    Subject: The destruction of 7 WTC
    While we know all too well about the horrific destruction of the two main
    towers at the World Trade Center (1 and 2 WTC), not as many people are aware
    of the destruction of nearby 7 WTC nearby approximately 8 hours after the
    initial impact. While the building sustained structural damage from falling
    debris and the collapse of the main towers, it was also consumed by a raging
    fire that seems to have caused similar catastrophic structural failure. This
    article in *The New York Times*
      <http://www.nytimes.com/2001/11/29/nyregion/29TOWE.html> (reg required)
    indicates that a likely cause of that fire was the approximately 42,000
    gallons of diesel fuel (6K gallons on the seventh floor, 36K in the
    basement) stored in the building to power backup generators for the City's
    emergency command center located there. This fuel was apparently ignited
    (the fireproof tanks may have been ruptured by debris) and burned intensely
    in the building's core to cause the collapse. Of course, the aforementioned
    emergency center was unusable in this emergency, and the city was left
    scrambling to setup another facility for emergency coordination (City Hall
    was too close to the accident site). Finally, according to an earlier NY
    Times article, this building also housed a regional CIA office whose
    destruction has hindered some intelligence and investigation efforts.
    As has been noted previously, the 9/11 disaster has illustrated all sorts of
    risks that are gruesome to contemplate. In hindsight, locating the emergency
    coordination center at the location of a potential emergency was
    unfortunate, and the lack of a backup emergency coordination center
    compounded the problem. And it is ironic how preparedness for one common
    emergency (power outages) can create a vulnerability in itself. I'm sure
    there are a lot more sites looking more nervously at their backup fuel
    supplies these days.
    Date: Wed, 28 Nov 2001 12:48:47 -0500 (EST)
    From: "Ed Ravin" <eravinat_private>
    Subject: Connecticut Attorney General website wants Microsoft browsers?
    A friend just sent me a pointer to the announcement that the Connecticut
    Attorney General is opposing the Microsoft settlement.  The URL for the
    announcment is:
    When I surf over there with my Opera 5.0 or Netscape 4.77 browser running on
    Linux, I get this error page:
      This site requires JavaScript to be enabled.
      The Web browser that you are using does not have JavaScript
      enabled, or is not a JavaScript-capable browser.  [...]
    The link to "upgrade your browser", naturally, suggests that I use Microsoft
    Internet Explorer or Netscape.
    (1) I shouldn't have to enable JavaScript just to read your press releases,
    but more importantly, (2) both browsers that I tried, Netscape 4.77 and
    Opera 5.0, running under Linux, have JavaScript enabled already.  Something
    is clearly broken here.
    It is ironic that the Attorney General's attempts to fight Microsoft's
    market dominance are undermined by a Web site that insists that its users
    switch to Web browser software provided by the market leaders.  Talk about
    anti-competitive forces!
    Ed Ravin  <eravinat_private>
    Date: Wed, 28 Nov 2001 22:22:08 -0500
    From: Monty Solomon <montyat_private>
    Subject: How to crash a phone by SMS
    How to crash a phone by SMS
    By John Leyden
    Posted: 28/11/2001 at 18:20 GMT
    So now you can send an SMS and crash a mobile phone, so that the user is
    locked out.  Job de Haas, a security researcher at ITSX, has adapted a
    program called sms_client, which sends an SMS message from an
    Internet-connected PC, in which the User Data Header is broken.
    During a presentation during the Black Hat conference last week, he
    demonstrated how a malformed message crashes a Nokia 6210 phone on its
    receipt. Once the message is received it is impossible to turn on an
    infected phone again.  ...
    Date: Wed, 28 Nov 2001 22:21:33 -0500
    From: Monty Solomon <montyat_private>
    Subject: The Web Never Forgets
    The Web Never Forgets, David Colker, Los Angeles Times, 27 Nov 2001
    Government agencies have tried to remove sensitive information, only to
    discover that copies have proliferated and they're virtually impossible to
    eradicate.  Within days of the 11 Sep attacks, the federal Agency for Toxic
    Substances and Disease Registry rushed to pull a suddenly sensitive report
    from its Web site titled "Industrial Chemicals and Terrorism."  The agency
    eliminated all traces of the document and its description of sources for
    home-brew nerve gases and improvised explosives.  But on the World Wide Web,
    almost nothing truly dies.  [...]
    Date: Fri, 30 Nov 2001 13:29:06 -0500
    From: David Friedman <dkf5kat_private>
    Subject: Risks of computer security education 
    When Gary McGraw gave a talk to our Cryptology/Computer Security class at
    University of Virginia, one of the things he mentioned is that the "bad guys
    are a lot better at sharing than the good guys."
    On Monday we had project presentations, and a group of students told the
    class how to exploit a serious security vulnerability present on any of the
    Lab PCs on grounds. The students had not told the system administrators of
    the machines about the vulnerability.
    The RISK of educating people about computer security is nobody knows how the
    people getting educated are going to use their knowledge.
    In this case I don't think my fellow students were acting maliciously. They
    simply didn't expect anybody to use the knowledge to do damage. It was a
    case of the "good guys" not sharing.
    David Friedman
    Date: Fri, 23 Nov 2001 23:21:14 -0500
    From: "Walter Dnes" <waltdnesat_private>
    Subject: Re: Let's get really paranoid about e-mail and spam (Hurst, R 21 78)
    The general risk here is the use of software in conditions it was never
    designed to be run under.  SMTP (*SIMPLE* Mail Transfer Protocol) is called
    that for a reason.  It was designed to be run in a trusted environment --
    i.e., for communications between researchers, professors, and military
    people who had sufficient security clearance to be allowed onto the ARPANET
    in the first place.  It was never designed to thwart misdirection and
    forgeries by sleazy scammers, i.e. no built-in authentication.  Servers were
    few and far between, run by a small community of administrators who probably
    knew each other on a first-name basis.
    There is a spammer sub-culture (I use the term "culture" rather loosely) and
    also an anti-spammer culture, which are visible on various spam-fighting
    forums/mailing-lists.  What you see here is probably the result of a
    "dictionary attack".  The following description is a simplification, and is
    not 100% technically exact.  A service paid for or run by spammers will set
    up a script to probe an ISP's smtp server.
     - if the smtp server supports the EXPN and/or VRFY commands an effective
       procedure is to establish an smtp connection to "smtp.example.com".  Then
       run those commands inputting addresses like aaaaaaaaat_private,
       aaaaaaabat_private, aaaaaaacat_private, etc, etc.  A smarter script
       will use a dictionary of common names to increase the percentage of hits.
       The server will obligingly tell the connecting end which addresses are
       for real, and which are invalid.
     - if the smtp server has EXPN/VRFY disabled, another approach is to
       run a bogus mass-mailing.  Each e-mail transaction starts the
       process and gets as far as supplying the "To:" address.  If the
       receiving smtp server rejects an address, it's obviously invalid.
       If the smtp server responds OK, then the address is valid.  The
       script will abort and tear down the e-mail transmission in that
       case, and get on with testing the next e-mail address.
    With today's fast computers and broadband, the above is feasible.
    Spammers forge return addresses.  This prevents the originating machine from
    getting e-mail-bombed if several percent of a multi-million spam run are
    invalid addresses, or the targets' ISPs have spam-blocking of some sort.  At
    first spammers put in gobbledygook into the return address.  Then ISP's
    started refusing e-mail from domains that didn't exist (this is a quick
    lookup against DNS).  So spammers resorted to forging random email addresses
    at valid domains.  Occasionally, the forgery will be identical to a valid
    e-mail address, and innocent people get the bounces.
    >  how on earth did the spammers "harvest" my specific MyRealBox account name 
    They probably used some "common.nameat_private" forgery, as
    mentioned above.
    >  (And are there any steps one can take to prevent it from happening again?)
    Not very much.  You could try a long gobbledygook-type e-mail address that
    is less vulnerable (nothing is invulnerable) to a dictionary attack that is
    biased to common names.  The disadvantage is that your friends and business
    associates will have problems remembering your kjgrhjkfdhat_private e-mail
    >  This also brings to mind the risk of using a "free" Internet e-mail 
    Actually, the risk is in signing up with any ISP/e-mail-service with
    millions of valid e-mail addresses where a dictionary attack will return a
    lot of hits.  You're less likely to run into this on a smaller ISP.
    Walter Dnes <waltdnesat_private>
      [SMTP EXPN also noted by Doug Sojourner, in very similar discussion.  PGN]
    Date: Tue, 27 Nov 2001 02:21:55 -0500
    From: Jason Bennett <jasonabat_private>
    Subject: Re: Let's get really paranoid about e-mail and spam (Hurst, R 21 78)
    Allan's story about all his mailboxes getting hit with spam doesn't really
    surprise me.  I strongly suspect that he was the victim of a dictionary
    attack (mentioned several times before in RISKS).
    When I started a new job last year, my e-mail account was set up a couple of
    weeks before I started (I had to move several hundred miles for this
    job). When I did start, I found my mailbox containing several hundred spams!
    I had, unfortunately in this case, been assigned the e-mail address of
    jason@domain. It was pretty much a given that most domains would contain an
    address of "jason," and so I got caught in those spam dragnets. Whenever I
    would go on vacation, I would come back to several hundred junk messages.
    Lesson? An easier e-mail address is easier for everyone.
    Jason Bennett, jasonabat_private
      [We had a lot of e-mail on this topic.  PGN]
    Date: 28 Nov 2001 08:50:33 -0800
    From: david-moonat_private (David A. Moon)
    Subject: Re: Risks of the space in Unix filenames (Spinellis, R 21 79)
    Some of Mr. Spinellis' suggested fixes won't help when a quote character
    appears in a filename.
    This "requoting problem" has been known since before Unix even existed, at
    least within the Multics community.  I remember encountering it myself in
    1971 or 1972 in the exec_com facility of Multics.
    The root cause and the real source of the risk here is the attempt to use an
    interactive command language as a programming language.  It's evidently a
    very seductive temptation, since the mistake has been repeated many times by
    many people, but in the end that approach just can't work.  A programming
    language needs a syntax and semantics that don't confuse the data being
    processed with the program doing the processing.
    Date: Thu, 29 Nov 2001 14:15:21 +1300
    From: "Dr Richard A. O'Keefe" <okat_private>
    Subject: Re: Risks of the space character in Unix filenames
    I can't be the only RISKS reader with an MPW documentation set, can I?
    Apple has had a UNIX-like shell for many
    years.  Let me quote page 3-18 of "Introduction to MPW" (that's
    *M*acintosh Programmer's Workshop):
      In general, when a parameter contains a space, you must enclose it in
    quotation marks
      so that the MPW Shell recognizes it as a single parameter.
    and page 3-19:
      Place quotation marks around parameters that contain spaces.
    While UNIX may (perhaps!) have been new to Apple programmers, the need for
    quoting parameters that contain spaces certainly wasn't.
    Date: Mon, 26 Nov 2001 07:59:28 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Hackers Beware", Eric Cole
    BKHKRBWR.RVW   20010829
    "Hackers Beware", Eric Cole, 2001, 0-7357-1009-0,
    %A   Eric Cole www.securityhaven.com ericat_private
    %C   201 W. 103rd Street, Indianapolis, IN   46290
    %D   2002
    %G   0-7357-1009-0
    %I   Macmillan Computer Publishing (MCP)
    %O   U$45.00/C$67.95/UK#34.99 800-858-7674 317-581-3743 infoat_private
    %P   778 p.
    %T   "Hackers Beware: Defending Your Network from the Wiley Hacker"
    It is difficult to maintain confidence in a book that, within six sentences
    of the opening of the first chapter, misspells the word "brakes."  We are
    told that two developmental editors, two copy editors, two proofreaders, and
    no less than five technical reviewers had at this work.  Did any of them pay
    attention to what they were reading?
    Chapter one basically states that dangers are out there, security is bad,
    and companies should be concentrating on prevention, detection, and
    education.  Cole also nudges at the "hacking for protection" theory, without
    ever really examining it.  A brief but reasonable list of security breaking
    activities is given in chapter two.  Various steps and tools involved in
    gathering information about a network connected to the Internet are
    described in chapter three.  Unfortunately, this explanation, while helpful
    to a potential attacker, has no utility for the defender: almost all of the
    data discussed must be publicly available for the network to function, and
    so there are no means of blocking this level of access.  Spoofing, or
    masquerading, is dealt with in chapter four, but again, while some
    protective measures are provided, much more time is spent on the disease
    than the cure.  After twenty six pages of telling you how to hijack
    sessions, including the best programs to use and how to operate them,
    chapter five gives us two pages of simplistic advice (avoid remote
    connections) on protection.  Chapter six lists a number of common denial of
    service attacks and, while it does devote a lot of ink to describing the
    exploits, the material is reasonably balanced, and the suggested defensive
    measures realistic.  Chapter seven requires almost forty pages to tell us
    that buffer overflows are not good, and you should apply software patches.
    Password security is very important, but the material in chapter eight is
    vague, disorganized, and has relatively little to say about good password
    choice.  (Chapters nine and ten describe some NT and UNIX password cracking
    programs.)  The examination of background fundamentals of NT, in chapter
    eleven, is a terse and unfocused grab bag of information.  The analysis It
    would be of little help in explaining the specific attack programs listed in
    chapter twelve, a number of which rely on particular applications.  The same
    relation is true of chapters thirteen and fourteen, relating to UNIX.  A
    number of backdoor and remote access trojan programs are described in
    chapter fifteen.  Chapter sixteen discusses log files, and lists some
    programs for generating spurious network traffic in order to hide attacks.
    Some random exploits are listed in chapter seventeen, and a few more in
    eighteen.  An attempt is made to combine various attacks into scenarios, in
    chapter nineteen, but these do not add anything to the material already
    provided.  Chapter twenty is the usual vague look to the future.
    This book takes the all-too-common approach of assuming that teaching you
    how to break into systems will help you to protect them.  The work also
    amply demonstrates the fallacy of that argument.  While the harried systems
    administrator spends several hours coming to grips with the minutiae of the
    attacks described, the vast majority of the exploits listed can be countered
    simply by ensuring that software patches are up to date.  In addition, while
    dozens of loopholes are listed in these pages, thousands more exist that are
    not covered.  The material contained in these pages may be entertaining, but
    it is of far more use to the attacker than to the defender.  This would be
    upsetting, were it not for the fact that most of the exploits described are
    old and not likely to remain unpatched if administrators are keeping up to
    date.  (Of course, many small outfits can't commit a lot of resources to
    keeping up to date ...)
    For security specialists, this volume provides nothing that can't be found
    elsewhere.  For non-specialists, it fails to supply a security framework and
    strategy within which to work.
    copyright Robert M. Slade, 2001   BKHKRBWR.RVW   20010829
    As usual, a draft has been sent to the author.  He has requested that
    this response be included, unedited:
    First allow me to say thank you for taking the time to review the book
    as criticisms are as crucial as praise. We take your feedback
    seriously. That being said, let me see if I might speak to some of
    your discussions on "Hackers Beware".
    When you buy "Hackers Beware", you buy it for the technical content.  While
    we maintain that this faction of the book is air-tight and well- supported,
    we also admit that we could and should have done a better job with edits on
    spelling and grammar. While we admit that shortcoming, we also ask that you
    look at the eleven reviews posted on Amazon, praising the technical content
    of my book and earning it FIVE- STAR rating.
    The book starts opens with some introductory material but does that for a
    reason. Much of the security information that companies need to protect
    their site is straightforward. Yet companies systems are still hacked into
    with a growing frequency because they fail to understand how to build a
    proper defense. So my book aims to ensure that everyone is well, if not
    over-educated on DEFENSE.
    There are many books on hacking but what makes this book different is its
    emphasis on defense. Yes, you need to understand how the enemy breaks into
    systems, so you can build better defenses. Every section has an area on how
    to defend against a certain type of attack. So I am not sure how a review
    can say that defense is not covered when that is the thrust of this
    book. There are plenty of books that show you how to break in. This book
    clearly and explicitly explains the properties of a strong defense.
    Thanks for letting me write a response.  Eric
    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.80

    This archive was generated by hypermail 2b30 : Sat Dec 01 2001 - 13:28:49 PST