The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 23 Issue 76

Monday 28 February 2005


BofA loses backup tapes in transit with customer data
Nicolai E M Plum
Some Sympathy for Paris Hilton
John Schwartz via Monty Solomon
Sensitive information: lesson learned
Bill Hopkins
Computerization of the automobile continues apace
Omri Schwarz
Address coercion
Paul D. Smith
Re: "Spam-blocker causes missed court date"
Joseph Brennan
Re: UK gets official virus alert site
Rob Skedgell
Re: Component Architecture
Mark Lutton
Steve Taylor
Jan Vorbrüggen
Olivier Dagenais
Paul D.Smith
Steven Hauser
Dimitri Maziuk
Bill Royds
Tom Swiss
Ross Lonstein
Dave Budd
Geoff Kuenning
Dan Jacobson
Info on RISKS (comp.risks)

BofA loses backup tapes in transit with customer data

<Nicolai E M Plum <>>
Sat, 26 Feb 2005 15:50:34 +0000

Bank of America "lost computer tapes containing account details of more than
one million customers who are US federal employees", reported by the BBC at

My first question is "Why were the backups not encrypted before leaving a
BofA site?". The RISK is obvious - handing unencrypted sensitive data to
random third parties significantly increases the chance of them being stolen
and misused. Commercial backup software offers encrypted backups these days,

There is another more general RISK, since the theft occurred on a commercial
airline flight. There is a conflict between wishing to lock your luggage to
prevent theft from luggage handlers (a group of people known to steal from
luggage) and being told that if you lock your luggage the lock may be forced
open and destroyed by the Transport Security Administration searching your
bags - you can't win. The "TSA [master] key" lock idea will just mean the
thieving baggage handler will acquire one of the master keys beforehand.

I doubt background checks, as suggested by Senator Charles Schumer in this
article, are an effective solution. Failure to encrypt these backups before
they went offsite seems negligent of BofA to me.

Some Sympathy for Paris Hilton (John Schwartz)

<Monty Solomon <>>
Sun, 27 Feb 2005 21:24:02 -0500

Some Sympathy for Paris Hilton
By JOHN SCHWARTZ,  *The New York Times*, 27 Feb 2005

POOR Paris Hilton!

As unlikely as the preceding sentence might seem, there is ample reason to
pity Ms. Hilton, the heiress, reality-TV actress, product pitchwoman and
accidental porn starlet.

Ms. Hilton just can't seem to get a break in the digital age. She suffered
embarrassment back in 2003 when a homemade sex tape hit the Internet, and
now her Sidekick - a high-tech toy that combines phone, organizer and camera
and also lets users send e-mail and instant messages - has been hacked. Its
contents, like her movie, were posted to the Internet for any and all to

"She was pretty upset about it," someone told MSNBC. "It's one thing to have
people looking at your sex tapes, but having people reading your personal
e-mails is a real invasion of privacy."  ...

Sensitive information: lesson learned

<"Bill Hopkins" <>>
Fri, 25 Feb 2005 18:25:46 -0500

A Delaware blood bank lost a laptop computer containing sensitive
information about donors when it fell off a truck (really).  It was found
and returned by the finder.

Officials say they will now encrypt the information to prevent its
unauthorized use or disclosure.

Who knew?  Perhaps the publicity will wake up a few others with
similar data responsibility.

[Source: WHYY-FM, the Philadelphia NPR station, filtered through BH]

Computerization of the automobile continues apace

<"Omri Schwarz" <ocschwar@MIT.EDU>>
Fri, 25 Feb 2005 12:13:51 -0500,0,2964317.story?co

This system takes over the steering in some situations:

  "Lane Departure Prevention" combines a camera and computerized devices
  that control braking for front and rear wheels, nudging the car in the
  right direction. The feature disengages when you hit the turn signal, so
  you can change lanes and make turns.

The RISKS are obvious.

Address coercion

<"Paul D.Smith" <>>
Fri, 25 Feb 2005 09:08:12 -0000

A few years ago I was working in the US and applied for a bank account.
They insisted on taking my "permanent" address, which was in England.  But
on entering the town, Enfield, they were then stuck - their software
insisted that Enfield was in either Vermont or a couple of other US states.
There is indeed an Enfield in Vermont, just not mine.  Just another example
of the software being made too "clever" by the programmer with
"bullet-in-foot" being the result.

Re: "Spam-blocker causes missed court date" (Carroll, RISKS-23.75)

<Joseph Brennan <>>
Sat, 26 Feb 2005 17:40:03 -0500

