The RISKS Digest
Volume 24 Issue 57

Wednesday, 21st February 2007

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…


Govt Health IT: Electronic prescribing is no panacea
Deborah Peel
DNS roots attacked
AACS: A Tale of Three Keys, by J. Alex Halderman
via Monty Solomon
Amazing boilerplate text in Fairfax County e-mail
Gabe Goldberg
Crashing an in-flight entertainment system
Steve Summit
Infrastructure risks: pump-station alarm
Carmakers copy and repeat error almost forever
Doug McIlroy
Two war stories from the NASA trenches
Ron Garret
US government's contracts tracked by contractors
Ken Knowlton
Study Finds Security Flaws on Web Sites of Major Banks
Gabe Goldberg
Web Site Wants JPEG of Government ID
Mike Conley
Re: Math libraries
Peter B. Ladkin
Re: Excel Date Bug
John Levine
Impact of DST changes on BlackBerry device users
Monty Solomon
Re: Digital cameras converted to weapons
Leonard Finegold
Re: Canadian coins containing tiny transmitters
Adam Abrams
New Short Video: "Is Your Cell Phone Bugged?"
Lauren Weinstein
REVIEW: "Code Quality: The Open Source Perspective", Diomidis Spinellis
Rob Slade
Info on RISKS (comp.risks)

Govt Health IT: Electronic prescribing is no panacea

<"Dr. Deborah Peel" <>>
Sun, 18 Feb 2007 00:27:48 -0600

You should know about this massive violation of the privacy of every
American who takes medication.

This opinion piece is about the fact that there is no such thing as a
private prescription in the nation. Identifiable prescription data is sold
to insurers for medical underwriting and to large employers to use as they
see fit (discrimination?).

Electronic prescribing is no panacea
By Dr. Deborah Peel, Saturday, February 17, 2007

When a coalition of technology companies, insurers and health care providers
launched a $100 million project last month to provide free electronic
prescribing software to every physician in the United States, it was greeted
with cheers. The presence of brand name vendors was supposed to ensure that
sensitive prescription records would be private and secure.

But those who believe there is anything private about e-prescribing under
the National ePrescribing Patient Safety Initiative (NEPSI) - or any other
e-prescription system - are simply incorrect.

Security makes little difference because every identifiable prescription in
the country is data mined and sold daily. Nobody needs to break into
pharmacies to steal our prescriptions; they are for sale. For example,
market intelligence firm IMS Health reported revenues of $1.75 billion in
2005 solely from the sale of prescription records, primarily to drug

Privacy is the right to control who sees your sensitive health records and
the right to decide if those records are even entered into electronic
systems. But it is impossible for anyone to have a private prescription -
meaning that it is never disclosed without a patient's consent - because
data mining has eliminated that right.

Furthermore, many people refuse to take psychiatric medication or other
medications in an attempt to prevent the pharmacy benefits management
industry from reporting to employers that they are on antidepressants or
other medications.

Knowing that prescriptions are not private also keeps people with other
sensitive illnesses from taking medications. And that exerts pressure on
doctors to avoid prescribing pain medications - out of concern that the
Drug Enforcement Administration is tracking their prescribing patterns.
The lack of prescription privacy is a problem that endangers people's
lives and quality of life.

That brings us to more misinformation about e-prescribing: that it is a
panacea for preventing prescription errors. Pharmacies have been
converting handwritten prescriptions into electronic prescriptions for
more than a decade, so software that catches errors and drug
interactions could have been used before with electronic prescription
data. Doctors don't need to issue e-prescriptions to reap the benefits
of software that checks for correct doses and a drug's conflicts with
other medications.

In the rush to extol the benefits of e-prescribing, NEPSI also neglects
to mention that e-prescribing will introduce new sources of error. It
could produce about the same rate of errors as written prescriptions.

With written prescriptions, two licensed professionals - the physician
and the pharmacist - look at the prescription. Two experienced humans
are paying attention. If there are any questions, the pharmacist calls
the doctor. With e-prescribing, only one human will look at the
e-prescription, the doctor. Indeed, e-prescribing may make errors more
common than when doctors write prescriptions.

Most people do not know that they cannot keep prescription records
private - it's a huge area of ignorance. Now that we are moving rapidly
into an e-health system, we need to build it right. Congress should
follow the lead of New Hampshire, which passed a law in 2006 to stop
illegal and unethical prescription data mining.

We need all the benefits that health information technology can bring,
but we also need privacy. Technology can provide both - we should never
have to choose between our privacy and our health.

