Risks Digest 21.90

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

RISKS-LIST: Risks-Forum Digest  Sunday 10 February 2002  Volume 21 : Issue 90

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

  Contents:
Software bug blamed in radioactive spill (Adam Shostack)
CT unemployment insurance folk mail out "off by one" letters (Danny Burstein)
Adult content filter considers MSDN Flash as "Unwanted adult spam" 
  (G.J. Dekker)
HP annual report bitten by spelling software (Jim Griffith)
Turning Macs on Thievery (Monty Solomon)
Instructive story (Edward W. Felten)
E-commerce website automatic response proves costly (Brian Ally)
Automated upgrade means no statistics (Paul Roberts)
Yet another Microsoft Outlook exploit (Bear Giles)
Bug in MS Excel? (Alberto)
Re: Excel cut-and-pasting behaviour (Peter Jeremy)
UK to try remote voting (Merlyn Kline)
Miami-Dade OKs touchscreen voting (David E. Price)
Re: Even unscientific elections get rigged (Joe Thompson)
Re: Woman says telephone makes unsolicited calls (William Kucharski)
More Kaiser followup (Geoff Kuenning)
Re: REVIEW: "CISSP Examination Textbooks", S. Rao Vallabhaneni (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Wed, 30 Jan 2002 13:45:14 -0500
From: Adam Shostack <adam () zeroknowledge com>
Subject: Software bug blamed in radioactive spill

http://news.com.com/2100-1001-826124.html
Andrew Colley, CNET News.com, 30 Jan 2002

SYDNEY, Australia--Amec Engineering, which designed the Beverly uranium
processing plant in Western Australia, has blamed buggy software for a
radioactive spill that occurred at the site last December, confirming early
suspicions that computers played a role in the accident.  "After a detailed
assessment of the incident it is now clear that the problem was caused by a
computer programming error that has since been corrected," said Stephen
Middleton, spokesman for the plant's operator, Heathgate Resources.
According to Amec's report, the glitch cut power to the plant's
fluid-distribution control system during a routine service exercise. At the
time, the mechanism should have shut down pumps moving fluid into the plant.
"Before they could be shut down manually, pressure built up in the pipelines
leading into the plant and one ruptured," Middleton said.  According to
Middleton, Amec has re-examined the entire system, retested the plant's
pipes and corrected the "computer logic error."  He refused to name the
software technology responsible for the error.

[It doesn't sound to me like a software error that pipelines had no pressure
gauges or relief valves; but it's always hard to say how correct media
reports are.  Does Australia have freedom of information laws or other means
of access to see Amec's report? Adam]

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

Date: Fri, 25 Jan 2002 23:32:54 -0500 (EST)
From: danny burstein <dannyb () panix com>
Subject: CT unemployment insurance folk mail out "off by one" letters

Labor Department finds error in unemployment compensation tax forms

  An error has been found on tax forms sent to Connecticut residents who
  collected unemployment compensation last year, the state Department of
  Labor announced Friday.  About 5,000 forms -- less than 3 percent of the
  176,000 tax forms sent -- contain information pertinent to individuals
  other than the named unemployment compensation recipient.  [...]  [Source
  unspecified, 25 Jan 2002]

The article doesn't go into much more detail, but it sounds like a classic
mix and merge problem, with the headers for the mailing labels being off by
one (or more...) from the other data fields.

Nothing on the CT Web site about this yet.

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

Date: Wed, 23 Jan 2002 08:27:40 +0100
From: "Dekker, G.J." <gjdekker () nlr nl>
Subject: Adult content filter considers MSDN Flash as "Unwanted adult spam"

The Microsoft e-mail newsletter MSDN Flash, Volume 6, Number 2, January 22,
2002, contains advertising text including the text (Copied almost literally;
note: I added one extra space after the word "over" to circumvent the
Microsoft filters.)

> Plus, VSLive! San Francisco provides over  180 hours of
> content in three technical conferences:

The standard Microsoft "Adult Content Filter" includes the rule that a
message body containing the text "over  18" is Adult Content.  [SPACE
added by PGN in hopes of avoiding filtering?]

As result, the MSDN Flash was rejected by Outlook, as being unwanted adult
content.

I Wonder how many Microsoft customers have read this number of the Flash.

Geert Jan Dekker, National Aerospace Laboratory (NLR), 
P.O. Box 153,8300 AD Emmeloord The Netherlands   +31 527 248435

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

Date: Tue, 29 Jan 2002 19:42:45 -0600 (CST)
From: griffith () olagrande net
Subject: HP annual report bitten by spelling software

An oldie but a goodie.  AP reports that HP's annual report filed Tuesday
mentions the names "David and Lucite Packard Foundation", "Edwin van
Pronghorns", "Eleanor Hewlett Limon", and "Mary Hewlett Gaffe", instead of
"Lucile", "Bronkhorst", "Gimon", and "Jaffe", respectively.

http://www.siliconvalley.com/docs/news/tech/085146.htm

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

Date: Sun, 27 Jan 2002 20:39:46 -0500
From: Monty Solomon <monty () roscom com>
Subject: Turning Macs on Thievery

In a story that is probably unique, R.D. Bridges recovered his sister's
stolen iMac using Netopia's Timbuktu Pro, a program that allows computers to
be remotely controlled and is widely used by computer-help technicians.
Bridges, who lives in Clear Lake, a suburb of Houston, had installed the
software to help his sister, who lives across town, when she ran into
problems.  [...]  
  http://www.wired.com/news/mac/0,2125,50025,00.html
Tracing a Stolen iMac Using Timbuktu
  http://www.macscripter.net/unscripted.html

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

Date: Mon, 04 Feb 2002 15:54:30 -0800
From: "Edward W. Felten" <ed () felten com>
Subject: Instructive story

Here is a true story that illustrates several familiar RISKS.

My sister-in-law Karen Rakow was quite surprised recently to discover that
according to a web site called slatkinfraud.com, she and her husband Robert
had pocketed more than $5 million from a Ponzi scheme in which they were
involved.  All of this was false -- including the part about having a
husband named Robert.  The accusation on the web site hyperlinked to Karen's
business and to her list of clients, and it even named one of her clients,
so this was a big problem for her.

A little research revealed what had probably happened: a person named Karen
Rakow was named in some court papers, and an Internet search for "Karen
Rakow" had turned up a link to a person with that name, who the
slatkinfraud.com people proceeded to accuse.  [RISK #1: Accusing person of a
crime based only on similarity of their name to that of a real suspect.]
[RISK #2: Trusting Internet searches to give semantically correct (and not
merely textually similar) results.]

So Karen asked the slatkinfraud.com people to remove the references to her,
her business, and her clients from their web site.  They replied by saying
they had done so, but in fact they had only removed some of the references.
Karen complained again, and they replied that "Our assistant webmaster has
made another search and believes that all references to you and your company
have now been removed from the site.

But we have 60 megabytes of material at slatkinfraud.com, so manual searches
are not the most efficient way of doing this."  [RISK #3: Using technology
to build artifacts that are too large for you to manage.]  [RISK #4: Making
unverified modifications that you cannot easily undo.]  Eventually all of
the offending references were found and removed (we think).