According to the reporter, the lawyer said that "his firm's spam blocking
software automatically sidetracked the court's e-mail notice" and that "his
law firm's spam-blocker software set the Internet security level too high,
which blocked the e-mail notification from the court. After the security
level was reset, the notification came through."

One would conclude from this that the law firm had unmonitored software that
was throwing away mail willy-nilly.  Or perhaps that the law firm's system
administrator configured it to do so.  Both are serious charges that are
likely to cause fear and doubt among users of email systems.  It is unlikely
that either is true.

I submit to the court that the most likely facts are that the filter sorted
the court notice into a possibly-spam folder and that the lawyer failed to
look at the folder regularly.

The next most likely case is the one I find the most disturbing: that the
law firm's system refused the message (smtp 550) or accepted it and mailed a
bounce notice back.  But if this happened, why would the court issue the
show-cause order?

This is a vital question, because as an email system administrator, I rely
on refusal as a valid way to notify senders that mail was not delivered.  I
expect the sender's system to generate a bounce and I expect the sender to
look at it.  I would be very surprised to be held responsible for failing to
read a message that was properly refused.  The smtp protocol has always
defined the sender system as responsible until the remote side accepts.

By the laws of wishful thinking I assume that the court does not ignore its
bounces, and that the law firm's system does not throw away mail without
notice.  Therefore the court was in error.  Unfortunately the filter
software is not a person under law and cannot file for damages!

Joseph Brennan, Academic Information Systems
Columbia University in the City of New York

Re: UK gets official virus alert site (Leeson, RISKS-23.75)

<Rob Skedgell <>>
Fri, 25 Feb 2005 03:54:34 +0000

> 1. This would be a great site for the Malware Brigade to spoof. I hope
> that it is more secure than most Web Sites.

Sadly, no:

Signing up for email or SMS alerts does not appear to require any
address confirmation, so presumably anyone can sign up anyone else's
email address or mobile phone for alerts. Also, no secure (SSL/TLS)
form is provided for submission.

I am also dubious about the 'ITsafe Word' scheme to protect from spoofing by
the 'Malware Brigade' --
definition: A security feature used on the ITsafe website to help reduce the
risk of someone spoofing our e-mails.

  When you sign up to our e-mail service you are asked to type in an ITsafe
  Word (please keep this clean). This is not a password, so if you forget
  it, it is not the end of the world. You just need to be able to recognise
  it again in the future.

  All e-mails we send to you will use this word in the 'subject' line. In
  e-mail programs this is normally displayed just above the e-mail
  content. You can quickly check that the e-mail has come from us as someone
  else would not know your ITsafe Word.

Until you forward the email, forgetting to remove it (not that it mentions
that people *should* do this on forwarding etc). Or post it to USENET, or...

I wonder if they have heard of S/MIME or PGP signatures?

The problem here is that quite a lot of people will probably receive this as
a forward, all malware would need to do is search mail folders for a
legitimate bulletin (identified from mail headers) with the ITsafe Word in
the subject line and use this to construct a forgery to attach itself to...

ITsafe site URL

Re: Component Architecture (RISKS-23.74 and .75)

Fri, 25 Feb 2005 13:19:42 -0500

Several replies to Paul Robinson's "In the Matter of Component Architecture"
suggest changes to the analogies.

Robinson: "most likely you got out of a bed, got up and took a hot shower in
your indoor bathroom...."  As many replies pointed out, the components may
be applied in new situations: A Linux computer instead of a Windows
computer, or a faster or slower computer where the components may or not
meet real-time requirements.  Another reply told about a bug in the C
library.  There can also be a bug in the operating system or in the
computer's firmware.  Remember how some interrupts wouldn't preserve the BX
register on the original IBM PC?  The firmware may be a component to you but
it's part of the environment to me.  My program is expected to work in
unpredictably buggy environments.  So, add to the analogy: "As you were
doing this, several other people attempted to take a shower with identical
plumbing and heating: an astronaut on the Space Station in zero gravity, a
man on Mars where the low atmospheric pressure made the hot water evaporate
as soon as it left the showerhead, and a cold-adapted inhabitant of Pluto
who found the showerhead couldn't deliver the ice-cube shower he wanted.
"Meanwhile on Earth, a bug in your local laws of nature makes water change
into sulphuric acid if its temperature is between 119.3 and 119.4 degrees F,
so you have to be careful with the temperature setting or risk damage to the
showerhead.  You had some difficulty yesterday when the gravity server
malfunctioned for a few seconds and all the water fell up to the ceiling."