Peel is a physician and chairwoman of the Patient Privacy Rights
Foundation based in Austin, Texas.

DNS roots attacked

<"Peter G. Neumann" <>>
Tue, 6 Feb 2007 17:19:19 PST

Hackers briefly overwhelmed at least three of the 13 computers that help
manage global computer traffic Tuesday in one of the most significant
attacks against the Internet since 2002.  Experts said the unusually
powerful attacks lasted for hours but passed largely unnoticed by most
computer users, a testament to the resiliency of the Internet.  Much rogue
data was traced to South Korea.  UltraDNS was a particular target.  Attacks
passed largely unnoticed by most computer users.  [Source: AP item, 6 Feb
2007, PGN-ed; Thanks to Lauren Weinstein.]

  [See RISKS-22.32 for the attacks that crippled 9 of the 13 root servers in
  Oct 2002.  Perhaps the Internet is somewhat more robust now?  PGN]

AACS: A Tale of Three Keys, by J. Alex Halderman (Re: RISKS-24.55)

<Monty Solomon <>>
Sat, 17 Feb 2007 11:35:21 -0500

This week brings further developments in the gradual meltdown of AACS (the
encryption scheme used for HD-DVD and Blu-Ray discs). Last Sunday, a member
of the Doom9 forum, writing under the pseudonym Arnezami, managed to extract
a "processing key" from an HD-DVD player application. Arnezami says that
this processing key can be used to decrypt all existing HD-DVD and Blu-Ray
discs. Though currently this attack is more powerful than previous breaks,
which focused on a different kind of key, its usefulness will probably
diminish as AACS implementers adapt.

To explain what's at stake, we need to describe a few more details about the
way AACS manages keys. Recall that AACS player applications and devices are
assigned secret device keys. Devices can use these keys to calculate a much
larger set of keys called processing keys.  Each AACS movie is encrypted
with a unique title key, and several copies of the title key, encrypted with
different processing keys, are stored on the disc. To play a disc, a device
figures out which of the encrypted title keys it has the ability to
decrypt. Then it uses its device keys to compute the necessary processing
key, uses the processing key to decrypt the title key, and uses the title
key to extract the content.  ...

Amazing boilerplate text in Fairfax County e-mail received today

<Gabe Goldberg <>>
Mon, 05 Feb 2007 17:20:04 -0500

The following hard-to-believe text speaks for itself. Fairfax County (VA)
prides itself on being techno-savvy, on the cutting edge of the new economy,
and other similar blather. Looks like the "cutting edge" is severing Fairfax
from the Internet. Being offline would be bad enough, but bouncing e-mail?
For three or four days? Amazing. I wonder how many people won't know in
advance and will be baffled/frustrated/angered/outraged?

  *** Fairfax County information technology services will be unavailable
  beginning February 17 and resume on February 20.  My account will be
  inaccessible during this timeframe and any incoming e-mail will be bounced
  to the sender.  In effect, Fairfax County will temporarily cease to exist
  online for this period.  We apologize for the inconvenience.***

Crashing an in-flight entertainment system

<Steve Summit <>>
Wed, 21 Feb 2007 00:16:08 -0500

Hugh Thompson reports that he was able to get an airplane's in-flight
entertainment system into a significantly unexpected state, by (a) using a
numeric keypad, rather than the normal up/down buttons, to enter a value one
higher than a Tetris game's preference was intended to allow, then (b) using
the normal "up" button to increment the value still further — evidently the
programmer had implemented "if(value == 4) {don't increment}" rather than
the more robust "if(value >= 4)".  When he incremented the value past 127,
not only his screen, but every seat-back screen on the whole plane went
black, until a flight attendant reset the system.  Further details at [with some subsequent discussion].

Infrastructure risks: pump-station alarm

Tuesday, 5 Feb 2007 13:55:00 -0500 (EST)

A tree-trimming contractor clearing power lines cut a phone line which
serviced a pump-station alarm.  The alarm is supposed to be checked twice
daily, but the pump was out of commission for four days, leading to a
massive sewage spill.

The risks are clear; multiple single points of failure (the alarm, the phone
line, the pump station, the human verification), no method to check for a
failure of the alarm, and a possible flaw in the human logging / reporting
side of things.

Carmakers copy and repeat error almost forever

<Doug McIlroy <>>
Sun, 18 Feb 2007 14:25:50 -0500

