Risks Digest 21.93

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

RISKS-LIST: Risks-Forum Digest  Tuesday 5 March 2002  Volume 21 : Issue 93

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

  Contents:
Malfunction shuts down computer-controlled amusement park ride (Chuck Hardin)
A$ 22,000 in fines for missing car-toll transponder (Peter Trei)
Air Transat emergency landing (John Johnson)
Nick Petreley: Identity theft (Anthony W. Youngman)
Metro: Time runs out for Domesday discs (Chris Leeson)
RISKS to computers from society (Arthur J. Byrnes)
Corporate Web sites leave cold steely feeling (Dan Jacobson)
Tunneling too close to the person you're trying to protect: SafeWeb
  (David Martin)
Privacy risk in Netscape 6 (Sim IJskes)
Electronic Voting in Ireland (Peter Thornton)
Re: Miami-Dade OKs touchscreen voting (Les Barstow, Mark Nelson)
Re: The homograph problem (Partha)
Re: Dangerous Characters (Dick Botting, Darrell Fuhriman, Bill McGonigle)
REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Sat, 02 Mar 2002 08:57:38 -0600
From: Chuck Hardin <chardin () suchdamage org>
Subject: Malfunction shuts down computer-controlled amusement park ride

  http://news.bbc.co.uk/hi/english/uk/england/newsid_1850000/1850592.stm

  It was a perfect day in the capital for viewing the skyline from the giant
  London Eye.  But a computer problem made the 450-ft-high structure rotate
  too fast, and it was halted amid safety fears.  Engineers have been
  brought in to get the attraction, officially known as the British Airways
  London Eye, up and running again.

This calls to mind Ben Morphett's narrative in RISKS-21.50 about a carnival
ride which gave him a bad moment by displaying a blue screen of death just
before it began its (planned?) rapid descent.  The difference is that in his
case, the computer was merely providing some graphical effects and was not
apparently responsible for controlling the ride.  Not so in this case.

Four hundred and fifty feet is a long way to fall, or to be hurled, due to
an ill-considered RISK.

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

Date: Tue, 26 Feb 2002 15:20:10 -0500
From: "Trei, Peter" <ptrei () rsasecurity com>
Subject: A$ 22,000 in fines for missing car-toll transponder

  A man used City Link more than 220 times without an e-tag, attracting at
  least $22,000 in fines, because he did not know it had become a toll road,
  the Melbourne Magistrates Court was told yesterday. [...]
  http://theage.com.au/articles/2002/02/26/1014704951335.html

Some highways in Australia cannot be legally used without a radio tag.  This
poor soul hadn't updated his address with the DMV.  The RISK lies in
building systems which automatically rack up charges without limit, and no
backup notification system.  A big flashing sign saying 'E-Tag missing!'
might have helped.  Peter Trei

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

Date:   Mon, 4 Mar 2002 15:36:27 -0500
From: john.johnson () dalsa com
Subject: Air Transat emergency landing

I thought RISKS readers would be interested in a developing story in the
news about a computer problem on the Canadian Air Transat flight that made
an emergency landing in the Azores last summer.  Apparently, as early
reports describe, a "computer program" incorrectly reported a fuel leak as
an "imbalance".  To correct the "imbalance" the "computer program" diverted
fuel from a good tank to the tank that was leaking thus both tanks were
emptied.  Inflight.  The skill of the pilot and the availability of an
island with an airport in the Atlantic Ocean averted a disaster.

Source: Canadian Press, *Toronto Globe and Mail*, *Toronto Star*, & other
Canadian newspapers

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

Date: Thu, 21 Feb 2002 13:05:11 -0000
From: "Anthony W. Youngman" <Anthony.Youngman () ECA-International com>
Subject: Nick Petreley: Identity theft

  http://www.computerworld.com/cwi/story/0,1199,NAV47-74_STO68446,00.html