Mark Lutton, Dialog, a Thomson business.

Re: Component Architecture (RISKS-23.75)

<"Steve Taylor" <steve.taylor@PETARDSCS.CO.UK>>
Fri, 25 Feb 2005 11:40:00 -0000

I am surprised that nobody has remarked on the fundamental fallacy in
comparing the "design" of software with the "manufacture" of physical items.
If you want to compare software development with other engineering then you
must understand the economics of design and manufacture in these two
industries.  The software manufacturing process typically involves copying
of the software onto a CD; this is so fundamentally cheap that the practical
cost of software is focused in the design stage.  In physical engineering
the vast majority of products that people encounter have the opposite
relationship - cost is dominated by manufacturing.  This doesn't invalidate
the comparison but it does mean that it has to be made very carefully.
When, for example, a building designer uses of the shelf components do they
do it to make the design process simpler or do they do it because the
construction is cheaper.  All the cases where the decision is made to reduce
construction costs are not applicable for comparison with the software
industry.  In fact software designers may make an opposite choice for
exactly the same reason - in software any standard of the shelf component
may bring manufacturing costs (license fees) whereas a home-grown variety is
free.  I believe this is an important force undermining reuse of components
in software.

I am in the business of producing software with a price limit from tens to
hundreds of UK pounds per license.  If I reuse commercial components with
license fees of 20 pounds each then I very quickly destroy the economic
viability of what I am doing.  In most cases the functionality I am actually
using in a software component that costs 20 pounds can be reproduced for a
lot less than the license fees I expect to pay on predicted sales.  If I
were making physical objects then my custom manufactured component would
probably have higher manufacturing costs than a bought in item rather than
the zero cost that applies in software.

The optimism that typically pervades the software development industry
reinforces this process.  Managers choose in house development because
the initial estimates show it will be cheaper.  If they were a little
more aware of the typical cost overruns, additional maintenance costs
and the like then there would probably be more reuse.

The result of all this is that there is only widespread take up of component
reuse where those components are reliable and free.  The dominant source of
these is the tools built into development environments.  I have been in
software for many years and I remember programming with assemblers and
simple language compilers where at best I got 3 or 4 machine instructions
for each line of code.  These days the number of machine instructions and
the amount of functionality for each line of code has increased
dramatically.  This is unquestionably reuse of components, even if many of
them are very small ones, and everybody uses these tools.

Steve Taylor, Technical Director, AssetCo Data Solutions  0116 2405755

Re: Component Architecture (Risks 23.73)

<Jan Vorbrüggen <>>
Fri, 25 Feb 2005 15:51:11 +0100

During the more than ten years that I worked at an Institute for Neural
Computation as a researcher, I regularly held a lecture series for students
on "neural" and "non-neural" computation, their similarities and
differences.  One important point about "traditional" software that
distinguishes it from physical systems -- and that has been a major part of
my introduction in the lectures -- has been alluded to in this thread most
clearly by Stephen Bull (RISKS 23.74) in saying that "[s]oftware is not
constrained by the laws of nature." Of course, that's not really true;
probably the best analogy would be to say that software is always a
(strongly) chaotic system. To a physicist like me, this means that a small
difference in initial condition -- just a single bit, perhaps -- can introduce
an arbitrary difference in future state in a finite time.

A physical system, for instance, is almost always dampened or low-pass
filtered, to use another way of viewing it, which restricts a change in
local state to a small rate of change; but in a computer system, it is
equally likely for the most- as for the least-significant bit to change when
something breaks (be it due to physical change such as radiation or a
software malfunction). A bug such as a buffer overflow or array bounds
violation can produce a knock-on effect that is unpredictable in its
time-space distance. This means, to get back to Robinson's original post (or
should I say diatribe 8-)?), that the component nature of a software
component cannot (easily) be guaranteed, part of that nature being that
components should only be loosely coupled among each other in a well-defined
way. As a counter-example, you don't expect a scratch on the cabinet in one
corner of your kitchen to lead to a short-circuit of the stove in the
opposite corner, killing the user in the process, while the same kitchen
implemented in software might quite conceivably have a bug that does that to
its virtual (one does hope) user.

Of course, there are physical systems that are chaotic, or where the
component nature and loose coupling among components are not true --
well-known examples might be the Tacoma Narrows bridge or the Columbia
accident.  Such systems still manage to surprise everybody, including the
experts in the field. On the other hand, sometimes a software system --
perhaps modelling a physical system -- can exhibit non-chaotic behaviour in
the face of errors; I particularly like the example given by Richard Feynman
in the first part of his autobiography.

