[risks] Risks Digest 21.86

From: RISKS List Owner (riskoat_private)
Date: Thu Jan 10 2002 - 10:54:08 PST

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

    RISKS-LIST: Risks-Forum Digest  Thursday 10 January 2002  Volume 21 : Issue 86
       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.86.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Credit-card cloners' $1B scam (Monty Solomon via David Farber)
    Mag-stripes on retail gift cards (Tim Christman)
    Luton schoolboy profits from Euro chaos (Clive Page)
    Another Euro surprise (Otto Stolz)
    A Web site about PC security asking to lower PC/browser security 
      (Koos van den Hout)
    Other blunders on "secure" Web sites (Skip La Fetra)
    Re: Harvard admissions e-mail bounced by AOL spam filters (Fredric L. Rice)
    User Web habits tracked by some music-swapping programs (NewsScan)
    Kaiser Permanente exposes medical record numbers (J Debert)
    ATT ignores it's own privacy policy? (J Debert)
    Peoples Federal Savings Bank explains their interest calculations 
      (Jonathan Kamens)
    Re: "Buffer Overflow" security problems (Stephen Steel)
    Re: "Buffer Overflow" security problems and PL/I (Kelly Bert Manning)
    Buffer overflows aren't the only issue (Rex Black)
    Separate I and D spaces (Mike Albaugh)
    Abridged info on RISKS (comp.risks)
    Date: Mon, 07 Jan 2002 20:07:25 -0500
    From: David Farber <daveat_private>
    Subject: Credit-card cloners' $1B scam
    Homemade machines costing about $50 are being used to read credit-card
    mag-stripes, without having to steal the cards.  The information is then
    e-mailed abroad, where cloned cards are fabricated.  This has become a
    billion-dollar-a-year enterprise.
    [PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists,
    mobsters in on hacking racket, by William Sherman, *NY Daily News*
      [The gadget was first demonstrated in maybe 1960s at Caltech as part of a
      demo on how poor the mag-striped credit cards were. In spite of that, they
      won.  Dave]
    Date: Sat, 29 Dec 2001 09:59:00 -0600
    From: Tim Christman <tjcat_private>
    Subject: Mag-stripes on retail gift cards
    Here's a link to an article on MSNBC that I found interesting --
    Many retailers are replacing paper gift certificates with small plastic
    cards containing magnetic stripes, similar to credit cards.  Ideally, the
    purchase of a gift card would result in a database being updated to reflect
    the balance associated with the card's unique account number.
    Some retailers are using sequential account numbers and have no provisions
    to protect against a thief using a mag-stripe reader/writer to re-program a
    stolen card or small denomination card so that it matches the account number
    of a larger valued card purchased by someone else.  Many retailers even
    provide a convenient 1-800 number so that the thief, knowing many valid
    account numbers, can "shop" for a card of significantly greater value.
    The RISK: A form of fraud, difficult to trace, involving a minimal
    investment in equipment by the thief.  Also note that the thief only
    requires the ability to query the back-end database (through the toll-free
    number), not the ability to manipulate the records.  Perhaps more ominously,
    the risk is angry family members who find a zero balance on their gift
    Solutions: One retailer, mentioned in the article, uses optical bar-coding
    which can't be re-encoded without defacing the card.  Another follows a
    technique used by many credit card companies -- extra check digits are
    included in the mag-stripe that are not visible on the face of the card.  It
    seems astounding that this isn't being done by all.
    Date: Sun, 6 Jan 2002 19:11:02 +0000
    From: Clive Page <Cliveat_private>
    Subject: Luton schoolboy profits from Euro chaos
    I hope you won't mind another Euro-related story, but this one is rather
    charming.  The facts are taken from my local newspaper, the *Luton on
    Sunday*, but the story made a brief appearance in some national papers.
    Although the UK is one of the three European Union countries not to have
    adopted the Euro, many large retailers in the UK announced that they would
    accept them, but would give change in pounds sterling.  Among these was the
    Debenhams chain of department stores.  (Incidentally, I'm told that
    officially the plural of Euro is Euro, presumably to prevent language wars.)
    Robert Sheilds, a 15-years old Luton schoolboy, decided he would like
    experience of using Euro, so he changed 10 pounds to Euro at a bank, and
    went on to his local branch of Debenhams to spend them.  He found that they
    had programmed their tills as if there were 1.6 pounds to the Euro rather
    than 1.6 Euro to the pound, but none of the sales assistants was experienced
    enough to notice the error.  So after his initial purchase, he still had
    more than 10 pounds in change.  He tried to tell the store staff of their
    mistake, but they said the rate was programmed into the computer, and nobody
    had the authority to change it.  So he carried on spending, and after two
    hours, ended up with 130 pounds of goods, and 20 pounds in cash.  At this
    point the store manager asked him to leave, saying "I think you've had your
    fun".  Richard then took a train to Bedford (about 20 miles away) to try his
    luck at another branch, but by this time staff had been alerted, and refused
    all Euro transactions.
    Date: Tue, 08 Jan 2002 17:34:11 +0100
    From: Otto Stolz <Otto.Stolz@lh-iplanet.rz.uni-konstanz.de>
    Subject: Another Euro surprise
    Here is one more example of the unexpected implications a large project
    (such as the introduction of a new currency) can have.  It is not a
    murderous risk, but you may find the story instructive, and perhaps amusing.
    Today, I received an assessment from the local tax office.  The amount due
    was the former amount converted from DM to EUR -- almost, but not exactly:
    it was rounded up to the nearest multiple of 0,1 EUR.
    Thus, the new annual amount was no more a multiple of 4. As the amount is
    due by quarterly installments, the assessment told my to pay three equal
    amounts (at certain dates every year) and another amount, which is 0.02 EUR
    larger, at some other date.
    Of course, my bank had already converted my standing remittance order from
    DM to EUR. However, this being not adequate, I tried to adapt it to the new
    tax assessment. (I dare not risk the trouble of owing anything to the tax
    office, not even 0,02 EUR, would you?)
    It turned out that the bank is not prepared to handle a standing order of
    this type. I could have four annual orders instead, one per quarter. I
    preferred to do it the other way: I left my original order as it was, and
    placed a new order for 0,02 EUR (roughly 0,02 US$) per year. I hope well
    that somebody at the tax office will be irritated with this extra paying.
    The lesson to be learned: any change in a large, working system will have
    unexpected, possibly undesired, results. Be on your guard!
    Date: Mon, 7 Jan 2002 10:08:24 +0100
    From: Koos van den Hout <koosat_private>
    Subject: A Web site about PC security asking to lower PC/browser security
    I received an e-mail this morning with an unknown .exe attachment which on
    inspection seemed to do something with registry keys. Since it doesn't look
    like any of the viruses I heard about recently I tried to look for it on
    Therefor, I visited <http://www.mcafee.com/> first using Netscape 4.72 for
    Solaris (I use a Solaris workstation). The site shows a pop-up asking me to
    enable an ActiveX plug-in, but I might be able to use the site without
    it. The fact that I am using a different operating system for which an
    ActiveX plug-in isn't available at all has never crossed the mind of whoever
    designed that.
    To top that, when I visit the site using Lynx 2.8.2 (a text-mode browser for
    Unix, quite popular with blind or near-blind Internet users) I just get a
    page asking me to enable scripting by LOWERING the 'Internet security'
    setting on my Web browser. Never mind the fact that there are browsers for
    which there is no scripting and that it can be a decision made for security
    reasons. Literal text:
        3. In the Internet Control Panel, Select the Security tab
        4. Select the "Internet" zone
        5. If the security level is set to "High"
             a. Change the setting to "Medium" or click the "Reset" button
                for the Internet Zone
    If McAfee wants to look like a company that sells products for 'Securing
    your PC' they might want to set up their Web site so I don't have to LOWER
    the security of my browser.
    The security history of Javascript and ActiveX do not suggest to me that
    they are welcome on a 'Securing your PC' site.
    [Genuine virus investigators interested in the mail with 'ASD.EXE'
    attachment should contact me privately]
    Koos van den Hout  koosat_private  http://idefix.net/~koos/     
    Date: Sat, 5 Jan 2002 14:15:07 -0800
    From: "Skip La Fetra" <Skipat_private>
    Subject: Other blunders on "secure" Web sites
    In RISKS-21.84, Jeffrey Mogul ("When a 'secure site' isn't") points to some
    "secure" sites which fail to properly implement https secure protocols.
    In an incident from two years ago, my employer required use of an online 
    form which required credit-card info for cards which were billed to 
    employees.  This "secure site" was provided by an external supplier.  
    Naturally I checked for https use and browser "lock" icons.
    All went well until the final confirmation screen.  In addition to the 
    "you have ordered zzzzz with credit card yyyyyy" expected, imagine my 
    surprise when I noticed that the URL of the page contained ALL of my 
    6789,ExpirationDate=3D12/31/2001" etc.
    Being part of the URL "address", this information (including my name, 
    address, credit card number, and expiration date) was not protected, 
    even though the page was sent using "https".
    A discreet call to the webmaster for this site provided a quick reply -- 
    that all was okay, and all pages were sent using "https".
    A second call (and a CC to a very-high-ranking IT manager) explaining 
    the difference between "PUT" and "GET" in forms processing produced a 
    fix -- and an apology.
    Moral:  Even when the technology is secure, people can still blunder 
    around it.  The analogy which was effective in this case was talking to 
    their IT engineers about the US postal system -- and pointing out that 
    writing information on the outside of an envelope isn't secure even if 
    the envelope itself is protected.
    Date: Tue, 08 Jan 2002 13:14:02
    From: "Fredric L. Rice" <friceat_private>
    Subject: Re: Harvard admissions e-mail bounced by AOL spam filters (R-21.84)
    I'll doubtlessly draw a lot of flack in my inbound e-mail for this comment
    yet what the hell: Harvard sent a lot of e-mail out to people who submitted
    entrance requests with an AOL return e-mail address and then AOL filtered
    them out as bulk spam.  As much as many people hate to admit it -- whether
    it's deserved or not -- AOL users have a reputation in newsgroups
    approximately one step above that of WebTV users.  "Get a real ISP and
    people will talk to you" is something I see in newsgroups from time to time.
    I doubt that Harvard's admissions department looks at an AOL address and
    decides the applicant should be rejected based solely upon that fact but
    what about prospective employees?  People in IT departments might wonder
    whether someone's using AOL because they're not Internet savy enough to
    figure out how to install, set up, configure and use a real ISP with real
    client software packages.
    AOL is marketed toward the average smuck with a plug-it-
    in-and-it-will-just-work requirement.  It doesn't take a genius to figure
    out how to use a real ISP with real servers and slients but AOL _is_
    targeted to people who don't want to read "Internet For Dummies."
    Date: Mon, 07 Jan 2002 09:23:26 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: User Web habits tracked by some music-swapping programs
    The Web surfing habits of people who used the LimeWire, Grokster and KaZaA
    music-sharing programs were surreptitiously tracked because those programs
    were linked to an online sweepstakes game called ClickTillUWin, in which
    players pick numbers and win cash prizes. The company that operates the
    sweepstakes game says it told outside distributors to get users' permission
    before installing the software, but in these cases that action was not
    taken. The three companies have posted new versions of their software
    without the tracking component, and LimeWire has issued an apology. (AP/*USA
    Today*, 4 Jan 2002; NewsScan Daily, 7 January 2002)
    Date: Sat, 05 Jan 2002 23:52:37 -0800
    From: j debert <jdebertat_private>
    Subject: Kaiser Permanente exposes medical record numbers
    Here's yet another example of how an organization fails to
    abide by it's own security policies:
    Kaiser Permanente has a Web site for members at http://www.kponline.org/ .
    The first page here is the signon page, where one enters a medical record
    number and their region to enter the site.
    A statement concerning online security can be seen at:
    <http://www.kponline.org/ns/signon/signonmember?view=Security> .
    This statement indicates in the first paragraph that the medical
    record number will be sent via SSL:
      Signing On
      You need to sign on using your Kaiser Medical Number.
      This number will be transmitted using secure technology (SSL).
      We need your Kaiser Medical Number before you get into the site
      for two main reasons:
    (Note that this is the statement still in effect as of 1 Jan 2002.)
    However no SSL connection is possible. Every attempt to obtain a secure
    connection gets redirected to the non-secure page.
    The people in Kaiser's kponline service center seem to have no clue and no
    concern about this lapse. They say to disregard the security statement
    because it applies only to those already signed up for access which is not
    indicated in the security statement and cannot understand what the problem
    is. Pointing out that that is not what is stated just annoys them.
    The service reps say that no one can use the medical record number to access
    personal information online. Seems like that's all they are concerned
    with. They also claim that there is no way a medical record number can be
    associated with a patient. I am fairly certain that these claims are easily
    proven false.
    The RISKS are quite obvious but Kaiser seems oblivious to the obvious even
    when pointed out in detail.
    Date: Sat, 05 Jan 2002 23:23:56 -0800
    From: j debert <jdebertat_private>
    Subject: ATT ignores it's own privacy policy?
    Yet another example of how an organization ignores its own published
    privacy policy:
    ATT allows customers to send form mail using SSL on their Web site.  This is
    to keep their customer's info and the message private.
    But their people include the entire message in plaintext e-mail messages
    sent in response defeating the purpose of the secure form.
    Their privacy policy as published online essentially says that they will
    keep customer info private.
    RISKS? What RISKS? TO customers? So? What's the problem???
    Date: Sun, 23 Dec 2001 21:43:41 -0500
    From: Jonathan Kamens <jikat_private>
    Subject: Peoples Federal Savings Bank explains their interest calculations
    Well, it took five months of letters and contacting the local news media and
    several regulatory agencies, but I finally got Peoples to explain why their
    interest calculations for June 2001 differed from mine.  So this message is
    the retraction I promised I would submit if Peoples proved to me that their
    interest calculations were correct.
    (This, of course, does not change the fact that they stonewalled me for five
    months and caused me all sorts of other grief when they "upgraded" their
    computer systems in June.)
    The technical explanation, for those of you who are interested.... In their
    old computer system, they calculated interest for the month on the
    second-to-last day of the month, using the ending balance for that day as
    the ending balance for the last day of the month as well.  If in fact the
    ending balance changed on the last day of the month, a credit or debit was
    applied to the interest payment for the *next* month.  My calculations of
    what my interest payment should have been did not include this credit, and
    indeed *could* not include this credit because the bank never explained this
    part of their algorithm to me (despite my multiple requests for a precise
    explanation of how they were calculating interest).
    On the bright side, their new computer system pays interest at the beginning
    of the month for the entire previous month, so this particular bit of
    brain-damage is gone.  But I won't be staying with this bank for long enough
    to enjoy that particular "perk" -- would you stay with a bank whose officers
    either were incapable of explaining to you how they calculate interest, or
    simply refused to take the time to do so, until you pressured them about it
    for five months?
    See <URL:http://www.mit.edu/~jik/pfsb_problem/> for the whole story,
    including this latest installment.
    Jonathan Kamens
    Date: Mon, 7 Jan 2002 19:12:39 -0500 
    From: Stephen Steel <steve.steelat_private>
    Subject: Re: "Buffer Overflow" security problems (Leichter, RISKS-21.85)
    The primary problem here is not the C language, but the associated standard
    library, because the library is responsible for a lot of the C/C++
    programming culture.  Almost every book on C programming had lots of
    examples using sprintf(), strcpy() and other buffer overflow prone
    functions. And programmers took these examples to heart, duplicating them in
    the programming interfaces they wrote.
    If the topic of buffer overflows came up, then strncpy() would probably be
    mentioned. What a fine example this was for the beginning programmer: it
    wouldn't overwrite the destination buffer if called correctly, but the copy
    of the original string in the buffer had an unbounded length!  (since the
    copy would not be properly NUL terminated if the source string was as long
    or longer than the buffer size).
    Its a great pity the first C standards didn't provide two variants of the
    standard library and a standard means of selecting which variant would be
    used. Safe versions of the problematic functions would be include in both
    variants, and the recommended variant library would have omitted the unsafe
    functions completely (for completely new code).
    Stephen C. Steel <stephen.steelat_private>
    Date: Mon, 7 Jan 2002 21:54:47 -0500 (EST)
    From: bo774at_private (Kelly Bert Manning)
    Subject: Re: "Buffer Overflow" security problems and PL/I
    PL/I also supports string subscript range checking, in addition to Array
    Bounds checking, but in working with PL/I since 1973 I've never seen a site
    that had them as the site default. The site I currently work with runs at
    100% processing capacity from 07:00 to 23:00 every day. OTOH, they feel that
    DB2 is the way to go even though IMS still beats DB2 by at least 2:1, so
    perhaps it would be worth giving this a try as the site
    At the moment I can't recall whether a protection exception or a data
    exception is the most common symptom, but I've got it down to the point
    where I can quote the PL/I manual section advice about adding a Subscript
    and Array bound Check prefix in my sleep for "unidentified routine
    malfunction" types of errors when on call programmers give up and ask for DB
    Admin advice.
    It rarely shows up in that overt form. I'm more concerned about it happening
    quietly without ringing alarm bells. BTW, in the only major program where I
    ever had to worry about array overflow(why not use a DB instead) I made the
    array CONTROLLED with a REFER clause and checked the array size explicitly,
    allocating a new larger array and printing and warning message if I reached
    the array size limit.
    It is always interesting to compare the confidence with which programmers
    state that they don't feel they have an Array bound problem with their quite
    manner when they get back to me with confirmation that adding the
    stringrange and subscriptrange checks zeroed in on the problem.
    Date: Mon, 07 Jan 2002 21:35:35 -0600
    From: Rex Black <rexblackat_private>
    Subject: Buffer overflows aren't the only issue
    As a long-time practitioner of software testing, let me mention that, while
    buffer overflows are commonly exploited for security breaches, plenty of
    software quality problems--some of which are quite risky to the users--arise
    from other causes. Just off the top of my head, I can spout off the
    following unforgivable "buggy software" stories, none of which have anything
    to do with buffer overflows as far as I can tell:
    * An expense reporting program, QuickXPense, that didn't have any data
    quality bugs at all...at least until the operating system crashed. (Gee,
    what are the odds of that?) Once the OS did crash, the file was randomly
    corrupted, and the corruption cascaded with subsequent use, so ultimately
    the entire expense report file was garbage. The vendor's technical support
    staff was aware of the problem, but rather than a patch or a file report
    utility, they suggested that I "e-mail your file and we'll fix it." Well,
    sure, there's nothing private or personal in that file.
    * The fact that some PowerPoint presentation files, if corrupted--by, say,
    the computer going into power-saving hibernation at just the wrong time--in
    as much as a single bit in some cases, can become totally unreadable by the
    program. (See the first and last bullet for ways this might happen.)
    Microsoft knows about this bug, but they choose not to include recovery
    utilities in their applications. Instead, after a $100 paid support call,
    they send you to a software developer--who would be called a "highwayman" a
    couple centuries ago--who charges $400 for his recovery tool. Talk about
    turning the incompetence of others into a business opportunity!
    * The Windows NT network driver that came with a 3Com network card which, on
    two out of three boots, is unable to see the network. No diagnostic messages
    come up. Cold booting the system until communications are re-established is
    the only cure.
    * The automatic update software in my Toshiba laptop that recently
    "upgraded" the drivers for the built-in Xircom MPCI modem--without prompting
    me--which resulted in the loss of all modem definitions in my Windows
    "Device Manager". (Device mismanager?) I wasted an entire day trying to get
    the drivers reloaded. Toshiba's technical support was worse than clueless,
    having me try the same thing over and over until the batteries on my cell
    phone died, ending the call. Ultimately I had to go out and buy a new modem,
    which also turned out to solve a bunch of connection problems I had,
    indicating that the buggy setup problem was only the tip of the iceberg,
    quality-wise, with this modem.
    * The Lexmark printer I bought that didn't say anything in the manuals or
    installation process about the fact that you couldn't install it on a
    networked PC and access it from other systems on the network. After a few
    hours of trying, I e-mailed tech support, only to get response that boiled
    down to, "Oh, yeah, you can't do that." Oh, really? Why can't I do that? I
    have a twelve-year-old Epson dot matrix printer that was built before anyone
    had a small office network. I can share that printer just fine with every
    computer on my network. This whiz-bang color printer-scanner-copier that I
    bought in the day of ubiquitous small office/home office/home computer
    networking can't be shared with other computers? Pshaw!
    * The daily (or more often) crash that my Windows Me laptop computer
    subjects me to, generally without warning, usually losing a good fifteen
    minutes worth of work. I guess I should learn to save every thirty seconds?
    If experienced people like me have problems like this, imagine the average 
    computer user who has no idea whatsoever about what is going on when her 
    system screws up. And why should they have to understand a computer to use 
    them? (Don Norman, in his book *The Invisible Computer*, discusses this 
    situation at length.) Ultimately, a computer is a tool, nothing more, 
    nothing less. I think we have a long way to go before we can claim levels 
    of quality consistent with what the makers of almost any other tool could 
    Rex Black, Principal, Rex Black Consulting Services, Inc., 31520 Beck Road
    Bulverde, TX 78163 USA   +1 (830) 438-4830  www.rexblackconsulting.com
    Date: Mon, 7 Jan 2002 15:22:45 -0800 (PST)
    From: Mike Albaugh <albaughat_private>
    Subject: Separate I and D spaces (Re: Buffer overflows, Baker, RISKS-21.85)
      [This feels like my days reading comp.programming (Been "clean and sober"
      off Usenet for over a year now :-) MEA ]
    ... As someone who, until very recently, wrote primarily code that was
    executed from ROM, I need to point out that "corrupting running code" is not
    needed.  If one can corrupt the subroutine return-address (normally _part_
    of a buffer-overflow attack), one can point it wherever one wishes.  If a
    sufficiently dangerous set of instructions (or bytes that could be
    interpreted as instructions) already exists in the "instruction memory", one
    can do the intended mischief.
    As for Henry's assertion that such devices are "more vulnerable" because
    "nobody bothers to run virus-checking software on them", I think this
    exhibits touching faith in anti-virus authors and a mis-understanding of the
    most common recent viruses.  Outlook could be in ROM and "Execute Only"
    (No-Read) and I still would have gotten a mailbox full of mail whose subject
    I won't include so this copy of RISKS will get through :-) Buffer-overflows
    are indeed examples of shoddy programming practices, but they are hardly the
    most popular vulnerability.  People who leave their doors open need not fret
    overly about the quality of their locks.
    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.86

    This archive was generated by hypermail 2b30 : Thu Jan 10 2002 - 12:04:46 PST