Here is the really interesting part: the webmaster of slatkinfraud.com is a
well-known computer scientist who definitely should have known better.
[RISK #5: Thinking that RISKS only apply to newbies.]

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

Date: Fri, 01 Feb 2002 04:34:22 -0500
From: brian ally <b.ally () sympatico ca>
Subject: E-commerce website automatic response proves costly

The BBC has this story about Kodak giving in to customer's demands that they
honour a wesite promotion for cameras mistakenly listed for [much] less than
they should have been. Seems their automatic e-mail response constituted an
acceptance of the sale. As a Web developer, I'll certainly keep this in mind
in the future.

http://news.bbc.co.uk/hi/english/sci/tech/newsid_1795000/1795624.stm

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

Date: Wed, 23 Jan 2002 13:19:08 +0800
From: Paul Roberts <Paul.Roberts () nautronix com au>
Subject: Automated upgrade means no statistics 

A report via APP that appeared on Australian IT 
(http://australianit.news.com.au/articles/0,7204,3602608%5E15306%5E%5Enbv%5E,00.html)
states that the Australian Bureau of statistics has been unable to provide
data on people leaving or arriving in Australia (information collected on
arrival/departure cards) for the last 18 months because of "technical
difficulties" in upgrading from a manual to an automated system. This data
is particularly useful to the tourism industry.

Apparently the "technical" difficulties are related to the outsourcing of
the computer system. Hmmm...sounds like there are more than "technical"
difficulties, but unfortunately the outsourced company is not named.

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

Date: Mon, 28 Jan 2002 22:31:26 -0700 (MST)
From: Bear Giles <bear () coyotesong com>
Subject: Yet another Microsoft Outlook exploit

Yet another Microsoft Outlook exploit is on the loose... and this time the
arrogance of the recommended solution is breathtaking.  The problem is the
built-in support for UUENCODED text within the body of a message.  Prudent
programmers will use a starting pattern such as

 "\n\nbegin ([[:octal:]]+) ([^\n]+)\n"

and subsequently verify that each line has the expected format.  Even
checking only the first few lines (e.g., verifying that the first character
correctly encodes the length of the rest of the line) essentially eliminates
any chance of a false hit.

Sadly, it will surprise few people that Microsoft cuts straight to the heart
of the matter.  If your line starts with "begin " (possibly with two
spaces), Outlook/Outlook Express WILL interpret the rest of the message as a
UUENCODED attachment.  It doesn't need a preceding blank line, nor a
following octal number.  It doesn't need subsequent lines that actually look
like UUENCODED data.

There are some reports on slashdot that later versions of O/OE have
discarded the "view source" command, with the effect that the rest of the
message is permanently lost to the user.  The use of this bug as a DOS
attack on mailing lists that use a 'digest' approach is left as an exercise
for the reader.

Naturally, it hasn't taken long for the malware writers to jump on the
bandwagon.  All you need to do to get around the "strip executable
attachment" killjoys is to put the malware right in the body of the message!
Just start a line with "begin 666 www.myparty.yahoo.com" and you're off and
running!

Microsoft's official position, at 
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q265230 , is
stunning in it's <s>feeble-mindedness</s> simplicity.  We, and by "we"
I mean every person on the planet who may ever send a message to an
O/OE <s>victim</s> user, or have a message forwarded to such users,
are advised (with editorial comments) to:

 * not start messages with the word "begin"

   (actually, it's *any* line starting with the word "begin".  And
   that's effectively a ban on the word "begin" for anyone using a
   mail agent with transparent line wrapping, e.g., the web mail 
   portals that some ISPs are pushing.)

 * capitalize the word "begin," even when used within a sentence.  E.g., 
   "We will Begin the new project when Bob returns from his vacation.

 * Use a different word such as "start" or "commence."  E.g., all
   training materials for new Visual Basic programmers shall henceforce 
   refer to "start/end" loops instead of "begin/end" loops.

Microsoft's justification for suggesting a significant change to the
English language instead of fixing their bug is given as:

  "In a SMTP e-mail message, a file attachment that is encoded in 
  UUencode format is defined when the word "begin" is followed by 
  two spaces and then some data,..."

Needless to say there is no citation given for this "fact."  That's probably
related to the fact that UUENCODE was defined by UUCP, not SMTP, and that
every encoder/decoder I have seen requires a leading blank line and a octal
file permissions code.

But the damage is done - since malware is exploiting this bug we now get to
put into place filters that don't just strip executable attachments or
properly formatted UUENCODED blocks, we also have to strip *improperly*
formatted UUENCODED blocks!

Bear Giles

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

Date: Sat, 26 Jan 2002 15:08:16 +1100 (EST)
From: Alberto <abit () wintermute anu edu au>
Subject: Bug in MS Excel?

Effect: Using database functions in Excel with autofilter on and hidden
columns. Deleting rows will scramble the rows of the database.

How to see it:
in Excel (all versions I tried fail) make a Database area, that is,
make a table with few rows and few columns, say 5 rows, 5 columns for
example. Fill it with whatever you want. Maybe fill the row 1 with
"c1", "c2", "c3", ... as those will be the names of the fields of the
Database. Also, fill 1 column only with 0 and 1.

Select the table (with 1 more empty row) and define the name for the area
"Database".

Chose the option AUTOFILTER ON, hide a column (not the one with 0 and 1),
using the automatic filter on the column with 0 and 1 ask for only the rows
with 0 in that column.

Delete a row in the middle.

unhide the column that was hidden, remove the filtering and see that Excel
did not delete the row in that column but did delete the row in the other
columns.

Therefore the rows after the deleted one are all reporting misleading
information.

I think this is serious. After some use the Database will be more or less
scrambled.

Note that this would not happen if the autofilter was off regardless the
number of hidden columns

Any advice?

Was this bug reported before?
                         
Alberto <abit () maths anu edu au>

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

Date: Tue, 29 Jan 2002 07:53:51 +1100
From: Peter Jeremy <peter.jeremy () alcatel com au>
Subject: Re: Excel cut-and-pasting behaviour (Brent, RISKS-21.88)

About 40 years ago, Ed Lorenz re-ran a weather forecasting model using
rounded figures and discovered Chaos Theory.  Maybe Microsoft is hoping
that Excel's (mis)behaviour will lead to an equally important discovery :-).

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

Date: Tue, 5 Feb 2002 17:42:16 -0000
From: "Merlyn Kline" <merlyn () zyweb com>
Subject: UK to try remote voting

According to the BBC
(http://news.bbc.co.uk/hi/english/uk_politics/newsid_1802000/1802956.stm),
"Voters in Liverpool and Sheffield will be able to cast their ballot by
sending a mobile phone text message in May's local elections." These
elections will significantly empower real people as members of local
councils.

Some more choice quotes from the article:

"The pilots will be crucial in building public confidence and testing
technical robustness to ensure that the integrity of the poll is
maintained."

"In some wards in Liverpool and Sheffield voters will be able to cast their
ballot by digital television as well as via their mobile phones."

"In Swindon there will be a touch-tone phone voting system, while Gateshead,
North Tyneside, Stevenage and Chorley will pilot elections where people can
only cast their ballot by post."

"The text messaging system will work by voters being given PIN numbers to
use if they want to vote by text message."

"Opponents of online voting argue it is too easily exploited by electoral
fraudsters..."

Endless potential RISKs discussed here previously may now be realised.
Doubtless some new ones will come to light, too.

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

Date: Wed, 30 Jan 2002 11:08:31 -0800
From: "David E. Price" <price16 () llnl gov>
Subject: Miami-Dade OKs touchscreen voting

Officials in Florida's Miami-Dade County have approved a $24.5 million
contract to replace the county's punch-card voting system with touchscreen
equipment, in time for Nov 2002.  The touchscreen machines make it
impossible to vote for more than one candidate in each race, known as
overvoting, and alert voters if they fail to select any candidate, or
undervote.  Two other counties that were at the heart of the controversy --
Palm Beach and Broward -- also plan to use touchscreens.  30 Jan 2002
[source not specified]

  [And as we have noted here before, today's touchscreen systems provide
  essentially ZERO hard evidence that your vote is counted as cast, and not
  for someone else or for no one.  With just a little insider fraud, what a
  remarkable opportunity for rigging elections!  PGN]

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

Date: Sun, 27 Jan 2002 12:14:48 -0500
From: Joe Thompson <joe () orion-com com>
Subject: Re: Even unscientific elections get rigged (Epstein, RISKS-21.87)

This is really nothing new.  The article Epstein linked to mentions the
Microsoft "astroturf" campaign, but as early as the spring of 1998 a
high-profile case of good-natured ballot stuffing was widely remarked upon:
the People Magazine poll for Most Beautiful People.  A campaign to write-in
Howard Stern regular "Hank, the Angry Drunken Dwarf" had already boosted him
to second place, until on 28 April 1998 Slashdot picked up the story and
Hank shot to number one (by a margin of over 10 times his nearest rival).
People played along to an extent, adding Hank as an official ballot choice,
but complaining about vote-stuffing.

That same spring I was witness to an episode more like Microsoft's effort.
The game company I worked for, Kesmai, had a game up for an online award
based on a reader survey.  The director of the department that included
testing (the section I was in) instructed us to "vote early and often" until
Kesmai's offering topped the list.  (Kesmai no longer exists, having been
bought by Electronic Arts in early 2000 and folded into the struggling
EA.com online game venture.)

All our effort was ultimately for naught, as by the next morning someone
*else* had apparently been hard at work stuffing the votes.  We pondered
writing a Perl script but never did so.

The real risk in both of these cases is the assumption that a) one's own 
poll is too small or specialized to attract a ballot-stuffing campaign or 
b) that you can effectively detect rogue voters in an anonymous system. 

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