RISKS-16.3, 5 May 1994, contained an account of the shock of being locked
out automatically after closing the door on a stopped car with the engine
running.  (Not unlikely if you get out to check the roof rack, fetch the
mail, etc.)  The problem was reported for a Chevvy; I met it years later in
a 2001 Ford Focus.  Poking around the web, I find reports of the same
trouble in car models as recent as 2006 from various makers.  Disheartening
that such a trivially fixable misfeature should be imitated so widely and
persist so long.

Two war stories from the NASA trenches

<Ron Garret>
Wed, 7 Feb 2007 23:55:32 -0800

One of my favorite case studies is getting a bit long in the tooth, but it
has never to my knowledge been cited or discussed in RISKS, so from the
better-late-than-never department I give you:

This is the story of the NASA Deep Space 1 Remote Agent Experiment (RAX),
and a bug that appeared in the RAX executive despite a then-
state-of-the-art effort to develop fault-free software.  The approach was
very much like the "software-IC" approach that has been advocated off and on
for decades (I remember first hearing about it when I was a grad student,
and a 5MB hard drive was considered a lot of storage).  To summarize and
radically oversimplify, a "substrate" layer was developed and exhaustively
analyzed using formal methods to insure that it maintained certain
invariants (like being deadlock- free).  Application code was then developed
on top of this exhaustively analyzed substrate, in effect "wiring together"
the supposedly reliable components.

To make a very long story much too short, one of the applications
programmers inadvertently undermined the invariants that were supposed to be
guaranteed by the substrate when he needed a feature that the substrate
didn't provide.  Instead of requesting that the feature be added to the
substrate, he just "rolled his own" (it was only two lines of code), and
thereby undermined the guarantees that the substrate provided.  The
resulting bug was never detected during extensive ground testing, but
nonetheless failed in flight.

It was quite a humbling experience, and it makes a worthwhile read even

As long as I'm telling war stories, I'll offer up a second one which was
never published.  This happened in 1989.

We were developing code for autonomous mobile robots (what was to eventually
become the Mars Pathfinder mission) using a dialect of Lisp called T.  We
had ported the T compiler from a Sun3 to a Heurikon 680x0 board running
vxWorks.  We found that when the robot moved its arm the Lisp process would
crash intermittently.  Forensic analysis after the crash revealed a
completely and nondeterministically corrupted heap.

This was the probably the most challenging bug I've ever encountered in my
career because it was impossible to reliably reproduce, and when it happened
it obliterated everything that might provide a clue as to why it happened.
Another long story short (it took us over a year to figure it out) the
problem turned out to be a bug in the T compiler: in the code emitted to
return from a function, the stack pointer was adjusted while they were still
live vales on the stack.  On the Sun this was not a problem because user
processes ran in a different address space from the kernel.  But under
vxWorks interrupt handlers used the same stack as the process being
interrupted.  So when an interrupt happened right in between those two
instructions the unprotected value on the stack was obliterated by the
interrupt handler code, resulting in a gradual corruption of the heap.

The moral of the story is that even code that tests perfectly under formal
analysis and/or extensive use may yet contain latent bugs.

US government's contracts tracked by contractors

<Ken Knowlton <>>
Mon, 5 Feb 2007 18:09:32 EST

