The RISKS Digest
Volume 21 Issue 90

Sunday, 10th February 2002

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


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?
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
Info on RISKS (comp.risks)

Software bug blamed in radioactive spill

<Adam Shostack <>>
Wed, 30 Jan 2002 13:45:14 -0500
Andrew Colley, CNET, 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]

CT unemployment insurance folk mail out "off by one" letters

<danny burstein <>>
Fri, 25 Jan 2002 23:32:54 -0500 (EST)

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.

Adult content filter considers MSDN Flash as "Unwanted adult spam"

<"Dekker, G.J." <>>
Wed, 23 Jan 2002 08:27:40 +0100

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

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

HP annual report bitten by spelling software

Tue, 29 Jan 2002 19:42:45 -0600 (CST)

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.

Turning Macs on Thievery

<Monty Solomon <>>
Sun, 27 Jan 2002 20:39:46 -0500

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.  [...],2125,50025,00.html
Tracing a Stolen iMac Using Timbuktu

Instructive story

<"Edward W. Felten" <>>
Mon, 04 Feb 2002 15:54:30 -0800

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, 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 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 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, 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 is a
well-known computer scientist who definitely should have known better.
[RISK #5: Thinking that RISKS only apply to newbies.]

E-commerce website automatic response proves costly

<brian ally <>>
Fri, 01 Feb 2002 04:34:22 -0500

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.

Automated upgrade means no statistics

<Paul Roberts <>>
Wed, 23 Jan 2002 13:19:08 +0800

A report via APP that appeared on Australian IT
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.

Yet another Microsoft Outlook exploit

<Bear Giles <>>
Mon, 28 Jan 2002 22:31:26 -0700 (MST)

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" and you're off and

Microsoft's official position, at;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

Bug in MS Excel?

<Alberto <>>
Sat, 26 Jan 2002 15:08:16 +1100 (EST)

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

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

Therefore the rows after the deleted one are all reporting misleading

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

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 <>

Re: Excel cut-and-pasting behaviour (Brent, RISKS-21.88)

<Peter Jeremy <>>
Tue, 29 Jan 2002 07:53:51 +1100

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 :-).

UK to try remote voting

<"Merlyn Kline" <>>
Tue, 5 Feb 2002 17:42:16 -0000

According to the BBC
"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

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

"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

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

Miami-Dade OKs touchscreen voting

<"David E. Price" <>>
Wed, 30 Jan 2002 11:08:31 -0800

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]

Re: Even unscientific elections get rigged (Epstein, RISKS-21.87)

<Joe Thompson <>>
Sun, 27 Jan 2002 12:14:48 -0500

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 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.

Re: Woman says telephone makes unsolicited calls (RISKS-21.88)

<"William Kucharski" <>>
Thu, 24 Jan 2002 07:00:26 -0700

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...

More Kaiser followup

<Geoff Kuenning <>>
Mon, 28 Jan 2002 14:31:03 -0800

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

Re: REVIEW: "CISSP Examination Textbooks", S. Rao Vallabhaneni

<Rob Slade <>>
Thu, 7 Feb 2002 11:04:02 -0800

BKCISPET.RVW   20011122

"CISSP Examination Textbooks", S. Rao Vallabhaneni, 2000, , U$213.00
%A   S. Rao Vallabhaneni
%C   P.O. Box 681354, Schaumburg, IL   60168-1354
%D   2000
%I   SRV Professional Publications
%O   U$99.00 per volume 847-330-0126
%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 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    or

Please report problems with the web pages to the maintainer