Date: Thu, 24 Jan 2002 07:00:26 -0700
From: "William Kucharski" <kucharsk () mac com>
Subject: Re: Woman says telephone makes unsolicited calls (RISKS-21.88)

This is yet another in the "people treating Caller ID when the information
was never meant to be trusted" series.

As stated in past issues, anyone with a PBX system can program their system
to deliver any given name and phone number as the CNID (Calling Number ID)
information for any outgoing call from that system.  In most businesses,
this is used so that outgoing calls appear to be from that company's "main"
number for incoming calls rather than from the actual phone line used to
place the call.

A new trick many telemarketers are using to get around the new answering
machines and phone company features that automatically shunt "Private" and
"Out of Area" calls to telemarketer blocking features is to select a name at
random out of the phone book and use that name and phone number for their
outgoing CNID information.  I know I regularly receive telemarketing calls
that show up on my CID box as being from some person purported to be in the
619 area code...

This is no different from the way many spammers have recently taken to
grabbing valid e-mail addresses and using those as "From" addresses for their
missives.  (I can't tell you the number of bounced e-mail reports I get for
an e-mail address I stopped using some two or three years ago now, all with
typical SPAM subject lines and originating from an open SMTP relay somewhere
in the South Pacific.)

Alas, I don't believe misrepresentation of CNID information is any type of
crime, as, as stated before, it was never meant to be secure or any type of
authenticated representation of who is actually calling...