One can clearly derive some recommendations for software development and use
from these deliberations, a lot of which have been well-known for a long
time. One of the not-so-obvious ones might be taken from looking at "neural"
computation, to get back to the introduction: and that is to try to design
algorithms that are tolerant of errors, both in their data as in the details
of their implementation. That, of course, isn't easy, and I think it likely
that it isn't applicable in all too many cases; but if you have a choice,
select the algorithm that is perhaps slower or otherwise "worse", but that
is more tolerant of errors.

Re: Component Architecture (D.Smith, RISKS-23.75)

<"Olivier Dagenais" <olivierS_dagenaisP@canadaA.comM>>
Thu, 24 Feb 2005 20:01:54 -0500

> strcmp is one of the most simple, basic, fully-documented, and
> frequently-used "components" there is.  strcmp isn't an interchangeable
> part.

Your own story seems to tell us otherwise: because strcmp was "simple, basic
and fully-documented", you were able to write a compatible replacement that
traded off efficiency for reliability. (as your own unit tests have shown)
Your story was a little vague on the details of switching all uses of strcmp
to "smithcmp", but I presume the "fully-documented" part meant you were able
to write an interface-compatible method that meant a simple string replace
could be used on your source code to switch to the new implementation.

It would thus appear that if one can get "full documentation" on "simple and
basic" software components and write [unit] tests proving equivalent
behaviour, interchangeability is indeed possible.

Re: Component Architecture: strcmp (D.Smith, RISKS-23.75)

<"Paul D.Smith" <>>
Fri, 25 Feb 2005 09:04:07 -0000

Daniel Smith gave a great example of the problems of reusable software.
Clearly the bug in strcmp should have been fixed in the library.  A single
fix, well tested, would have filtered out to all the other products based on
this reusable code.

Better still, the odds on this nasty bug being identified were greatly
increased because the code was used by many applications, in many different
ways.  Single usage code has a nasty history of bugs that are spotted so
rarely that the cause and fix may never be identified.

But this falls down if nobody is making money maintaining strcmp. Good-will
goes only so far.  Thorough design, testing and maintenance costs and
someone has to pay.  But development teams often fail to correctly compare
hidden "do-it-yourself" costs against direct "buy-it-in" costs.  So if you
want quality, resuable software with timely fixes, get ready to pay.  It
doesn't have to be "through the nose", but it does need to be a reasonable

Re: Component Architecture (Kuenning, RISKS-23.74)

<Steven Hauser <>>
Mon, 28 Feb 2005 11:23:00 -0600 (CST)

Software patents make component reuse dead.

Reuse a bunch of stuff and pay many fees, royalties, patent searches,
lawyers and contract negotiations. So who will try reusing components with
very real legal, financial, etc. risks when the risk of consequence for a
bug (even resulting in deaths or huge financial losses,) is small?

Steven Hauser

  [That of course is precisely one of the main arguments for
  open-source/free software.  PGN]

Re: Component Architecture (Ladkin, RISKS-23.75)

< (Dimitri Maziuk)>
Thu, 24 Feb 2005 19:52:42 -0600

In comp.risks, "Peter B. Ladkin" <> wrote:

> I was surprised to find little of the extensive commentary on Robinson's
> essay directed at his premise. (Stephen Bull and George Jansen addressed the
> premise en passant.)
> The premise is obviously false, as  ... most software development ...
> is directed towards modifying already existing software ...

Yes, but that's not entirely the same thing as OO dream of everybody
assembling applications from ready-made components while everybody else is
getting rich selling libraries of said components.

Yes, larger businesses use custom software built from SAP or Oracle
components. At the same time, smaller businesses use lowest common
denominator off-the-shelf software that doesn't quite do what they want, but
it's "close enough" and is something they can actually afford (speaking from

Of course we reuse code. We reuse entire applications all the time -- nobody
writes their own webserver when they can simply install Apache. When it
comes to re-using components I prefer to re-use source code. Because
cheap-not-quite-right off-the-shelf component is as useless to me as an
overpriced custom component written to my specs which I know are going to
change as soon as the users see the final product.

We reuse code a lot. But that's not the same thing as building new systems
out of preexisting OO components. That dream's been exciting a few decades
ago but by now it's like that crazy uncle living in the attic: nobody talks
about it anymore. Anybody can list at least half a dozen reasons off the top
of their head why it doesn't work. As the comments clearly show.