(From AOL's NY Times news section, pertinent to "RISKS" for several reasons.
Complete article:

Contractors still build ships and satellites, but they also collect income
taxes and work up agency budgets, fly pilotless spy aircraft and take the
minutes at policy meetings on the war. They sit next to federal employees at
nearly every agency; far more people work under contracts than are directly
employed by the government. Even the government;s online database for
tracking contracts, the Federal Procurement Data System, has been outsourced
(and is famously difficult to use).

Study Finds Security Flaws on Web Sites of Major Banks

<Gabe Goldberg <>>
Mon, 05 Feb 2007 09:02:02 -0500

Internet security experts have long known that simple passwords do not fully
defend online bank accounts from determined fraud artists. Now a study
suggests that a popular secondary security measure provides little
additional protection.  [Source: Brad Stone, *The New York Times*, 5 Feb

Web Site Wants JPEG of Government ID

<Mike Conley <>>
Sun, 18 Feb 2007 12:17:45 +0000

I recently visited a Web site, <>, which provides
low-cost downloads of photographic images submitted by registered
users. It's actually quite nice, and rather professional-looking, and I was
interested in uploading some of my photos and perhaps making a few dollars
on them.

I discovered while registering that, in order to upload images, one has to
establish an upload account, a requirement for which is the submission, over
the Internet, of a scanned JPEG image of a government-issued identity
document, such as a driver's licence or — even better — a passport.

Further comment doesn't really seem necessary.

Re: Math libraries (Robinson, R 24 54, Karpinski, R 24 56)

<"Peter B. Ladkin" <>>
Mon, 05 Feb 2007 09:03:49 +0100

Dick Karpinski suggests in RISKS-24.46 that Paul Robinson's worries about
the hardware math functions in the 586 class of processors are not as well
founded as his worries about software math functions. I concur. Dick could
have told more of the history.

William Kahan at U.C. Berkeley has been worrying about floating point
calculations in computers for the last four decades and won the Turing
Award, the highest award for technical contributions to computing science,
in 1989 for these efforts. Intel was interested in defining portable
accurate floating point computations, in advance of their introduction of
the math coprocessor for the i8086/8 series (i.e., what was to become the
8087). Impressed by Kahan's understanding of the problems as well as his
efforts on behalf of Hewlett Packard, Intel engaged him to help further this
cause. Kahan worked with a PhD student of his, Jerry Coonen, and Harold
Stone, to define a proposal for the IEEE p754 committee which became in
large part the IEEE 754 standard. One can read more about it in some notes,
for an IEEE Computing article in 1998, on Kahan's WWW site at

I was the Teaching Assistant for the graduate numerics course in the Math
Department at UCB at the time that Jerry took it. Assessing the assignments
was a breeze. One first looked at Jerry's solutions and those of Jamie
Sethian (now himself a math professor at U.C. Berkeley) to see how to do it
right. (Those are the advantages of graduate teaching-assisting at a place
such as U.C. Berkeley. You can always assume that there is at least one
student who is better than yourself, and sometimes more.) Jerry finished his
PhD, on the FP work, waaay before I finished mine. I remember him telling me
that the way to be certain of a good job was to become acquainted with every
line of the BSD source code. Those were the days.  But even in those days it
was expanding faster than one could read it (besides, that was not the right
way to get a PhD in Logic and the Methodology of Science, for probably more
than one reason :-).

To my mind, IEEE 754 is one of the success stories in our efforts to reduce
mistakes in computing. It is a pity certain spreadsheet programmers didn't
emulate its example.

Peter B. Ladkin, Causalis Limited and University of Bielefeld

Re: Excel Date Bug (Winter, RISKS-24.56)

<John Levine <>>
5 Feb 2007 01:16:58 -0000

> The most obvious solution would be to decrement the day numbers before 1
> Mar 1900, effectively setting the epoch one day later...

That's what Open Office does.  Dates in 1-2-3 and most spreadsheets are
internally represented as integers with 1-Jan-1900 as day 1.  In Open
Office, day 1 is 31-Dec-1899, so dates before 1-Mar-1900 are off by one day.

This does not necessarily improve the situation.  In spreadsheets I've seen,
it's quite common to enter dates simply as dates, to mark when something
happened, less common to do date arithmetic, and I've never seen anyone
doing date arithmetic as far back as 1900.  So this change fixes the date
arithmetic, at the cost of making dates before March 1900 display wrong.

I am not a big fan of Microsoft, but in this case I have to agree with them
that there's no change to this bug that will make the situation better than
it is now.  They clearly did think about this change, and rejected it for
sensible reasons.

John Levine,,

Impact of DST changes on BlackBerry device users

<Monty Solomon <>>
Mon, 19 Feb 2007 20:05:57 -0500

Impact of North American Daylight Saving Time changes in 2007 on BlackBerry
device users:

Re: Digital cameras converted to weapons (R 24 54,56)

<Leonard Finegold <>>
Sun, 4 Feb 2007 18:43:21 -0500

Everyone is right:

At $13.99 this "Digital" camera looks suspiciously like CVC's ye olde
chemical-type cameras of about the same price.  I strongly suspect that what
CVC calls "Digital" on the box (note they say "Simple Digital Processing")
is what we mortals would call non-digital.

'The question is,' said Alice, 'whether you can make words mean so many
different things.'  Alice in Wonderland, CL Dodgson

Leonard X. Finegold, Physics, Drexel University, Philadelphia PA 19104 USA  Phone 215.895.2740

Re: Canadian coins containing tiny transmitters

<Adam Abrams <>>
Sun, 04 Feb 2007 21:32:24 -0800

There was a followup story in which the Defense Department reversed
themselves.  There were no transmitters.

I think some American contractors just thought the Canadian coins (probably
the thick two-dollar coin which has a gold inner part and a silver outer
part) looked funny and a wild idea became a rumour, which became a "reported

With field intelligence like that, the "war on terror" will be won any day
now, I'm sure...

Adam Abrams (604) 685-7634

New Short Video: "Is Your Cell Phone Bugged?"

<Lauren Weinstein <>>
Fri, 16 Feb 2007 21:13:01 -0800

Greetings.  I've been getting lots of continuing interest and queries in the
wake of my blog item from late last year: "How To Tell If Your Cell Phone Is
Bugged" ( ).

In an effort to explain this issue in a more demonstrative and somewhat less
technical manner, I'm pleased to announce a short free video (under six
minutes): "Is Your Cell Phone Bugged?"

While I'll admit that the production values are much closer to those of Ed
Wood than of Cecil B. DeMille, I hope you'll still find this video to be
interesting, or at least amusing.

"Is Your Cell Phone Bugged?" Video Access Pages:

  YouTube (Streaming):

  Google Video (Streaming & Download):

Lauren Weinstein +1-818-225-2800 or

REVIEW: "Code Quality: The Open Source Perspective", Spinellis

<Rob Slade <>>
Tue, 20 Feb 2007 10:40:40 -0800

BKCQTOSP.RVW   20061229

"Code Quality: The Open Source Perspective", Diomidis Spinellis, 2006,
0-321-16607-8, U$54.99/C$73.99
%A   Diomidis Spinellis
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-16607-8
%I   Addison-Wesley Publishing Co.
%O   U$54.99/C$73.99 416-447-5101 800-822-6339
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   569 p.
%T   "Code Quality: The Open Source Perspective"

The preface points out that it is easy to test for the functional
requirements of an application: either the program performs the function or
it doesn't.  Nonfunctional requirements (including such characteristics as
reliability, portability, usability, interoperability, adaptability,
dependability, and maintainability) are much harder to assess, and yet may
be more important.  (In an automated train system, for example, the lack of
a function to change the schedule from within a given train still allows you
to use the train within a given schedule.  Unreliability of the braking
system means the system is worse than useless.)  In addition, "Code Reading"
(the title of Spinellis' previous book) is pointed out as the most common
activity for developers, and yet is a skill seldom taught in the programming
curriculum.  The author has avoided using fictional code for the examples in
this (and the prior) work by providing sample code from open source software
projects, thus using working (but available) source code for illustrations.

Chapter one introduces the structure of the text by mapping characteristics
from the ISO 9126 quality standard to the chapters and sections of the book.
Inherent conflicts between different aspects of quality are also noted.
(For example, large numbers of discrete operations enhance the functionality
of a system, but at some cost in terms of usability.)  Reliability is
examined, in chapter two, in terms of common flaws.  Examples of such flaws
are given, followed by an explanation of the specifics of the problem.  This
is followed by samples of code that address the problem stated.  Each point
and section is accompanied by questions and discussion points that could be
used in a course teaching the issues of code quality.  (Unlike all too many
sets of questions these are rigorous and challenging.  Sometimes they may be
a little bit too demanding: occasionally the discussion would require
intimate knowledge of the internals of a specific programming language.)
The chapter ends with a summary of the points and factors covered.

Various security vulnerabilities and coding points are illustrated in
chapter three, but, in comparison to the rest of the work, this material is
weak and disappointing.  Performance issues in relation to time are reviewed
in chapter four, and to space in five.  The different factors of latency and
bandwidth, and the trade-offs between memory and speed are noted.  It is
rather odd that Spinellis is at pains to point out that time efficiencies
negatively affect simplicity and portability, while he goes to great lengths
to provide suggestions for space optimizations for a variety of specific
architectures (which wouldn't help portability either).

Chapter six looks at a number of factors relating to portability, between
both hardware and operating system platforms.  Maintainability is the
longest chapter (seven) in the book, and bears the closest relation to
Spinellis' previous work on "Code Reading."  There is a special section on
the characteristics of object-oriented code.  Chapter eight, on floating
point arithmetic, notes the sometimes surprising sources of inaccuracy.

In the information technology and development fields we are constantly
obsessed with production of code and the speedy release of the next version.
We need to stop and take a good look at the quality of what we produce: as
it frequently stated, the greatest source of computer problems is computer
solutions.  In regard to security, it is demonstrably true that the exploits
and difficulties that we find are those that would never have been created
if only programmers had paid a little more attention to the fundamental
concepts they were first taught.  I believe Spinellis' text should be
required reading for all programming courses and programs.  In addition,
those involved with analysis, maintenance, and change control should
consider it a bible to be read and re-read until the lessons are firmly

copyright Robert M. Slade, 2007   BKCQTOSP.RVW   20061229

Please report problems with the web pages to the maintainer