The RISKS Digest
Volume 23 Issue 71

Saturday, 12th February 2005

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…


Australian Frigate reversed onto rocks by computer override
Anton Lak
More uses of satnav/GPS
David Magda
Urology medical student residency "matching" process failure
Daniel Kahn Gillmor
Congressman Ron Paul R-TX Understands Risks and Countermeasures
Larry Sudduth
Flexibility destroys identity uniqueness: Implementing of IDN
Jon Lingard
Exploding cell phone shocks 911 dispatcher
Keith A Rhodes
RFID Tagging Elementary School Children
Peter H. Coffin
The risk of high-speed CD/DVD-rom drives in current-day PCs
Henk Langeveld
You type Zuerich and I type Zurich... A brief note
David G. Bell
Another MS Word info leak
Richard Akerman
High Risk Vulnerabilities in Eudora for Windows
NGSSoftware via Monty Solomon
Re: U of Calgary adding spam and spyware
Matthew Holmes
Re: Food via inkjet printer
Brian Reynolds
Minireview: Bill Neugent, No Outward Sign
REVIEW: "A History of Computing Technology", Michael R. Williams
Rob Slade
Info on RISKS (comp.risks)

Australian Frigate reversed onto rocks by computer override

Thu, 10 Feb 2005 11:17:02 +1100

Computer overrides the crew and reverses the Frigate onto rocks, a classic
risk of such automation.,10117,12204297-26618,00.html

Frigate on the rocks, By Ian McPhedran, 10 Feb 2005

The [Royal Australian] navy's newest $500 million warship was driven
backwards on to Christmas Island after crew error caused computers to take
control of the frigate.  A series of errors prompted the computer system to
over-ride manual commands and the ship's company had to stand by and watch
as HMAS Ballarat backed on to the rocky shoreline.  The 3600-tonne high-tech
Anzac class frigate, delivered last April, carries a missile-armed
helicopter and has a 127mm gun, torpedoes and missiles.

The 22 Jan incident damaged both propellers and the rudder and left
taxpayers with a bill of about $2 million and the navy with a major
headache.  The debacle began when the ship was conducting a boat transfer
during a planned U-turn manoeuvre.  It was operating in "port echo" or
economy mode at the time.

*The Daily Telegraph* has been told the move was supposed to take the
warship inside a buoy which had another ship's mooring line attached to it.
As the ship approached the buoy it became clear to the crew on the bridge
that it would not make it and would pass over the line, so they attempted to
make an urgent "three-point" turn.  This was when things started to go
seriously wrong.

Because the ship had only one of its three engines running, the crew tried
and failed to run one propeller forward and one astern to conduct the
radical turn. Such a move is impossible with just one engine running.  At
this point the control system froze, the ship's computer took over and
placed both propellers into reverse.  It shut down the engine soon
afterwards, but by that stage the ship was travelling in reverse at a couple
of knots.

  [Essentially the same article, with *The Daily Telegraph* replaced with
  *The Courier-Mail* (Brisbane) was submitted by David Tombs.  PGN],5936,12199057%255E953,00.html

More uses of satnav/GPS

<David Magda <>>
Sat, 12 Feb 2005 10:05:15 -0500

BBC news is reporting [1] that British Rail is thinking of use sat-nav / GPS
to help keep trains running on time.

I hope they realize that GPS may be shut off by the US government during
emergencies or terrorist acts (see RISKS 23.62). Hopefully someone will at
least think about using Galileo [2] as a back up, or even better, use
inertial guidance [3] as the primary system with satellite navigation as the
backup system.

The same concerns are applicable to any transportation system (e.g., cars,
boats, airplanes).


Urology medical student residency "matching" process failure

<Daniel Kahn Gillmor <>>
Tue, 1 Feb 2005 01:52:43 -0500


  Medical students don't just apply for residency positions at graduation --
  they "match" into them. The students rank their favorite programs, the
  hospitals rank their favorite students, and everyone hopes for the best as
  an algorithm puts them together. This process, more or less unchanged for
  decades, across many specialties, went terribly wrong last week during the
  urology match ...

Basically, they had to run the match again (with different outcomes) a few
days after announcing the first results.  This is huge in the lives of the
prospective doctors because a residency determines where you will live and
what you will do for many years.