Nick Petreley's *Computerworld* column (18 Feb 2002) describes how some
unknown person hijacked his phone account and made loads of long-distance
calls "at his expense".  The saga goes from bad to worse as poor security
and company incompetence frustrates his attempts to stop the fraud.

  [After noticing the frequent calls to Germany, Nick canceled his calling
  card and switched his long-distance carrier.  The person who had been
  piggybacking on his old card then managed to switch his new account back to
  the old carrier and make more calls.  It turns out that person had created
  a Web account for him, so that he no longer received statements.  The
  entire saga is a real horror story, and very well worth reading.  Lots of
  lessons to be learned.  PGN]

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

Date: Mon, 4 Mar 2002 09:51:50 -0000 
From: "LEESON, Chris" <CHRIS.LEESON () london sema slb com>
Subject: Metro: Time runs out for Domesday discs

The BBC's 1986 Domesday Project (a time capsule containing sound, images,
video and data defining life in Britain) is now unreadable. The data was
stored on 12-inch video discs that were only readable by the BBC Micro, of
which only a handful still exist.  The time capsule contains "250,000 place
names, 25,000 maps, 50,000 pictures, 3,000 data sets and 60 minutes of
moving pictures.".  The article notes that the original Domesday Book
(compiled in 1086 for tax purposes) is still in "mint condition".
[Source: London *Metro*, 01 Mar 2002]

Additional comments of my own:

The BBC Micro, along with the original Sinclair Computers, was the computer
that sparked off the "computer revolution" in the UK. The BBC Micro was
especially popular in schools, whereas the Sinclair computers were more
popular in the home.

To be fair, the 1986 Domesday Project was in the days before the really
rapid changes in technology came into force - the BBC Micro was not a bad
choice of platform then, especially when you consider that there were very
few other choices available (50,000 pictures alone take up a lot of space).

Moral/Risk: If you are wanting long-term data storage, the format is just as
important as the materials.

This is not a new problem - It has appeared in Risks before (RISKS-21.56:
'NASA data from 1970s lost due to "forgotten" file format' for one...), but
is worth keeping in mind. I still have an old Commodore 64/128 disk with my
(very) old account details on it - not that I have a C64/128 any more.  My
permanent records, however, are the printouts.

PS: "Domed... We are all Doomed..."

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

Date: Sat, 23 Feb 2002 20:53:21 -0500
From: "Arthur J. Byrnes" <arthur () ajb com>
Subject: RISKS to computers from society

Reading the various articles about buffer overflow and WiFi security
problems, makes you think that Society has to worry about risks from
computers.

Then I have two incidents in one week that remind me that computers are the
ones at risk.

First a I get a misdirected plain-text e-mail from a major insurance company
with login IDs, passwords, and usage instructions, (that seemed to come
from one of those "Dummies" books).  As much as my curiosity wanted to try
them out, my ethics stopped me.  A note to the company got an auto reply, no
thanks, or inquiry about how/why I ended up with this seemingly important
e-mail.

Then later in the week I added a new Web site to my Microsoft Central
account.  The welcome plain-text e-mail contained my login name and password,
which is also my .Net login.  They made clients sign up for .Net in order to
continue using their service.  (I'm glad I don't use it for anything else!)

Two major companies that should have known better, put Society's computers
at Risk, with a practice that is unpardonable.  Never send login IDs and
passwords together...

Arthur J. Byrnes  http://www.ajb.com

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

Date: 28 Feb 2002 03:56:16 +0800
From: Dan Jacobson <jidanni () deadspam com>
Subject: Corporate Web sites leave cold steely feeling

Now that I have traded my corporate life for "back to nature", every once in
a while there is a long term bond from my past life or something that is
about to expire, hence I must log on to some corporate site, wherein right
off the bat:

Browser Upgrade                        
   Thank you for visiting Jackson National Life Insurance Company's
   Web site. We have noticed you are using an earlier version of null.

Also, aren't those little lock symbols supposed to lock when asking for SS#,
passwd, etc.?

And don't you hate those Web sites that after filling in a long form, you
are to pick which of the 50 states you live in... I get stuck here.  I would
have used the toll free phone # but it is not toll free for me.