So I was rather surprised to see Robinson's essay published: not only the
idea is out of date, the analogies are all flawed.  I'm sure anyone who's
ever renovated more than one kitchen or fixed more than one car knows
exactly what's wrong with those analogies. (As the comments clearly show.)
Not to mention that reasons why Sears would rather replace an $5 item no
questions asked and have the customer come back for more don't have that
much to do with warranty on the item.

Re: Component Architecture

<"Bill Royds" <>>
Thu, 24 Feb 2005 22:26:26 -0500

In one interesting way, the problem with present software is not lack of
components but use of them without adaptation. In modern software exactly
the same program is sold to every user. In the Microsoft world, the install
procedure hardly ever ask the users for intended uses of the software, level
of knowledge of the subject etc. when installing. One size fits all is the
norm for software and the standard executable is given to millions of users,
completely ignoring any variances in knowledge, ability, interest or
configuration.  This is one reason why bugs in this software are so
devastating. A problem in a component, such as the RPC bug that lead to
Blaster, causes a problem with all systems built with that software.  It is
not the lack of component based development that is the problem, but the
complete dependence on components that are used in places where they have
not been fully tested.

Re: Component Architecture

<Tom Swiss <>>
Fri, 25 Feb 2005 11:58:29 -0500

If RISKS can bear one more comment on Paul Robinson's component architecture

In my experience, one reason why the decision to build new software rather
than use third-party components is one of control. Robinson mentions that
"nobody in their right mind would expect [a trucking company] to build their
own trucks"; but if the alternative was to buy trucks with the hoods welded
shut, and rely on a locked-in (and historically unresponsive) vendor for
repair and maintenance of your business's critical infrastructure, that
might just be an attractive option.

Fortunately, Free Software ("free as in freedom, not as in price") provides
us with the ability to obtain components that we can fix (or hire experts to
fix) if they break. Jay R. Ashworth's response notes CPAN and PEAR as
examples of reusable components; I think we need to emphasize that these are
not just reusable but are software libre.

Re: Component Architecture (Bell, RISKS-23.75)

<Ross Lonstein <>>
Fri, 25 Feb 2005 10:31:41 -0500

Whitworth is equally good as an example of a failed attempt at
standardization. By the 1900s it was just one British "standard" with the
British Standard Fine (BSF), the British Association (BA) thread (metric
measured in imperial units) and the Cycle Engineers Institute (CEI)
threading in use.

It is ironic that WWII forced the British Army to largely abandon
Whitworth's standard and adopt the American standard (actually two: National
Coarse and National Fine) which has threads that are easier to make (60
degree thread pitch, single cut process with flat roots and crests vs. 55
degree thread pitch, multiple cut process, varying threads per inch by
diameter, rounded roots and crests) and more reliable.

Metric, by the way, uses a 60 degree pitch and designates fasteners by their
nominal diameter and thread pitch, both measured in millimeters.

Software doesn't seem to be doing any worse with regard to standardization
than did mechanical engineering.

Re: Component Architecture (Ellims, RISKS-23.75)

<"Dave Budd" <>>
Mon, 28 Feb 2005 09:56:16 -0000

> "Mechanical engineering has it's standard components, nuts, bolts, screws,
>  nails etc. Just as we have some as well, languages, editors, protocols
>  etc." lists 33 separate major categories of screws, many
divided into sub-categories, and then there are the individual sizes...
It's similar for other components, and this is after over a century of
mechanised production.  I know I never seem to have quite the right item
ready in stock for whichever DIY job I'm wanting to do.

So, the kitchen-fitting analogy holds quite well - the whole thing's a mess.

Re: Component Architecture (Mathur, RISKS-23.75)

<Geoff Kuenning <>>
25 Feb 2005 16:36:23 +0100

Raj Mathur spotted a bug in my simple pipe.  I was hoping somebody would
notice that bug!  I spotted it only when the digest came out and I (vanity
of vanities) reread my posting.  Actually, I'd suggest and even better and
simpler fix:

   ls -l | grep  '^-' | awk '{total+=$5}END{print total}'

which protects against new future file types.

But I think that my original error nicely (if unintentionally) makes the
point that plugging components together isn't a cure-all.  -- Geoff Kuenning

  [The identical fix was also noted by Dave Horsfall.  PGN]

Re: Component Architecture (Kuenning, RISKS-23.74)

<Dan Jacobson <>>
Tue, 01 Mar 2005 03:10:49 +0800

  ls -l | awk '!/^[bcdps]/{total+=$5}END{print total}'
and with perl, one doesn't even need the ls...

Please report problems with the web pages to the maintainer