[risks] Risks Digest 21.87

From: RISKS List Owner (riskoat_private)
Date: Sat Jan 19 2002 - 10:10:51 PST

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

    RISKS-LIST: Risks-Forum Digest  Saturday 19 January 2002  Volume 21 : Issue 87
       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.87.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Exploding chips: Would you like to be fried with that? (Rob Slade)
    Hospital tells elderly men they're pregnant (Arthur Goldstein)
    Automated Debit: "There's nothing we can do to stop it." (Carl Fink)
    Even unscientific elections get rigged (Jeremy Epstein)
    The risks of standards and validators (Lindsay Marshall)
    Buffer overflows and other stupidities (Earl Boebert)
    Windows update server glitch (Mike Hogsett)
    An outrageous violation of privacy (Fred Cohen)
    Risks of Internet Reconfigurable Logic (John Gilliver)
    Linked DMV databases and biometrics on driver's licenses (Ben Rosengart)
    Facial recognition technology doesn't work (Nick Brown)
    Honolulu speed camera risk: mainly human error (Dan Birchall)
    AOL Buddy-Hole fix has backdoor (Robert Andrews)
    Reinventing snake oil: compression (Jeremy Epstein)
    Re: Airplane takes off without pilot (Paul Nelson)
    Re: Software glitch grounds new Nikon camera (Nickee Sanders)
    Re: Kaiser Permanente exposes medical record numbers (Geoff Kuenning)
    Re: ING bank debits wrong sum from accounts (Paul van Keep)
    REVIEW: "Counter Hack", Ed Skoulis (Rob Slade)
    Abridged info on RISKS (comp.risks)
    Date: Thu, 17 Jan 2002 08:58:01 -0800
    From: Rob Slade <rsladeat_private>
    Subject: Exploding chips: Would you like to be fried with that?
     From NewsScan Daily, 17 January 2002:
    > Researchers at the University of California in San Diego have developed a 
    > way to blow up silicon chips using an electric signal --
    Now, at this point I was willing to dismiss this as the stuff of fiction.
    You all know how computers in books and movies always "blow up real good"
    when the bad guy plants a virus or something in them.  However:
    > an innovation that could be used to fry electronic circuitry in devices
    > after they're stolen or fall into the wrong hands. The American spy plane
    > that was impounded in China last year is an example where such technology
    > would have proven handy in destroying its secret electronics systems.
    OK, this make a bit more sense.  Obviously these are chips that are
    specifically designed to blow up once they receive a certain signal.
    At this point, though, you start to think about what kind of signal that
    could be.  And, could it be counterfeited?
    > Similarly, if a cell phone were stolen, the owner could alert the wireless
    > carrier, which would send a signal to trigger a small explosion in the
    > phone's chip, rendering it useless. The techniques uses a small amount of
    > the oxidizing chemical gadolinium nitrate applied to a porous silicon
    > wafer. (New Scientist 16 Jan 2002)
    >   http://www.newscientist.com/news/news.jsp?id=ns99991795
    OK, I am definitely certain that, if I need to get a new cell phone from now
    on, I am *definitely* not going to carry it in my pants pocket.  The RISKS,
    as have been frequently noted here, are obvious.
    (If we could get them to use those chips in pacemakers, wouldn't that just
    make a killer application, Peter?)
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
      [I normally delete all trailer quote.  But this one from another message
      from Rob is rather fascinating:
        A modern US Navy cruiser now requires 26 tons of manuals.
        This is enough to affect the vessel's performance.
          -- `New Scientist' article on the paperless office
    Date: Fri, 11 Jan 2002 04:19:19 +0000
    From: arthur.goldsteinat_private
    Subject: Hospital tells elderly men they're pregnant
    The Chesterfield and North Derbyshire Royal Hospital admitted on 10 Jan that
    it had mistakenly sent computer generated letters to 30 patients, including
    six elderly men, telling them they were pregnant.  The system operator was
    blamed for choosing the wrong option (instead of informing them that their
    operations had been postponed).  [Reuters, 10 Jan 2002, PGN-ed]
      |oddlyenough|01-10-2002::11:30|reuters.html  [SPLIT URL]
    Date: Wed, 16 Jan 2002 14:02:08 -0500
    From: Carl Fink <carlat_private>
    Subject: Automated Debit: "There's nothing we can do to stop it."
    A Georgetown, TX man who had arranged for his water bill to be automatically
    debited from his bank account alertly noticed that his monthly bill was for
    over $21,000.  (If he hadn't noticed, the debit would have happened, causing
    him to bounce multiple checks before the error was corrected.)  When he told
    the city of the problem, "They said there was absolutely nothing they could
    do to stop the automated debit, and it was out of their hands."  Their
    solution was to send a city employee with a check for $21,000 to reimburse
    their customer!
    Risks?  Lack of sanity checking on a new billing system springs to
    mind.  Lack of any way to correct errors is also quite prominent.
    Carl Fink, Manager, Dueling Modems Computer Forum  http://dm.net/ carlfat_private
    Date: Wed, 9 Jan 2002 16:28:26 -0500
    From: "Jeremy Epstein" <jepsteinat_private>
    Subject: Even unscientific elections get rigged
    ZDNet is doing a poll on whether J2EE or .NET is more important for Web
    services.  Although it's a totally unscientific poll, they've set things up
    to try to detect (and stop) ballot stuffing.  It seems that Microsoft hasn't
    understood the concept, and employees are trying to vote repeatedly,
    including automated voting.
    The risk of believing unscientific polls is nothing new, but the combination
    of electronic polls that can be stuffed with the herd mentality that may
    influence buying greatly increases the risks.
      [*The Register* noted that 21.5% of the respondents said they would
      use .Net, 46% Java -- until a surge of votes came in from microsoft.com,
      some of which were apparently stimulated by internal MS e-mail saying
    Date: Fri, 11 Jan 2002 13:16:36 -0000
    From: "Lindsay Marshall" <Lindsay.Marshallat_private>
    Subject: The risks of standards and validators
    This week I ran a page of the RISKS Web site through the W3 html validator,
    as I do on a regular basis -- it keeps me clean and legal.  It complained
    that I didn't have a charset specification, so I added one as it suggested.
    This appears to cause some netscape 4.7 browsers some problems -- I had
    complaints that the text was vanishingly small, and also that it was vastly
    increased in size.  Presumably a typeface selection that is hard-wired
    somewhere, and that nobody is told about.  Anyway, I've taken out the
    charset setting for the moment.
      [Lindsay runs our UK redistribution and the excellent RISKS Web site --
      for both of which I am most grateful.  I'm delighted to take the
      opportunity to thank him once again!  PGN]
    Date: Mon, 14 Jan 2002 10:07:55 -0700
    From: Earl Boebert <boebertat_private>
    Subject: Buffer overflows and other stupidities
      "I used to be disgusted, now I try to be amused."  -- Elvis Costello
      "What a stupid robot." -- Marvin the Paranoid Android
    In my view, attempts to close the buffer overflow vulnerability through
    software or compiler tricks are doomed to one degree of failure or another
    because you're trying to program around a stupid processor design.  Certain
    contemporary processors actually host a Pantheon of stupidities, consisting
    of a Greater Stupidity and two handmaiden Lesser Stupidities.
    Greater Stupidity: Read access implying execute access. Any piece of data
    that the processor can be tricked into loading into the command register
    immediately becomes code. This is a stupidity of such breadth and depth that
    it comes with an event horizon.
    Lesser Stupidity I: Segmented addressing that isn't. Let's say you have an
    addressing scheme consisting of segment number plus offset. This raises the
    question of what to do when, in executing code, block moves, etc., the
    offset gets counted up to maximum length plus one. Smart answer: take a
    fault. Dumb answer: set offset to zero and count up one in segment number.
    Lesser Stupidity II: Brain-dead stack design. If you enumerate the design
    space of dynamic storage management, you may realize that one actually has
    to *work* to produce a stack design so dumb that overflow attacks are
    possible. Here are four classes of designs that are immune to the
    1. Descriptor stacks.  The only thing that goes in the stack are addresses,
    preferably with a bounds value attached. Overflow a buffer and at worst you
    clobber the heap. Penalty: one level of indirection, which (The Horror! The
    Horror!) may cause your dancing pigs to dance slower than the other
    guy's. Possibility: can be fitted transparently to existing processor
    designs, assuming anybody cared.
    2. Stack per protection domain. This assumes you can find the perimeters of
    your protection domains. Also slows down dancing pig displays because of
    copying parameters from stack to stack.
    3. Separate control and data stacks. CALL/RETURN works the control stack,
    PUSH/POP works the data stack. Doh.
    4. Error-checking stacks. A whole raft of options, including "shadow stacks"
    with checksums, return addresses protected with trap bits, etc. etc.
    So, if it's all so straightforward and well known, why hasn't some vendor or
    other fixed it?  Answer: the dancing pigs have won.
      [Ah, yes.  Earl is tacitly recalling the good old days of Multics
      (beginning in 1965) and its progenies (SRI's object-oriented Provably
      Secure Operating System design 1973--1980, and the Honeywell/Secure
      Computing Corporation type-enforced systems), all of which took care of
      this problem and so many others so long ago.  But with today's badly
      designed bloatware, the dancing pigs are increasingly becoming 700-pound
      porkers that can barely move around the pigsty without massive memory
      and processing power, and whose pigpen could not even contain them if
      they were in reality Trojan pigs.  PGN]
    Date: Tue, 15 Jan 2002 14:48:14 -0800
    From: Mike Hogsett <hogsettat_private>
    Subject: Windows update server glitch
    A glitch in Microsoft's server software has left some users unable to
    download important security patches and other fixes for Windows software
    since last Thursday.
      microsoft.security.server.ap/index.html   [SPLIT]
    Date: Sun, 13 Jan 2002 10:27:20 -0800 (PST)
    From: Fred Cohen <fcat_private>
    Subject: An outrageous violation of privacy
    I just saw a piece on MSNBC where they prominently featured the face of a
    man who helped someone out of the WTC on 11 Sep 2001 -- and just because
    they don't know who the man is, they have created a composite picture of him
    and posted him as if he were a wanted man on the national news.
    Now I understand their desire to make human interest stories go, but I think
    it is outrageous to take the image of a person and smear it all over
    national TV, creating a manhunt for someone, when all the person did was to
    help someone else out in a public place.
    If I were this man, I would sue them for as much as I could get and do all I
    could to try to recover what semblance of privacy I might barely still have
    left after being exposed on national TV without my permission.
    Is this all we have left of our privacy?
    Fred Cohen http://all.net/ Fred Cohen & Associates tel/fax:925-454-0171
    Sandia National Laboratories 1-925-294-2087  University of New Haven 
    Date: Tue, 08 Jan 2002 16:40:35 +0000
    From: john.gilliverat_private
    Subject: Risks of Internet Reconfigurable Logic
      ... "For example, IRL (Internet Reconfigurable Logic) means that a new
      design can be sent to an FPGA in any system based on its IP address."
      (From Robert Green, Strategic Solutions Marketing with Xilinx Ltd., in
      "Electronic Product Design" December 2001.  Xilinx is a big manufacturer
      of FPGAs.)
    For those unfamiliar with the term, FPGA stands for field-programmable logic
    array: many modern designs are built using these devices, which replace tens
    or hundreds of thousands of gates of hard-wired logic.
    The RISKs involved are left as an exercise to the readers ...
    J. P. Gilliver, BAE SYSTEMS Advanced Technology Centre, 
    West Hanningfield Road, GREAT BADDOW, Essex, CM2 8HN, UK  +44 1245 242133
    Date: Wed, 9 Jan 2002 17:38:14 -0500
    From: Ben Rosengart <ben+risksat_private>
    Subject: Linked DMV databases and biometrics on driver's licenses
    *Time Magazine* is reporting that the federal Department of Transportation,
    by instruction of the Congress, is working to link together the states'
    driver databases, and also to introduce biometric security on drivers'
    RISKS include false arrest due to database screwups, abuse for personal
    reasons by government personnel, abuse by the government itself, all the
    RISKS known to be associated with biometrics, disclosure of the databases to
    the public, and probably much, much more.
    Date: Wed, 9 Jan 2002 11:38:39 +0100 
    From: Nick Brown <Nick.BROWNat_private>
    Subject: Facial recognition technology doesn't work
    An article by the ACLU at
      http://www.aclu.org/issues/privacy/drawing_blank.pdf reveals that a
    highly-publicised facial recognition system has been quietly dropped by law
    enforcement officials in Tampa, Florida, following a large number of false
    positives (including males identified as females, and vice versa) and a
    total of zero matches against known criminals, leading to zero arrests.
    Aside from the already-discussed civil liberties RISKs of such systems, it
    seems we need to add the possibility that the taxpayers may not be getting
    value for money, with or without their knowledge (the withdrawal of this
    kind of thing tends to be done with rather less media coverage than its
    introduction).  One wonders if this will have any effect on plans to
    introduce such systems into airports to "detect" terrorists.
    Nick Brown, Strasbourg, France
    Date: Wed, 9 Jan 2002 22:52:58 -1000
    From: Dan Birchall <djbat_private>
    Subject: Honolulu speed camera risk: mainly human error
    After much debate, and general wailing and gnashing of teeth from those who
    like to drive fast, the powers that be here in Honolulu have a private
    contractor operating cameras to photograph vehicles which speed or run red
    lights.  After the license number, time, and location of the violation are
    verified, a citation is mailed.
    In their first day of operation, the cameras caught 927 speeders.
    However, more than 80% were unenforceable due to human errors in operation
    of the cameras - poor aim, inaccurate location recording, etc.
    On the bright side, people do seem to be speeding less since the cameras
    started working.
    Date: Wed, 9 Jan 2002 12:19:10 -0400
    From: "Robert Andrews @ PrivacyExposed.com" <Robertat_private>
    Subject: AOL Buddy-Hole fix has backdoor
    "A member of w00w00, the security enthusiasts who first reported the AOL
    Instant Messenger (AIM) games request vulnerability, has alerted users that
    a fix the group recommends has its own backdoor.  Apparently, the AIM Filter
    by Robbie Saunders which w00w00 had recommended is infected, group member
    Jordan Ritter disclosed on the Bugtraq mailing list late Tuesday. "At the
    time, Robbie Saunders' AIM Filter seemed like a nice temporary solution.
    Unfortunately, it instead produces cash-paid click-throughs over time
    intervals and contains backdoor code combined with basic obfuscation to
    divulge system information and launch several Web browsers to porn sites,"
    Ritter wrote."  [...]  Thomas C Greene, *The Register*
    Date: Wed, 9 Jan 2002 16:13:31 -0500
    From: "Jeremy Epstein" <jepsteinat_private>
    Subject: Reinventing snake oil: compression
    Snake oil is on the rise.  Latest to join the fray is Zeosync
    (www.zeosync.com), which announced on 7 Jan 2002 that they have new
    algorithms that can provide 100:1 lossless data compression over
    "practically random" data.  (What they mean by "practically" isn't defined.)
    Lots of criticism and proofs that it's impossible in Slashdot
    and elsewhere.  So far the algorithms haven't been given, except to provide
    the single longest stream of buzzwords I've seen in a long time.  The one
    part that says it might not be 100% snake oil is that they have a Fields'
    Prize winner as one of the participants.
    The risk here is that they've added enough buzzwords to the announcement
    that some people might actually believe it.  The media doesn't seem very
    skeptical, which they should be.  Reuters quoted David Hill, an analyst with
    Aberdeen Group as saying "Either this research is the next 'Cold Fusion'
    scam that dies away or it's the foundation for a Nobel Prize. I don't have
    an answer to which one it is yet."  Others have been much more willing to
    figure out which way it's going.  Remember the 1999 story about the
    16-year-old Irish girl whose new form of cryptography would revolutionize
    the world?
    Date: Mon, 7 Jan 2002 15:20:53 -0600
    From: pnelson@sauer-danfoss.com
    Subject: Re: Airplane takes off without pilot (Klein, RISKS-21.84)
    There are many aircraft which have no starters (or electrical system, for
    that matter)- commonly antique or classic small, one- or two- place planes
    like the 1947 Aeronca Champ that was the subject of this item. There are
    well-known safety precautions which go along with starting them- one of the
    oldest is that there should be someone in the cockpit with feet on the
    brakes, operating the magneto switches and throttle while a second person
    "props" the plane to start it. (The classic shouts "CLEAR!", "CONTACT!",
    If a plane like this is to be started by one person, the accepted
    precaution is to tie the tailwheel to a stationary object, turn the fuel
    OFF so that only the small amount in the carburetor bowl is available, and
    then make CERTAIN that the throttle is only cracked open a small amount.
    I've started my 1946 Cessna 140 in this manner many times when the battery
    happened to be run down.
    All that being said, incidents like this still happen when people try to
    take shortcuts. It shouldn't have happened!
    Paul Nelson, Senior Engineer, Sauer-Danfoss Company, Ames, IA  515-239-6614
    Date: Wed, 9 Jan 2002 12:10:32 +1300
    From: Nickee Sanders <njsat_private>
    Subject: Re: Software glitch grounds new Nikon camera (Gillett, RISKS-21.85)
    Our first digicam was also a Kodak.  When the battery voltage was low enough
    (and it happened suddenly), the camera would simply stop responding to *any*
    user actions whatsoever.  It didn't even do a power down.  The only way to
    clear this condition was to take the batteries out for a number of hours;
    after this, on insertion of fresh batteries, the camera would power down and
    then could be powered up again.
    The first time this happened it was pretty scary.  One minute we were
    snapping away; the next minute the camera was frozen, with the lens fully
    extended (and thus the lens cap wouldn't stay on it).  The local service
    reps knew nothing of this error condition and could only offer to send it to
    Australia (from New Zealand) for servicing, which would take several weeks.
    We figured out by trial and error how to solve it ourselves.
    Nickee Sanders, Auckland, New Zealand
    Date: Mon, 14 Jan 2002 13:09:28 -0800
    From: Geoff Kuenning <geoffat_private>
    Subject: Re: Kaiser Permanente exposes medical record numbers (Debert, R-21.86)
    J. Debert writes about an insecure Web page at http://www.kponline.org.
    It happens that my best friend works for Kaiser Permanente's IT department,
    so I forwarded the message to her.  As a result of discussions and
    exploration, I think that the alleged risk does not in fact exist.
    The claim was that medical-record numbers were being exposed during the
    signon process.  However, in viewing the source of the referenced Web page,
    it appears that the "sign on" button makes an https (SSL) connection.  Thus,
    although the "padlock" icon in the browser is unlocked, anything sent from
    that page is in fact sent using SSL.
    I have recommended that Kaiser change their main page so that it forwards
    the browser to an SSL equivalent, solely so that the padlock icon will
    appear locked.
    I think that the true RISK is not in Kaiser's Web page, but rather in the
    browser.  The "padlock" icon reflects not whether the page SENDS information
    securely, but rather the fact that the page was FETCHED securely.  This
    disconnect between what is shown and what is expected has been raised
    recently by Jeff Mogul in the converse direction: a page that had the
    padlock proceeded to send information insecurely.
    The first problem (apparently insecure page is actually secure) can be
    patched around with the forwarding kludge I mentioned above.  The second can
    be handled by the user to some extent (certain browser settings can warn you
    when you transition from a secure page to an insecure one).  However, the
    true problem is in browser design.  The "padlock" icon should be associated
    with a LINK, not a page.  Regardless of how it was fetched, if a page
    contains both secure and insecure links, the lock should be shown as
    unlocked and should lock only when you mouse over a secure link.  Only if
    all outgoing links from a page are secure should the padlock be permanently
    displayed in its locked form.
        Geoff Kuenning   geoffat_private   http://www.cs.hmc.edu/~geoff/
    Date: Wed, 9 Jan 2002 11:04:45 +0100
    From: Paul van Keep <paulat_private>
    Subject: Re: ING bank debits wrong sum from accounts
    Several people have pointed out that I was wrong in my statement about
    disproving a 10000 euro cash withdrawal would be tough. Banks have a sane
    upper limit on the amount of cash you can withdraw from an ATM, even at your
    own branch. That limit is somewhere below 2000 euro. A 10000 euro ATM
    transaction is therefore totally impossible.
    Paul van Keep
    Date: Mon, 14 Jan 2002 07:34:47 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Counter Hack", Ed Skoulis
    BKCNTRHK.RVW   20011023
    "Counter Hack", Ed Skoulis, 2002, 0-13-033273-9, U$49.99/C$75.00
    %A   Ed Skoulis
    %C   One Lake St., Upper Saddle River, NJ   07458
    %D   2002
    %G   0-13-033273-9
    %I   Prentice Hall
    %O   U$49.99/C$75.00 800-576-3800 416-293-3621
    %P   564 p.
    %T   "Counter Hack"
    Chapter one, as in many texts, is an introduction to the book, but is
    unusually important in this case.  First, Skoulis lays out the philosophy
    behind the work.  While the text of the book does concentrate on attacks,
    the author points out that invaders already have other sources of
    information.  Further, Skoulis proposes that a detailed, complete, and
    integrated examination of representative samples of classes of attacks will
    provide an outline of defensive measures that can protect against a wide
    variety of assaults.
    A second point in this introduction is a brief examination of the character
    of attackers.  Skoulis does point out that those who attempt to penetrate
    computer and communications security do so from a diversity of motivations
    and skill levels.  However, he does tend to overstress the participation of
    "professional hackers," proposing that industrial espionage, terrorism, and
    organized computer crime activities are common.  Certainly such campaigns
    may become common, making the need for pre-planning even more important, but
    the vast majority of endeavors we are seeing at present are amateur efforts.
    Finally, the introduction recommends the establishment of a computer
    security test laboratory, which is an excellent idea for any large
    corporation, but probably is not within the financial, personnel, or
    educational reach of even medium sized businesses.
    Chapter two provides a background in TCP/IP for the purposes of discussing
    networking offence and defence.  There are frequent forward references to
    later sections of the book that deal with network attacks.  The material
    could, however, have been condensed somewhat to emphasize those aspects of
    the protocols that are closely related to security.  UNIX and Windows (NT
    and 2000) are similarly covered in chapters three and four, and, again, the
    text could be tightened up by focusing on safety factors.
    Chapter five points out the ways in which people can obtain data in order to
    direct and mount an attack.  While the content is informative, and there are
    a  few suggestions  for restricting  the release  of such  intelligence, the
    defensive value of  the text is limited.  The  information gathering process
    continues  in chapter  six with  war dialling  and port  scanning.  Defences
    against application  and operating system  attacks are covered a  bit better
    than  in most  "hacking" books  (there are  descriptions of  buffer overflow
    detection  tools),  but the  protective  value  of  chapter seven  is  still
    questionable.  Chapter eight  examines network sniffing, scanning, spoofing,
    and hijacking.  Denial of service  is covered well in chapter nine.  Various
    examples of malware are described in chapter ten.  Chapter eleven deals with
    the means used to hide an attack.
    A number of scenarios are created in chapter twelve.  Chapter thirteen
    describes some resources for keeping up with the latest computer
    Recently there has been a flood of books to the security marketplace, all
    based on the premise that if you know how to attack a system, you will know
    how to defend it.  Skoulis has done a better job than most, but the thesis
    is still unproven.  Yes, knowledge of the details of an attack does help you
    fine tune your defence.  Yes, providing specifics of an example of a class
    of attacks does help you consider a protective mechanism that might work
    against a whole class.  Yes, Skoulis does recommend safeguards for most of
    the attacks listed.  But taking a crowbar to a padlock still doesn't teach
    you locksmith skills.
    copyright Robert M. Slade, 2001   BKCNTRHK.RVW   20011023
    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.87

    This archive was generated by hypermail 2b30 : Sat Jan 19 2002 - 11:35:13 PST