OK, now turning to the AT&T Universal card site... Ah, AT&T, equal
opportunity employer... OK, but still, cant use the Lynx browser... what if
I was vision impaired?  And, why after establishing that I am not spam,
cannot I have an e-mail conversation with these corporate giants about
compatibility issues with their Web sites without having to "login to
send/receive secure e-mail"... takes half of my modem session.

http://www.geocities.com/jidanni/ Taiwan(04)25854780

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

Date: Thu, 14 Feb 2002 16:50:52 -0500
From: "David Martin" <dm () cs bu edu>
Subject: Tunneling too close to the person you're trying to protect: SafeWeb

A tunnel is the prototypical example of a security mechanism that doesn't
compose well: it creates an end-to-end connection that can bypass
intermediate scrutiny.  SafeWeb, the Web anonymizing service, fell into this
trap by attaching the browser end of its tunnel too closely to the user and
thereby bypassing meaningful browser protections.  The result is that users
of the service are at higher risk of some types of privacy attacks than
those who refrain from using the service.

Note that SafeWeb's anonymizing service was shut down in December for
business reasons.  However, its technology was licensed to In-Q-Tel (the
venture capital firm funded by the CIA) and PrivaSec LLC.  PrivaSec is
currently offering a public beta test of its service based on SafeWeb's
technology at its Web site http://www.privasec.com.  For simplicity, we'll
pretend the system is still running at safeweb.com in the rest of this
article.

First a quick SafeWeb overview: a SafeWeb user types in a URL.  It goes to
safeweb.com within an SSL connection; SafeWeb sanitizes the requested
content and delivers it back to the browser.  The origin server Web site
only sees a connection from safeweb.com, and eavesdroppers near the user
only see an encrypted connection to safeweb.com On-screen, SafeWeb uses
frames to separate the SafeWeb controls from the requested content.  Let's
call them the "control" and "content" frames.

Now let's meet the protections: (1) simultaneously open windows or frames
can only communicate with each other if they're from the same domain, (2)
scripts stop running when a new page is displayed, and (3) cookies are
available only to the domain that set them.

