Risks Digest 22.58

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Friday 21 February 2003  Volume 22 : Issue 58

   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.58.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
Surgeons transplant mismatched organs (Steve Klein)
Health threat from computer use (Pete Mellor)
INFOSEC issues reach out to elevators (Russ Cage)
A $55,000 Net scam warning (Monty Solomon)
FTD.com hole leaks personal information (Fuzzy Gorilla)
ATM vulnerabilities and citibank's gag attempt (Ross Anderson)
Microsoft steamed over Hotmail spam (NewsScan)
Deadly input validation? (Chris Adams)
Fire risks (Tony Jones)
"E-lip" telemarketing phone systems (Al Meers)
Web site product serial number validation (Nik Smith)
Two-digit year field strikes again (Fuzzy Gorilla)
Too much tech can kill you (Jesus Climent)
Lawyers say hackers are getting bum rap (NewsScan)
Re: Playing Russian Roulette with traffic lights (Nicholas Weaver)
The fourth solution... (Peter da Silva)
REVIEW: "Mike Meyers' Security+ Certification Passport", Trevor Kay
  (Rob Slade)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 20 Feb 2003 11:44:33 -0500
From: Steve Klein <steveklein () mac com>
Subject: Surgeons transplant mismatched organs

On 7 Feb 2003, doctors at Duke Hospital in North Carolina mistakenly
transplanted a heart and lungs from a donor with Type A blood to a recipient
with Type O blood.  Her body immediately started rejecting the transplanted
organs.  The organs, which came from a cadaver in Massachusetts, included
paperwork correctly listing the donor's type-A blood.  The hospital admits
the error, but hasn't made public any information indicating how the mistake
was made.

On 20 Feb, new matching organs were transplanted in a second surgery.  Under
normal conditions, a heart-lung transplant has a 50% success rate.

  [I have yet to hear whether there was any computer-related error here --
  for example, someone miskeying the patient's blood type as A or 
  misrepresenting the donor's type as O.  Please let us know if you hear
  anything further.  PGN]

------------------------------

Date: Mon, 10 Feb 2003 01:09:44 +0000 (GMT)
From: Pete Mellor <pm () csr city ac uk>
Subject: Health threat from computer use

Sitting too long at your computer can cause potentially deadly blood clots.
The European Respiratory Journal reports the case of a young man from New
Zealand who nearly died after developing deep-vein thrombosis (DVT) after
using his computer as much as 18 hours a day.  The clot in his leg broke off
and traveled to his lungs.  (This problem has been reported on long airline
flights, and was reportedly first noticed in people who sait in World-War-2
air-raid shelters).  [Source: BBC news, 28 Jan 2003; PGN-ed]
  http://news.bbc.co.uk/1/hi/health/2698119.stm

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB +44 (0)20 7040 8422

------------------------------

Date: Thu, 20 Feb 2003 17:22:37 -0800 (PST)
From: Russ Cage <russcage937362 () yahoo com>
Subject: INFOSEC issues reach out to elevators