RISKS: Believing that either CNID information or the "From" line on e-mail
actually represent the true originator of the call or message in question...

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

Date: Mon, 28 Jan 2002 14:31:03 -0800
From: Geoff Kuenning <geoff () cs hmc edu>
Subject: More Kaiser followup

As a result of the recent discussion about security on the Kaiser Web site,
my friend there has gone through the Web site registration process.  In a
previous private e-mail, she noted that the Medical Record Number (MRN) is
not enough information to allow doing more than a few relatively innocuous
things like checking appointment times.  Here is her most recent message,
outlining the results of the Web registration process:

> I received a letter in the mail including an activation code:
>
> (Dear...
> Thanks...)
> The PIN you've chosen will always let you into the site.  The next time you
> visit our site, we'll also ask you for your one-time activation code.
>
> (Instructions)...  It will start the more confidential features of the Web
> Site, like answers to your personal health questions.
>
> We've sent you this Code by US Mail to make sure that no one is pretending
> to be you online.
>
> (If you have problems......)
>
> They never asked me for an address online so if the MRN and the name didn't
> match or the address was wrong, this wouldn't have made it to me.

Sounds like Kaiser has actually done a pretty good job.

Geoff Kuenning   geoff () cs hmc edu   http://www.cs.hmc.edu/~geoff/

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