The problem is that both of SafeWeb's frames are served from the same tunnel
(https://www.safeweb.com/) even though their content comes from radically
different sources: the trusted SafeWeb site on the one hand, and the
untrusted third party site on the other.  Since both frames come from the
same domain, the Web browser exposes each Document Object Model to the
other: protection #1 is gone.

Since the control frame is basically static, it's a great place for an
attacker to tuck away any code that needs to persist throughout the browsing
session -- like spyware.  So protection #2 is gone too.

SafeWeb also wanted to support pseudonymous persistent cookies.  Since the
content frame is always associated with a single privacy domain, they
aggregated all of the pseudonymous cookies from sites a user might visit
through SafeWeb into one "master cookie" associated with the fixed domain
safeweb.com.  That way, the individual cookies all get stored on the user's
computer in a slightly different form, and SafeWeb doesn't have to maintain
any persistent state on their servers (and users don't have to log in to
SafeWeb, etc.).  But this approach discards protection #3 as well.

To exploit these lost protections, an attacker has to take control of one of
the frames: the content frame is the obvious choice.  That turns out to be
not too hard.  SafeWeb *requires* that JavaScript be enabled in the browser.
Recognizing the risk, SafeWeb tried to sanitize scripts delivered to the
content frame, but they didn't go nearly far enough.  The result?  By
choosing to use this privacy enhancing system, users become vulnerable to
having their IP address revealed, *all* of their cookies stolen, and the
remainder of their privacy-"enhanced" browsing session silently transmitted
to an attacker in spite of the layer of SSL protection.  This is not
speculation; we have tested several effective exploits against the system.

Discarding protection mechanisms is only justified if those protections are
replaced by something stronger, or by something more valuable to the end
users.  SafeWeb's system did keep its users' identities out of routinely
gathered Web server logs.  But the cost was increased vulnerability to
targeted attacks, and it's hard to say whether the system's users would
consider this a good tradeoff.  There's no reason to think they would be
aware of the tradeoff at all.

Adding to the weirdness, we are told that this privacy enhancing service was
subjected to a "stringent" technological review by the CIA.

Details (24 pages, PDF) are available at
http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf.

In response to our observations, SafeWeb points out that their own service
is no longer in operation, that their new products didn't inherit these
problems, that the system was effective at resisting passive attacks, and
that the adversaries they had in mind wouldn't have been willing to use
attacks such as ours for fear of bad publicity.  They have also announced
that they are developing a fix for their licensees, In-Q-Tel and PrivaSec.

David Martin -- dm () cs bu edu
Andrew Schulman -- undoc () sonic net

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

Date: Thu, 21 Feb 2002 21:05:43 +0100
From: Sim IJskes <sim () nyx xs4all nl>
Subject: Privacy risk in Netscape 6

I just installed the Netscape browser version 6.2. I changed 'Internet
search' options so that Netscape performed searches through Google instead
of the Netscape search engine.

Some browsing in the files that were installed led me to this line:

action="http://info.netscape.com/fwd/lksidus_gg/http://www.google.com/search";

in a file "SBWeb_02.src". It looked as if Google directed search requests
are first sent to info.netscape.com. A quick look in the proxy server log on
the server confirmed my suspicion.

I guess that Netscape allows you to search other search engines than their
own, but still wants to know what you are searching....

P.S. a similar mechanism was also used in the 'SmartDownload manager' 
some years ago, as i seem to remember (maybe still is).

Sim IJskes, Leiderdorp, The Netherlands      |   sim () nyx xs4all nl

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

Date: Mon, 25 Feb 2002 14:48:22 -0000
From: "Peter Thornton" <Peter.Thornton () emr-radio ie>
Subject: Electronic Voting in Ireland

Further to recent contributions on electronic voting, this is from the
Web site of the Irish department of the environment:
  http://www.environ.ie/press/electvote02.html
The "forthcoming general election" they refer to will be taking place in
the next three months. I note that they will be using "an industry
standard PC system". I presume that this means a Wintel box. 
 
Green Light For Electronic Voting In Dublin North, Dublin West And Meath

Mr Noel Dempsey TD, Minister for the Environment and Local Government has
announced today (19 February) that the constituencies of Dublin North,
Dublin West and Meath have been chosen as the pilot constituencies for the
introduction of electronic voting.  "Subject to final testing of software,
my intention is that the voters in Dublin North, Dublin West and Meath will
be the first in the country to cast their ballots electronically. Thus, the
forthcoming General Election should usher in a new age of efficiency in the
voting process," said Minister Dempsey. "Electronic voting will dramatically
speed up the counting process with results for the constituencies likely to
be available within a half an hour of the final module, on which the cast
votes are stored, being delivered to the counting centres."
 
The electronic voting system to be used has been developed by the Dutch/UK
company, Nedap/Powervote. The Nedap/Powervote solution will provide a
'fullface' (large screen) machine which is successfully used in the
Netherlands and in the German cities of Cologne and Dusseldorf.  Election
preparation will be run from an industry-standard PC system and the
completion of the count will also be carried out on a standard PC and
programming unit.
 
In the run up to the introduction of electronic voting, there will be an
intensive public information campaign in the constituencies concerned to
ensure that all voters will be familiar with the new method of voting.
 
Peter Thornton, EMR Radio & Telemetry, Unit 11 Dunboyne Business Park
Dunboyne Co. Meath  Tel: +353-1-8013161

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

Date: Thu, 21 Feb 2002 07:03:28 -0700
From: Les Barstow <lbarstow () vr1 com>
Subject: Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90)

With physical access to voting machines and/or the software used to
control them, the only sure way to provide security is a paper record.

Especially with OpenSource software, it becomes possible to recompile
(and hence alter) any electronic-only record.  Closed Source software
isn't any better - it lacks public accountability and scrutiny.  Someone
could always create a new ROM, OS, or software image if given sufficient
knowledge, bypassing any security system that has been put in place.