The RISKS of the following should be obvious to regular readers of
this forum.  Emphasis IN CAPITALS added by poster, not in original.

  INTERNET LIFT CONTROL: Alcala University's Electronic Department has a
  research group that is developing an electronic system that will monitor
  the operation state of an elevator and transmit that information through
  the Internet to a central computer.  The system would be installed in each
  lift with temperature-gauge inputs in various locations. The transmission
  signals WILL PERMIT THE MACHINERY TO BE RESET AND ACTED UPON BY REMOTE
  CONTROL.  Collaboration is being sought through a joint venture or a
  licensing/manufacturing agreement.  ....  ELENET(R) is a free e-mail
  newsletter transmitted biweekly by Elevator World, Inc., the publisher of
  ELEVATOR WORLD magazine.  ELENET(R) is a registered trademark and all
  rights are reserved. Copyright 2003(C) Elevator World, Inc., 356 Morgan
  Avenue, Mobile, AL 36606, phone: (251) 479-4514, fax: (251) 479-7043,
  Internet: www.elevator-world.com.

    [I got a real UPLIFT from reading that one.  I hope it PUSHES YOUR
    BUTTONS as well.  In elevator parlance, it could RUS(S)tle your CAGE.  I
    note that the Spanish word for elevator is "ascensor", which suggests
    that we might contemplate the SENSOR CENSOR that filters the information
    that is available to the Internet when a Critical Person or someone with
    a large rear end (as*censor) enters the elevator, and perhaps even a
    SEE-YOU-LATER-ALLOCATOR ACTUATOR when you wish to delay someone you
    don't like.  PGN]

------------------------------

Date: Tue, 28 Jan 2003 00:22:29 -0500
From: Monty Solomon <monty () roscom com>
Subject: A $55,000 Net scam warning
 
Despite being described as a long-time Internet user and an accomplished
dentist who was knowledgeable about Internet crime, Bruce Lachot decided to
buy a new BMW M5 over the Internet from someone in Germany, for the bargain
price of $55,000.  The result: no car, no trace of the seller, and the need
for a lot more dental patients.  [Bob Sullivan, MSNBC, 23 Jan 2003; PGN-ed]
  http://www.msnbc.com/news/854552.asp

------------------------------

Date: Sat, 15 Feb 2003 15:55:52 -0500
From: "Fuzzy Gorilla" <fuzzygorilla () euroseek com>
Subject: FTD.com hole leaks personal information

A security flaw at FTD.com left a large flowering bouquet of private
information ready for picking during the busy business week leading up to
Valentine's Day.  Using sequentially modified cookies, outsiders could
exhaustively access customer billing records, including names, addresses,
and phone numbers.  (Availability of credit-card data was reported
initially, but later denied by FTD -- perhaps after they blocked it.)  This
was discovered when one customer found another person's information
displayed by his browser, and reported to NTBugTraq on 12 Feb.  It was fixed
on 14 Feb.  Prerequisite for doing the attack was reported as 'HTML for
Dummies' (or equivalent).
  [Source: Robert Lemos, FTD.com hole leaks personal information,
  CNET News.com, 13 Feb 2003; PGN-ed]
    http://news.com.com/2100-1017-984585.html

------------------------------

Date: Thu, 20 Feb 2003 09:58:47 +0000
From: Ross Anderson <Ross.Anderson () cl cam ac uk>
Subject: ATM vulnerabilities and citibank's gag attempt

  [See the cryptome.org URL below, which is one of the sites at which
  this message and its supporting documents appeared.  PGN]

Citibank is trying to get an order in the High Court today gagging
public disclosure of crypto vulnerabilities:

    http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_gag.pdf

I have written to the judge opposing the order:

    http://www.cl.cam.ac.uk/ftp/users/rja14/citibank_response.pdf

The background is that my student Mike Bond has discovered some really
horrendous vulnerabilities in the cryptographic equipment commonly
used to protect the PINs used to identify customers to cash machines:

    http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-560.pdf

These vulnerabilities mean that bank insiders can almost trivially find out
the PINs of any or all customers.  The discoveries happened while Mike and I
were working as expert witnesses on a `phantom withdrawal' case.

The vulnerabilities are also scientifically interesting:

    http://cryptome.org/pacc.htm

For the last couple of years or so there has been a rising tide of
phantoms. I get e-mail with increasing frequency from people all over the
world whose banks have debited them for ATM withdrawals that they deny
making. Banks in many countries simply claim that their systems are secure
and so the customers must be responsible. It now looks like some of these
vulnerabilities have also been discovered by the bad guys. Our courts and
regulators should make the banks fix their systems, rather than just lying
about security and dumping the costs on the customers.

Curiously enough, Citi was also the bank in the case that set US law on
phantom withdrawals from ATMs (Judd v Citibank). They lost. I hope that's an
omen, if not a precedent ...

------------------------------

Date: Wed, 19 Feb 2003 08:38:14 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: Microsoft steamed over Hotmail spam

Microsoft has filed a lawsuit against unnamed bulk mailers who harvested the
e-mail addresses of Hotmail users in order to bombard them with junk
messages. The spammers allegedly used tools to randomly generate e-mail
addresses and then tested them to see which accounts were active. Microsoft
argues that this form of dictionary attack violates federal laws, including
the Computer Fraud and Abuse Act. (*The Register*, 19 Feb 2003; NewsScan
Daily, 19 Feb 2003)
  http://www.theregister.co.uk/content/6/29382.html

------------------------------

Date: Tue, 18 Feb 2003 22:00:39 -0800
From: Chris Adams <chris () improbable org>
Subject: Deadly input validation?

Two teenagers died when their rowboat sank in Long Island Sound on 24 Jan
2003.  The 911 operators who took their last-minute phone call have been
charged for not handling the call and delaying the search for a day.  The
story suggests that there may have been some familiar RISKS themes along
with the obvious ones: the operator attempted to enter "Long Island Sound"
as the location but the software prevented that and, after consulting an
equally ill-informed superviser, the operator simply gave up and dropped the
call.  It sounds like this was a known problem as the official response has
been that they should have known to use the address of the nearest police
station instead.  http://story.news.yahoo.com/news
?tmpl=story&ncid=533&e=9&cid=533&u=/ap/20030218/ap_on_re_us/missing_teens

------------------------------

Date: Fri, 21 Feb 2003 07:13:57 +1100
From: Tony Jones <tmj () apex net au>
Subject: Fire risks

A newly-available Web site at <http://www.sentinel.csiro.au/> declares:

"Sentinel Fire Mapping is a mapping tool designed to provide timely fire
location data to emergency service managers across Australia. The mapping
system allows users to identify fire locations that pose a potential risk to
communities and property."

Unfortunately, recent publicity for the site has generated a burning interest:

"Due to heavy demand this Web site is currently experiencing delays. 
Please be patient and allow priority access to emergency services."

------------------------------

Date: Fri, 21 Feb 2003 10:44:39 EST
From: AlMeers () aol com
Subject: "E-lip" telemarketing phone systems

I got a fundraising phone call last week from one of the US political
party's campaign fund raising organizations.  This alerted me to a new type
of phone-calling mechanism that more and more telemarketers are using.
While the voice on the other end of the line was human, there were odd
pauses between portions of our conversation, a few clicks on the other end
of the phone line, and sometimes an odd response to my questions or
comments.

I realized that I was talking to a machine which was being controlled by a
human.  Not an "Eliza" like computer program mind you, but a recorded voice
mechanism which a human was controlling.  Half of the responses were totally
appropriate, accurate, and well-delivered, but the rest seemed that "he" was
not really listening to me, or had to read from a pre-canned and scripted
set of responses.

Well, of course that is exactly what was going on.  The human telemarketer
would be listening to the call, and in response to my questions, comments,
and responses, push a button on a computer screen which would then play a
prerecorded statement in answer to my query. It was fairly easy to ask a
couple of offbeat questions which could only be handled by vague, stiff, and
rather useless zombie-like answers.

The system can actually be quite useful in many circumstances where the
phone operators repeat the exact same answers many times during the day.  A
live operator can sound bored, angry, distracted, or have a hard to
understand accent, where the prerecorded voice is always pleasant, clear,
and can even have the same regional or national accent of the caller.

These same human controlled computer response "e-lip" systems are not just
useful in telemarketing, they can also be useful in phone Customer support
environments, at least on the front line calls.

And in an Internet "chat" room support environment, one technician could
carry on multiple conversations simultaneously, responding by copy&pasting
pre-canned text to a screen full of slow typists. In a chat-room
environment, the delay in responses would barely be noticed unless the tech
was trying to do too many conversations at once.

http://sfgate.com/cgi-bin/article.cgi?f=3D/c/a/2003/02/19/LAZ.TMP
details a SBS Yahoo tech call with "Floyd"
and
support.sbcglobal.net/general/contact/
can connect you with "Austin".

Both are apparently a form of "e-lip" systems.

The risk here is that inappropriate responses from a "known" machine can be
tolerated to some extent, but my tolerance level shrunk to almost zero when
I realized that I was being "fooled" into thinking I was actually talking
with a human.  There is a difference between talking WITH a person, and
talking AT a person who is responding via a canned-response machine.  If I
was talking to Stephen Hawking, the machine responses are "normal", but
these systems are attempting to fake you out, and those same responses
evoked frustration, resentment, and maybe even anger.

After playing with the "cyborg machinery" for a few seconds I just hung up.

------------------------------

Date: Thu, 20 Feb 2003 18:01:41 -0000
From: "Nik Smith" <nik () djnz com>
Subject: Web site product serial number validation

Ok, I know it's not much of a security issue, but to leave the code in your
Web page viewable to see what format the 'valid serial number' should be is
just silly.

I wanted to download a patch for my lecturer to run a copy of 3dstudio
max on XP, and went to www.discreet.com to do this:
  (Yes, they have licenses, but the software version they use won't
  work on XP)
www.discreet.com/support/max  
where I was prompted for my name, surname, address, serial number of the
product etc in order to obtain the update.

After being told I had entered incorrect details persistently, I thought
I'd check the source code to see what it wanted.  Yep, there it was:

function ValidSerial(item) {
   if (item.length != 12) return false;
   if (item.indexOf('-') != 3) return false;
        var i;
        for (i = 0; i < item.length; i++) {
                var c = item.charAt(i);
          if (((c < "0") || (c > "9")) && (i != 3)) return false;
        }
 if (item == "226-19791979") return false;
 if (item == "110-12345678") return false;
   return true;

So, in goes a random number in the format clearly described, and away I go.
A valid street name and postal code can be obtained from www.streetmap.co.uk
and typing in a random street name, and an e-mail address, should they need
to send you an activation code or such like, can be set up at hotmail
instantly.  The least they could've done is use .asp to hide the code.  One
easy way to avoid disclosing your personal information to companies you'd
rather not have it.

Nik, student at BCUC(.ac.uk)

------------------------------

Date: Fri, 31 Jan 2003 18:22:21 -0500
From: "Fuzzy Gorilla" <fuzzygorilla () euroseek com>
Subject: Two-digit year field strikes again

In Norway, a 106-year-old woman was summoned to start school, and offered
free bus rides to the school.  The last time she had started school was of
course 1903, having been born in '97.  "Since I can already read, maybe I
should skip a couple grades," she joked.  [Source: Associated Press, 31 Jan
2003; PGN-ed]
  http://news.yahoo.com/news
  ?tmpl=story2&u=/ap/20030131/ap_on_fe_st/norway_senior_student

------------------------------

Date: Thu, 20 Feb 2003 12:33:12 +0100
From: Jesus Climent <jesus.climent () hispalinux es>
Subject: Too much tech can kill you

As a proof that technology can lead to a dead end, here it goes what
happened last winter to my girlfriend and me.  While visiting Portugal, in
Lisbon, we had to go to the doctor. The medical insurance she is subscribed
to allows her to receive medical assistance without any bills, which are
sent to the insurance company.  For the only purpose of being sure that the
carrier of the insurance title the insurance company is asked to send a fax
copy of the actual contract.

Oh well. That is not as easy as it sounds.  When called, the company
representative who answered the 24hrs service line said "we don't do faxes
anymore. Don't they have an e-mail address?"  It happens that in the 24
service hospital we went to, they do not have e-mail. And for that matter,
what kind of authentication mechanism both ends would have used to ensure
that the sender was who it claimed to be?

As seen, early technology adoption with a depreciation of old communication
methods is as bad as slow technology adoption.

Finally we had to pay the bill. She will probably sue the company ;)

Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es

------------------------------

Date: Fri, 21 Feb 2003 10:39:34 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: Lawyers say hackers are getting bum rap

The National Association of Criminal Defense Lawyers has joined with the
Electronic Frontier Foundation and the Sentencing Project in publishing a
position paper that argues people convicted of computer-related crimes tend
to receive harsher sentences than perpetrators of comparable
non-computer-related offenses. "The serious nature of the offenses is
overplayed," says Jennifer Granick, author of the paper and clinical
director at Stanford University's Center for Internet and Society. "The
(majority) of the offenses are generally disgruntled employees getting back
at the employer or trying to make money." In a review of 55 cases prosecuted
under the most-often used computer crime statute, only 15 involved harm to
the public and only one resulted in a threat to safety.  Those convicted
"are receiving sentences based on the fear of the worst-case scenario rather
than what the case may really be about," says Granick. The paper was
submitted in response a request for public comment by the U.S. Sentencing
Commission as required by the Homeland Security Act of 2002. Cybercrime
legal expert Scott Frewing says he agrees with many points raised in the
paper, but recommends a two-tiered sentencing threshold: "I would be
comfortable in a situation where the code addresses the discrepancy between
those who cause bodily injury and those that don't.  If that results in the
law being unfair to a virus writer, maybe that's enough to put them on
notice."  [CNet News.com 20 Feb 2003; NewsScan Daily, 21 February 2003]
  http://news.com.com/2100-1001-985407.html?tag=fd_top

------------------------------

Date: Wed, 19 Feb 2003 17:25:58 -0800
From: Nicholas Weaver <nweaver () CS berkeley edu>
Subject: Re: Playing Russian Roulette with traffic lights (Foster, R-22.57)

  [Dan Foster said "there is no safe way to deterministically
  recover" from the failure he described in RISKS-22.57.  PGN]

Actually, there is a reasonably "safe" automatic recovery procedure for
traffic lights to transition from blinking-red to normal operation: Switch
to red in all directions for the 10-20 seconds, in order to clear the
intersection of those who were crossing in 4-way stop mode.  This allows the
intersection to clear of traffic before normal operation resumes.

You can pick nits on cases where a car ends up being stuck in the
intersection after the light resumes normal operation, but those can occur
during normal operation as well.

  [Congratulations to RISKS readers who responded to this one.  We received
  over 100 messages, mostly with content similar to Nicholas's.  Many
  thanks.  That sets the all-time RISKS record thus far.  CHEERS!  PGN]

------------------------------

Date: 28 Jan 2003 19:45:22 GMT
From: peter () abbnm com (Peter da Silva)
Subject: The fourth solution... (Re: SQL Slammer, RISKS-22.52)

> As usual the two most common responses are:
>      1. Blame Microsoft for producing code with holes in.
>      2. Blame the sysadmins for not patching systems.
> [and 3. Nobody blames the anti-social [deleted] who wrote it]

My reaction is to blame the sysadmins who exposed a system to the Internet
running unhardened applications without minimal firewalls in place. I have
one Internet-visible box running SQL server... it's isolated behind a proxy
firewall that doesn't allow any connections n or out that aren't
specifically required for the application running on top of the
database. This is really the appropriate level of protection for an
application that's only "LAN tight"... regardless of who wrote the OS or
application.

I wouldn't demand everyone use a proxy firewall, but I would expect at least
as much protection between it and the Internet, and between the inside LAN
and it, as there is between the inside LAN and the Internet.

But even the elementary precaution of restricting incoming connections to
ports and addresses that are known to be required would have been enough to
stop this worm in its tracks.

------------------------------

Date: Thu, 20 Feb 2003 07:48:41 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Mike Meyers' Security+ Certification Passport", Trevor Kay

BKMMSCRP.RVW   20030207

"Mike Meyers' Security+ Certification Passport", Trevor Kay, 2003,
0-07-222741-9, U$29.99/C$44.95
%A   Trevor Kay trevor () trevorkay com
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2003
%G   0-07-222741-9
%I   McGraw-Hill Ryerson/Osborne
%O   U$29.99/C$44.95 800-565-5758 fax: 905-430-5020
%O  http://www.amazon.com/exec/obidos/ASIN/0072227419/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0072227419/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0072227419/robsladesin03-20
%P   363 + CD-ROM
%T   "Mike Meyers' Security+ Certification Passport"

Given the organization of the Security+ objectives, part one covers general
security concepts and chapter one is on access control.  Some factors are
dismissed a little bit too concisely: it is difficult to justify the blanket
statement that biometric authentication is "extremely accurate and secure."
(Biometrics does get a bit more explanation in the chapter on physical
security, but there is no indication of that in this location.)  For the
first set of sample questions, the emphasis is on simple definitions and
fact recitation, but later questions do become somewhat more complex.  A
variety of attacks are described in chapter two, generally reasonably.  The
virus material is unfortunately poor, concentrating on older viral
technologies (such as the almost extinct boot sector viruses and older DOS
precedence-based companions) and failing to provide proper outlines of the
basic antivirus technologies.

Part two looks at communications security.  Chapter three deals with remote
access, but the content has limited application to security.  Technologies
related to Internet application security are reviewed in chapter four.  The
highlights are touched on, but the lack of detail can be troubling.  Cookies
are discussed, with some mention of privacy, but the potential problem of
cross-site tracking is not dealt with at all, and neither is the danger of
HTML (HyperText Markup Language) formatted messages when the topic turns to
e-mail.  The material on wireless networking and security, in chapter five,
is very weak.  The explanation of direct-sequence spread spectrum is not
clear at all, a mention of SSL (Secure Sockets Layer) makes no reference to
the description in the previous chapter (and almost contradicts it), and
security itself gets short shrift in the haste to trot out the alphabet soup
of related technologies.

Part three deals with infrastructure security.  Chapter six runs through a
list of networking components, cabling, and storage media, again with
limited allusion to security.  Network topologies and intrusion detection
systems are discussed in chapter seven.  System hardening, generally by
applying patches and disabling functions, is reviewed in chapter eight.

Cryptography is in part four.  Most of the basic content in chapter nine is
sensible, but it is clear from the paragraphs on double- and triple-DES
(Data Encryption Standard) that the author does not fully understand the
subject.  Chapter ten reviews key management, but it is not clear why the
topic was separated from that of PKI (Public Key Infrastructure).

Part five deals with operational and organizational security.  Physical
security, in chapter eleven, is covered fairly well.  Disaster recovery is
confined to backups and fault tolerance: chapter twelve supports Kenneth
Myers contention (cf. BKMGTCPD.RVW) that most people concentrate on
recovering technology rather than the business, and would be improved by a
broader view that incorporated all aspects of the operation.  Chapter
thirteen lists some areas that should be covered in a security policy.
Forensics is dealt with poorly, and chapter fourteen also throws in
education and training.

While the book still adheres, rather slavishly, to the arbitrary structure
of the Security+ list of objectives, the content is generally pretty
reasonable, providing background explanations for important concepts, and
keeping the descriptions of many of the specific technologies limited to the
fundamental ideas.  The text does tend to be terse, given the size of the
book, but most basic material should be available to the student.  This does
vary by chapter: some seem to be merely going through the motions.  The work
could be improved with some removal of duplicated material.  For example,
there are three separate discussions of social engineering, and two could be
replaced with cross-references.  Despite its smaller size, I would recommend
this volume over the Syngress "Security+ Study Guide and DVD Training
System" (cf. BKSCRTYP.RVW), but not emphatically.

copyright, Robert M. Slade, 2003   BKMMSCRP.RVW   20030207
rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

------------------------------

Date: 29 Mar 2002 (LAST-MODIFIED)
From: RISKS-request () csl sri com
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-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 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.
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> 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 risks () CSL sri com 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.58
************************