Date: Thu, 7 Feb 2002 11:04:02 -0800
From: Rob Slade <rslade () sprint ca>
Subject: Re: REVIEW: "CISSP Examination Textbooks", S. Rao Vallabhaneni

BKCISPET.RVW   20011122

"CISSP Examination Textbooks", S. Rao Vallabhaneni, 2000, , U$213.00
%A   S. Rao Vallabhaneni srvbooks () aol com
%C   P.O. Box 681354, Schaumburg, IL   60168-1354
%D   2000
%I   SRV Professional Publications
%O   U$99.00 per volume 847-330-0126 www.srvbooks.com
%P   ~500 p. per volume
%T   "CISSP Examination Textbooks" (vol 1 Theory, vol 2 Practice)

I should probably declare a bias.  I am newly indoctrinated as a CISSP
(Certified Information Systems Security Professional) instructor, so,
presumably, anyone who decides to study for the exam out of a book, and not
take the course, reduces my chances of getting assigned to teach a course by
approximately 0.016 percent.

Having said that, then:

These books will not help you study for or write the CISSP exam.

These books may, in fact, make your study more difficult, and your chances
of passing the exam more remote.

At the very best, the time (and significant amount of money) you spend
studying these books will be wasted, when you could have been reviewing
other, more useful material.