So:  Print an OCR paper record when the voter finishes his vote.  He
gets to check the paper copy and put it in a standard secured voting
box.  The best parts are:

  (a) Since it's printed on demand, only the voter's candidate appears
      on the printout - the voter sees only who or what he voted for,
      or that he made no vote, and can easily check the paper before
      dropping it in the box.
  (b) Using OCR, independent auditing becomes easy.  The auditor needs
      little in the way of custom hardware or software to do the job;
      they only need to tweak their OCR readers.  Auditors could be
      chosen by mutual agreement of the candidates after the vote is
      completed (and only if a candidate determines he wants to have
      a recount), removing any temptation to bribe the auditing firm.

Les Barstow, System Administrator, VR1, Inc. 
http://www.vr1.com  lbarstow () vr1 com

  [We've been talking about such schemes before here.  See Rebecca Mercuri's
  PhD thesis for a detailed analysis:
    http://www.notablesoftware.com/~evote  
  noted in RISKS-21.10,13,14,61.  PGN]

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

Date: Fri, 22 Feb 2002 15:56:57 -0500
From: Mark Nelson <mcnels1@h_o_t_m_a_i_l_._c_o_m>
Subject: Re: Miami-Dade OKs touchscreen voting (Brain, RISKS-21.92)

> The risks for vote-rigging on COTS systems [include]:

e) Someone tweaks the compiler of the compiler of the compiler of the...

See Ken Thompson's "Reflections on Trusting Trust"
  http://www.acm.org/classics/sep95/

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

Date: Thu, 28 Feb 2002 19:16:12 +0530
From: Partha <algolog () hd1 vsnl net in>
Subject: Re: The homograph problem (RISKS-21.91 and 92)

I am a victim of one such problem. Our Indian bureaucrats in the Govt.
owned ISP called VSNL decided to create domain names using a mixture of
alphas and Arabic numerals. Resultant: I have an e-mail address containing a
"one". It is impossible to make out the "one" from "lower case L", and as
result of which I lose many many e-mails destined for me.  I have mitigated
the problem to a certain extent, by adding a descriptive note in my
signature box, but it is impossible to print such things on my visiting
cards.  Notice that there is also a "lower case L" in the second field of my
domain name "v-s-n-L". We (Indians) are perhaps the only ones in the world
to have such confusing combinations of alphas and numerals in their domain
names.

When will we ever learn?

PS: VSNL has now been "privatised". They changed the owners but they
kept the brilliant employees who created this mad domain name.

Dr. S. Parthasarathy, Algologic Research & Solutions, 78 Sancharpuri Colony, 
Bowenpally, Secunderabad 500 011 - INDIA  Phone: + 91 - 40 - 775 1650

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

Date: Thu, 21 Feb 2002 13:41:31 -0800
From: Dick Botting <rbotting () csusb edu>
Subject: Re: Dangerous Characters (Lomas, RISKS-21.92)

This looks like the "sanitization" procedures for user supplied data that is
recommended for the Perl language.  Perl is used by many Webmeisters.
Typically, it has to call other programs and uses a "shell escape" to do so.
On UNIX boxes it does this in such a way that the shell interprets the
passed data as a command.  An apostrophe is a string delimiter and so a
stray blip can play havoc with string data...  A smart user can easily make
the server execute any command.  Hence User data is sanitized by removing
certain characters.

Another solution is to avoid Perl. Scripts written in Bourne/Korn/Born Again
SHell do not have this problem.  Care is still needed, but the removal of
the usual suspect characters is not necessary.

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

Date: 21 Feb 2002 13:49:09 -0800
From: Darrell Fuhriman <darrell () grumblesmurf net>
Subject: Re: Dangerous characters (Lomas, RISKS-21.92)

I regularly have perfectly valid e-mail addresses rejected by Web forms
because they contain a '+' sign.  Most Web sites seem to assume that anything
not in the set [A-Za-z1-9_-] is invalid, even though the valid set defined
in RFC 2822 is much larger than that.