According to the discussion boards, the AUA (American Urology Association?)
has blamed the mismatch on a misconfigured computer algorithm, which was
only discovered because some top-ranked residency programs were unfilled,
which supposedly never happens.

So, why wasn't a human reviewing the results of the match for reasonableness
before publication?  Why aren't the algorithms used in the match process
freely available?  What safeguards are there on the data-entry step (since
GIGO continues to apply)?  Why isn't there an audit process in place?

  [It could have been worse.  Suppose someone was matched who was reportedly
  an expert in Eurology (e.g., an economist in Brussels)...  PGN]

Congressman Ron Paul R-TX Understands Risks and Countermeasures

<Larry Sudduth <>>
Thu, 10 Feb 2005 18:42:33 -0500

As early as RISKS-6.73, consequences of automated sharing of driver license
information have been discussed.  While the appropriateness of
countermeasures levied against risks has been a fundamental element of
RISKS since its inception, the mention in RISKS-2.20 of Mann's article
( marked the beginning of a
(still nascent) popular tendency to review countermeasures for
appropriateness, all the more so since the Patriot Act and successors.

I'm happy to learn that at least one congressman, Dr. Ron Paul, (R) TX, gets
it.  I'm unhappy that it is not one of my congressmen — I'm from Virginia
-- but maybe mine will learn from their Texas colleague!

H.R. 418, the "Immigrants ID bill" or "REAL ID Act of 2005," is advertised
in part as establishing and rapidly implementing "regulations for State
driver's license and identification document security standards, to prevent
terrorists from abusing the asylum laws of the United States, to unify
terrorism-related grounds for inadmissibility and removal."  (See

The Honorable Dr. Paul characterizes HR 418 as a National ID Card bill
masquerading as immigration reform.  The clarity and brevity of his comments
merit reading, both from an infosec perspective as well as a countermeasures
perspective (,
excerpted and LMS-ed below:

  " ...this bill will do very little to make us more secure. It will not
  address our real vulnerabilities. It will, however, make us much less
  free. In reality, this bill is a Trojan horse. It pretends to offer
  desperately needed border control in order to stampede Americans into
  sacrificing what is uniquely American: our constitutionally protected

  "This bill establishes a massive, centrally-coordinated database of highly
  personal information about American citizens: at a minimum their name,
  date of birth, place of residence, Social Security number, and physical
  and possibly other characteristics ... that will be shared with Canada and

  "This legislation gives authority to the Secretary of Homeland Security to
  expand required information on drivers' licenses, potentially including
  such biometric information as retina scans, finger prints, DNA
  information, and even Radio Frequency Identification (RFID) radio tracking

  "There are no limits on what happens to the database of sensitive
  information on Americans once it leaves the United States for Canada and
  Mexico - or perhaps other countries. Who is to stop a corrupt foreign
  government official from selling or giving this information to human
  traffickers or even terrorists? Will this uncertainty make us feel safer?"

Security practitioners know better than most the aptness of the saying, "err
in haste, repent at leisure."  I hope Representative Paul's common-sense
proves to be contagious before HR 418 comes to a floor-vote.

Larry Sudduth  703.845-5-eight-33

Flexibility destroys identity uniqueness: Implementing of IDN

<Jon Lingard <>>
Thu, 10 Feb 2005 05:39:23 +0000

It is now possible to spoof the URL displayed in the address bar, SSL
certificate, and status bar of a browser, due to the increased flexibility
brought about by the IDN (International Domain Name) implementation, which
allows using international characters in domain names.  This can be
exploited by registering domain names with international characters that
resemble commonly used characters.

See security details here:

  [This is another old topic in RISKS, but as Jon points out, it is
  now even easier to fool more people.  For example, see
    Evgeniy Gabrilovich and Alex Gontmakher, The Homograph Attack,
    *Communications of the ACM*, vol 45, no 2, Feb 2002,
  which has normally been
  but a massive reorganization of the CSL Web structure is underway
  at the moment, and the usual URLs and cross-links do not seem to be
  working yet today.  (If internal links fail, stick in the tilde.)

Exploding cell phone shocks 911 dispatcher

<"Keith A Rhodes" <RhodesK@GAO.GOV>>
Thu, 10 Feb 2005 08:25:16 -0500

How ironic that this would happen to a 911 dispatcher.

and the hits just keep on coming.

RFID Tagging Elementary School Children

<"Peter H. Coffin" <>>
Fri, 11 Feb 2005 20:17:05 -0600

The only grade school in Sutter, California is requiring students to wear
radio frequency identification badges that can track their every move. Some
parents are outraged, fearing it will rob their children of privacy.  The
badges introduced at Brittan Elementary School on 18 Jan 2005 rely on the
same radio frequency and scanner technology that companies use to track
livestock and product inventory.

While similar devices are being tested at several schools in Japan so
parents can know when their children arrive and leave, Brittan appears to be
the first U.S. school district to embrace such a monitoring system.

Civil libertarians hope to keep it that way.  [PGN-ed]

I trust no one reading RISKS has any troubles imagining many ways to
foil this system. "Karen, I wanna ditch. Carry my tag in your backpack?"

  [That's why they will be embedded in babies' navels at birth.  PGN]

The risk of high-speed CD/DVD-rom drives in current-day PCs

<Henk Langeveld - risks digest <>>
Wed, 02 Feb 2005 22:54:00 +0100

I've had the nasty experience to have lost four CD's to newer high-speed CD
and DVD-drives within a year.

The current state of technology will run CDs and DVDs at high speeds, and
the centrifugal force of the drive increases the risk of any scratch on the
media to result in one broken CD, and one ruined drive.

  [Drew Dean commented to me on this: ``I believe programs such as Exact
  Audio Copy (EAC) do slow down the drive, and most CD/DVD burning software
  can write at slower speeds, but I'm not aware of any interface to tell an
  OS to always slow down reading.''  PGN]

You type Zuerich and I type Zurich... A brief note

< ("David G. Bell")>
Thu, 10 Feb 2005 09:18:24 +0000 (GMT)

There's been one of those idiosyncratic discussions in rec.arts.sf.fandom on
the details of library catalogues and author's names, and the most recent
issue of RISKS has sort of bounced off it.

Zuerich is, I understand, a quite correct "english" version of the Swiss

Most english-speakers will type "Zurich", similar to the native version but
using an ordinary ASCII "u", just as all sorts of other accent marks get
missed from European-language names.

And now Unicode allows computers to store all the variations as unique
codes, which is good for typesetting, but has potential for confusion
between visually similar characters.  Not everyone will be exploiting that
confusion for entertainment, as happened in "Monty Python and the Holy

But will search engines and indexes get tripped up by the differences, both
correct alternatives and mistakes?  Google does suggest alternatives to some
spelling errors and variants, but how far do you go?

David G. Bell — SF Fan, Filker, and Punslinger.

  [But do American search engines handle Zürich properly?  PGN]

Another MS Word info leak

<Richard Akerman <>>
Fri, 4 Feb 2005 14:05:48 -0400 (AST)

Just another example of the risks of Word features.  Not quite in the league
of the 'dodgy dossier' but still.

'The press release looked pretty unremarkable at first. The McGill
University Health Centre announcing an increased risk of heart attack in
elderly people with no prior history of heart attack who use the painkiller
Vioxx (which is now off the market).

The writing is a bit technical, but pretty clear.

But when press release writers compose these things, they have to run a copy
past the scientist involved. His comments in the margin of the final draft
were inadvertently sent out to everyone on the mailing list.  They're meant
to be "blind" — visible only to a specified reader — but they were in fact
visible on computers with Windows XP and Microsoft Word 2003.'

Fortunately for everyone involved, the scientist didn't say anything
particularly controversial.

Source: "Secret comments that everyone can read", Tom Spears, Ottawa Citizen,
3 Feb 2005.

Richard Akerman

High Risk Vulnerabilities in Eudora for Windows

<Monty Solomon <>>
Tue, 8 Feb 2005 21:42:44 -0500

John Heasman of NGSSoftware has discovered multiple high risk
vulnerabilities in the Windows version of Eudora.

Versions affected include:

Eudora 6.2.0 and below

The flaws permit execution of arbitrary code via:

1) previewing or opening a specially crafted e-mail
2) opening specially crafted stationary or mailbox files

These issues have been resolved in Eudora 6.2.1 as detailed at

It can be downloaded from:

NGSSoftware are going to withhold details of this flaw for three months.
Full details will be published on the 2nd of May 2005. This three month
window will allow users of Eudora the time needed to apply the patch before
the details are released to the general public. This reflects NGSSoftware's
approach to responsible disclosure.

NGSSoftware Insight Security Research
+44(0)208 401 0070

Re: U of Calgary adding spam and spyware (Slade, RISKS-23.70)

<Hendrik <>>
Fri, 11 Feb 2005 10:54:34 +0900

The risk of not learning what needs to be learned!

It's about time this was done! :-)

In 1992 I found a small book in a bookstore in Saudi Arabia, that had been
published by the German "Kaos Computerclub". In this book the authors
explained how viruses worked, from an angle of approach of how to write
viruses (at that time we had to deal mostly with DOS boot sector viruses).
The authors further described how they had approached major software
companies with this information, none of whom was the least bit interested
in the information or in any cooperation with people who knew how to write
viruses. Some of the approached companies had furthermore warned the
authors against publishing the information about viruses they had on hand.

I am not impressed, to say the least, that 13 years after the Kaos
Computerclub had the right idea, in a world awash in viruses, worms, and
spam, with a world-wide deployed home computer OS that seems to have less
security than the front door of my house, we still have not made any
progress in regards to how we deal with knowledge about malware.

In the the CBC article that Rob Slade refers to, Aycock (the "virus teacher"
at UofC) is quoted as saying "[S]ome companies have said they're not going
to hire [our] graduates because they don't like the perception of having
someone on board who has written viruses."

Well, I imagine reading the following in Time Magazine: "The White House
official said, 'We are not going to hire body guards who have been trained
at school X because we don't like the perception of having someone on staff
who has been trained to kill.'" Would you forgive me for laughing?

Rob Slade further writes:
>I can vaguely see a dim advantage to having students write viruses in order
>to understand them (rather inefficiently, in terms of time spent), but
>getting them to write a spamming program in order to understand how to fight
>spam seems even less effective.

Not all approaches to learning something are equally effective, and in an
area where something is being pioneereed, the first steps may not be quite
in the right direction or not as effective as future approaches. But that
alone is not a good reason to abolish a certain curriculum. My question
would be "What would make this training more effective?"

>As previously noted, John Aycock doesn't seem to have any credentials in
>security or malware [...]

Assuming this is relevant (it may be but need not be - i would suggest that
anybody who is a well-trained programmer and has the requisite imagination
has in principle the necessary credentials) why not call for a more
qualified professor for that course, then, instead of suggesting this
training is a bad idea?

I hope one day we will see malware courses in all university computer
science programs - then i would have reason to be more optimistic that the
"security mess" we are finding ourselves in might be cleaned up.
Creativity, more than anything else, is what we need to deal with the
future, and anybody who fosters and harnesses such creativity has my vote.

  [RISKS readers should see George Ledin's article,
     Not Teaching Viruses and Worms Is Harmful
  in the Inside Risks column space of the January 2005 issue of the
  *Communications of the ACM*, vol 48, no 1.  This article is also available
  online on my Web site
  The normal URL has always been

Re: U of Calgary adding spam and spyware (Slade, RISKS-23.70)

<"Matthew Holmes" <>>
Sat, 12 Feb 2005 11:23:26 -0500

> ... John Aycock doesn't seem to have any credentials in security or
> malware ..., so why he, and the university, chose to do this, other than
> pure self-promotion, is completely beyond me.

Hmmmm - who does have "credentials" in these fields? Is there a "mal-ware"
certification board? I must have missed it.

I did survey Aycock's professional literature, much of which is available
on-line, and I notice that a great deal of it centers on reverse-engineering
methodology, compiler/parser theory, etc. These are in fact the tools of the
virus writer - the real ones, not the script kiddies and buffer-overflow

Why the snippy tone in a RISKS article?

Re: Food via inkjet printer (Re: Scrivner, RISKS-23.70)

<Brian Reynolds <>>
Thu, 10 Feb 2005 12:07:55 -0500

These setups have been around for years.  The last time I saw this was
several years ago on the old epson-inkjet list.  The printer was
a standard Epson model.  There were warnings not to use standard inks in a
printer intended for food printing.

One method of doing this involves printing the image onto a potato starch
sheet using the food color inks and then affixing the sheet to the food item
(e.g., a cake).  Here in the USA Baskin & Robbins offers a service to print
an image to be put on one of their ice cream cakes.

Minireview: Bill Neugent, No Outward Sign

<Peter G Neumann <>>
Fri, 11 Feb 2005 20:53:58 PST

  Bill Neugent
  No Outward Sign
  ISBN 0-595-25749-6
  Bill Neugent's web site is at
  e-mail: wneugent at

Bill (in his work at MITRE) has been on the inside of computer security for
many decades.  I just finished reading his novel, and found it delightful,
and excellent piece of cybersecurity fiction.  It is a well-written
page-turner.  It is soundly based on things that have happened or could
easily happen, but threads them all together very nicely through a twisty
plot.  It twits the oxymoron of computer security, and brings together
good-hacker motivations, government bureaucracies, international
cyberthreats, short-sighted optimizations, and many other issues familiar to
RISKS readers.

The book is now available apparently only on the Internet, so I have
included a URL.

REVIEW: "A History of Computing Technology", Michael R. Williams

<Rob Slade <>>
Fri, 11 Feb 2005 08:32:32 -0800

BKHSCMTC.RVW   20041018

"A History of Computing Technology", Michael R. Williams, 1997,
0-8186-7739-2, U$64.95/C$104.95
%A   Michael R. Williams
%C   10662 Vaqueros Circle, Los Alamitos, CA   90720-1314
%D   1997
%G   0-8186-7739-2
%I   IEEE Computer Society Press
%O   U$64.95/C$104.95 714-821-8380, 800-CS-BOOKS
%O   tl i rl 4 tc 3 ta 4 tv 4 wq 4
%P   426 p.
%T   "A History of Computing Technology"

Yet another timeline from the Pascaline to Babbage to ENIAC?  Not so.  How
refreshing, and fascinating, to see a history that really tells us how we
got here.

Chapter one talks about the development of numeration itself, and the
various forms of representing numbers (as well as a few systems of
calculation).  Early aids to calculation, starting with fingers and moving
through to slide rules, are described in chapter two.  Throughout the book,
Williams has included frequent references to how calculating tools and
techniques have given rise to common phrases.  The definition of "point
blank" is particularly fascinating, involving not only a particular gunnery
instrument, but also the distrust of the Arabic numeral zero, which paranoia
would have been uniquely strong at that specific time.  Mechanical
calculators are discussed in chapter three, covering much more than the
usual reference to the Pascaline.  Chapter four outlines Babbage's machine;
noting that he was more social than is usually thought, and that he
succeeded in a number of fields (inventing, for example, the cow catcher);
explains why the Difference Engine is known as such, and further mentions
that it was hardly a failure, but spawned a bit of a building spree that
lasted over twenty years.  Analog, rather than digital, computers are often
neglected, but chapter five notes a number of significant devices.  The
large mechanical or electro-mechanical machines of the 1940s are frequently
seen as the beginning of the computer revolution, so it is interesting that
the book is half complete before chapter six takes a look at the Zuse
machines, the Bell relay machines, and Aiken's line.  Chapter seven moves
into the electronic world with reviews of the Atanasoff/Berry computer,
ENIAC, and the Colossi.  Given the importance of the work at Bletchley Park
in terms of character manipulation (in cryptanalysis) it is interesting that
other forms of text manipulation technology have not been addressed up to
this point.  The early computers dealing with stored programs are reviewed
in chapter eight.  As could be expected, the development of memory
technologies is a major component of this material.  Chapter nine finishes
off with a review of some other early mainframe type computers.

We tend to pass over the history of computing with varying degrees of
interest.  Having a detailed examination of the development of both ideas
and technologies of the basics of computing is both fascinating and helpful.
Those who ignore the history of computing are likely to buy it again,
repackaged under a new name.  Professionals willing to understand the
foundations of the industry and operations of the machinery will be in a
much better position to judge what will (and what will not) be of importance
in the future.

copyright Robert M. Slade, 2004   BKHSCMTC.RVW   20041018    or

Please report problems with the web pages to the maintainer