If I went back through the files I might be able to find one, but, off the
top of my head, I cannot recall a technical book with a poorer structure,
organization, or grasp of the titular material.  Many authors fail to do
full research.  A large number present the content in a disorganized manner,
forcing the reader to do more work.  Some have their own idiosyncratic
definition of the topic, and may be slightly misleading in what they
deliver.  Seldom do the confluences of those aspects reach the depths of
uselessness seen in these volumes.

While the (ISC)2 (International Information Systems Security Certification
Consortium) CBK (Common Body of Knowledge) domain structure can be
problematic, the "Theory" volume does not seem to follow either the (ISC)2
study guide nor the CBK course outline. Point or section numbering is
inconsistent, making it difficult even to follow the material.  Tables and
illustrations are unclear, and either baldly repeat surrounding text, or
have no relation to it. (Tables are often carelessly broken between pages,
making reading of the charts and also surrounding text extremely difficult.)
There are endless mistakes in spelling, grammar, and sentence or paragraph
structure.  Non-standard terms are used, and not defined. Occasionally small
variations in phraseology seem to imply different topics that further (and
pointless) study reveals to be identical.  Major heading are sometimes
simply printed, and are not explained or introduced.  Certain topics and
phrases are heavily emphasized, although not defined, and many of these are
the most minor of issues in terms both of security and of the CISSP exam.
Much of the technical material is confused, such as an analysis of the
correspondence between "ISDN and OSI networks," which is something like
comparing apples and juice extractors.  The text contradicts itself
frequently: a simple list of firewalls on one page does not relate to
another three pages later.  Some technologies have only one aspect
explained, others are touched on without mentioning inherent dangers, others
are so confused that closely related topics end up being set in opposition
to each other.  (The malware definitions, needless to say, are appalling.)

The "Practice" volume is a set of multiple choice questions supposedly
similar to those you would encounter on the CISSP exam itself.  Only those
on the exam committee would be able to say, for certain, how close these
questions come to the real thing, but I can say that, in terms of
information security, a great many of these questions simply make no sense.
The quality of the second volume seems to approximate that of the first.

I must say that, while the books and the Web site do carry a disclaimer that
the tomes are not endorsed by (ISC)2, I am slightly appalled that (ISC)2 has
not objected to the use of this particular name.  In fact, these books
appear on the (ISC)2 resource list. Which, itself, carries a disclaimer that
such a listing does not imply any endorsement.  Even so, the simple
association gives the work a cachet that is wholly undeserved, and probably
misleading.  (I should also note that, as a relatively new CISSP I don't
have a solid idea of how the books on the reference list at
https://www.isc2.org/cgi-bin/content.cgi?page=36 got there.)

I should also note, in strict fairness, that one of my fellow instructors
used these books and self-study to pass his own exam, and said that he found
them very useful.

But, in my own opinion, and at the risk of repeating myself, if you are
studying for the CISSP:

Do not buy these books.

If you have bought these books, do not read them.

copyright Robert M. Slade, 2001   BKCISPET.RVW   20011122
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.90
************************