I wonder what's going to happen when, inevitably, e-mail addresses are
allowed to be in Unicode.  I fully suspect that we'll suddenly find a large
portion of the population unable to use their nifty new language appropriate
addresses.

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

Date: Thu, 21 Feb 2002 11:46:48 -0500
From: Bill McGonigle <mcgonigle () medicalmedia com>
Subject: Re: Dangerous characters (Lomas, RISKS-21.92)

Probably Waitrose is storing their orders in a SQL database.  In most SQL
statements, apostrophes need to be escaped, typically as '' (that's two
single quotes).  I've met so-called Web-site programmers to whom the notion
of an escape character suggests something out of a prison-break movie.
Often they notice a problem, with the database of course, when trying to
store text with an apostrophe, so they put some 'error checking' code in to
prevent those errors.

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

Date: Mon, 4 Mar 2002 07:44:27 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Security Fundamentals for E-Commerce", Vesna Hassler

BKSCFUEC.RVW   20020108

"Security Fundamentals for E-Commerce", Vesna Hassler, 2001,
1-58053-108-3, U$83.00
%A   Vesna Hassler hassler () infosys tuwien ac at
%C   685 Canton St., Norwood, MA   02062
%D   2001
%G   1-58053-108-3
%I   Artech House/Horizon
%O   U$83.00 800-225-9977 fax: 617-769-6334 artech () artech-house com
%P   409 p.
%T   "Security Fundamentals for E-Commerce"

"The purpose of this book is to give an in-depth overview of all the basic
security problems and solutions that can be relevant for an e-commerce
application."  I'm sorry, but "in-depth overview" sounds a bit like "jumbo
shrimp": it's an oxymoron.  And "all the basic security problems and
solutions that can be relevant for an e-commerce application" covers a lot
of ground.  (Which is, I suppose, why this text has twenty two chapters.)

Part one explains the basics of information security.  Chapter one defines
some of the basic jargon, but misses a number of the important fundamental
terms.  For example, the relationship between threats, vulnerabilities and
exploits is fairly basic to security and risk analysis, and yet all security
problems seem to be lumped together as threats.  The examination of security
mechanisms, in chapter two, is limited to cryptography.  Key management is
restricted to X.509 certificates and Diffie-Hellman in chapter three.

Part two looks specifically at security of electronic payment systems.
Chapter four briefly lists a wide variety of payment systems.  A terse set
of payment security problems is given in chapter five, while some seemingly
random cryptographic solutions are given in six.  A little bit of math for
functions directed at electronic cash and cheques is presented in chapters
seven and eight, respectively.  Chapter nine describes the Internet Open
Trading Protocol.

Part three deals with communications security.  Chapter ten is a general
look at networking.  Chapters eleven to fourteen examine different systems
for security at different layers, but the depth of coverage is very
inconsistent: extremely terse in some cases, with many gaps, and yet delving
into minute detail in others.

Part four examines Web security.  Chapter fifteen details the HyperText
Transfer Protocol (HTTP), which is good, since few texts bother to do.
Random topics related to Web servers make up chapter sixteen.  Web client
security topics are dealt with somewhat better in chapter seventeen,
although cookies aren't given any significant discussion.  Active content
does get its own chapter: eighteen concentrates almost exclusively on Java.
Chapter nineteen contains miscellaneous topics.

Part five covers some special issues for mobile or agent computing.  Agent
technology is described in chapter twenty, some cellular phone topics are
reviewed in twenty one, and smart card security is discussed in twenty two.

Well, overview it is.  The book does cover a variety of topics, although
there are a great many gaps and holes.  However, "in-depth" can't be
supported, except in a very few cases.  There are some topics that are
discussed in excruciating detail, but they are definitely in the minority.
As a college text this undoubtedly has its uses, but professionals or
businesspeople will find the inconsistent coverage problematic.

copyright Robert M. Slade, 2002   BKSCFUEC.RVW   20020108
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: 12 Feb 2001 (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 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-request () pica army mil> (Dennis Rears).
   .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 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.93
************************