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 28

Thursday 18 March 2004


House Panel Slams Federal IT Security
JFK AirTrain passengers end up at storage yard instead of airport
Tom Lambert
Connecticut automobile emissions tests faulty
Danny Burstein
Diebold Opteva 520 ATM crashes exposing Windows XP Inside!
Scott A. Hissam
The RISKS of Risk Analysis
Michael Bednarek
Anti-spam lawsuit complaints
Monty Solomon
Self adjusting firewalls in Longhorn
Neil Youngman
Death of UK skydiver in Australia
Anthony Youngman
"Special Skills draft"
Geoffrey Brent
Risks of automated pedophilia detection
Nick Brown
Latest e-mail worms use password trick to foil filters
CORRECTION to "SSL is being severely stressed by phishing expeditions"
Alistair McDonald
Re: SSL is being severely stressed by phishing
Isaac Morland
Nelson Minar
Re: When is a decimal point not a decimal point?
John Carlyle-Clarke
Nick FitzGerald
Throwing out the baby with the bathwater: Crypto sigs
Tim Panton
Info on RISKS (comp.risks)

House Panel Slams Federal IT Security

<"Peter G. Neumann" <>>
Wed, 17 Mar 2004 17:10:06 PST

The latest "report card" of the U.S. House Government Reform Subcommittee on
Technology on cybersecurity in U.S. government agencies continues to paint a
generally dismal picture.  The National Science Foundation and the Nuclear
Regulatory Commission received A grades, while eight other agencies had F
(Failing) grades — including the Department of Homeland Security.  FOURTEEN
of 24 agencies received a score worse than C.  According to
U.S. Representative Adam Putnam (R-Fla.), Federal agencies aren't doing
enough to secure their network systems, even as documented cyber-attacks
against the U.S. government continue to rise dramatically — from 489,890 in
2002 to 1.4 million in 2003.  "Our government has taken very dramatic steps
to increase our physical security, but protecting our information networks
has not progressed commensurately either in the public or private sector."
Putnam closed the hearing by saying his subcommittee will seek
accountability of the "highest agency official responsible for information
technology investments to insure that IT security is baked into the
investment decision making process."  [Source: Roy Mark, *Internet News*, 17
Mar 2004; PGN-ed]

  [What's New?  Technology alone does not solve management problems.
  Management alone does not solve technology issues.  Reducing risks is a
  beginning-to-end, end-to-end system problem where the systems include all
  of the relevant technology, all of the relevant people, and all of the
  dependencies on and interactions with the operating environment, however
  flawed and complicated.  But those flaws and complexities must be
  addressed systemically.  The many lessons familiar to RISKS readers tend
  to be widely ignored by the folks who should most seriously be learning
  them.  PGN]

JFK AirTrain passengers end up at storage yard instead of airport

<"Peter G. Neumann" <>>
Thu, 4 Mar 2004 14:19:12 -0500

For the second time this year, passengers on the Kennedy Airport AirTrain
were accidentally diverted to a unused-train storage yard — where
passengers were exposed to live rails.  The 12 Feb 2004 mistake prompted an
internal overview of the $1.9 billion, eight-mile long transit system to
JFK.  Fifteen minutes later, the train was back on course.  A similar event
occurred on 26 Jan 2004, with a train winding up in the same storage yard.
[Source:, 4 Mar 2004, PGN-ed.]

Thanks to Tom Lambert at ACM for noting this one.  Tom's reaction was this:
"Whenever I hear of MTA [subway system] plans to further automate subway
service here in NY City, I think of events such as this one."]

Connecticut automobile emissions tests faulty

<danny burstein <>>
Tue, 16 Mar 2004 18:47:40 -0500 (EST)

Lisa Chedekel, Connecticut: New Emissions Tests Faulty, DMV Says False
Readings May Have Led Inspectors To Fail Thousands Of Vehicles,
(Hartford) *Courant*,  16 Mar 2004

  As many as 13,000 vehicles tested under Connecticut's new emissions
  inspection program may have been failed in error because the software used
  to measure a critical pollutant produced false readings, state motor
  vehicle officials confirmed Monday.  [...]  In Connecticut, state
  Department of Motor Vehicle officials, working with Agbar technicians,
  discovered recently that an analyzer used to detect hexane, the main
  hydrocarbon present in gasoline exhaust, was instead measuring propane

Sigh. The usual two problems here. First, no one kept track of the expected
versus the actual failure rates. And second, there's apparently no periodic
quality control checks.

(and third, of course, is the entire question of the value of emissions
testing, but that's a horse of a different color)

Diebold Opteva 520 ATM crashes exposing Windows XP Inside!

<"Scott A. Hissam" <>>
Thu, 18 Mar 2004 07:27:55 -0500

Want to listen to a little Beethoven, Jazz, or even the Talking Heads
while making that ATM deposit?

* The Scene: Carnegie Mellon University
* The Event: A newly installed Diebold Opteva 520 ATM crashes, then
  reboots. Surprisingly, it's vanilla-style Windows XP operating system
  initialized without the actual ATM software.
* The Result: A desktop computer with only a touch screen interface is left
  wide open for the amusement of the most wired university in the U.S.

Eschewing more malicious schemes, the first move was to connect to the
Internet. This plan proved unsuccessful as there seemed to be no network
capability. The situation was complicated in that even typing proved
extremely difficult due to the lack of a keyboard. The Character Map program
was used to enter text by copy-and-pasting, yet the most that was
accomplished by doing so was making the text-to-voice program say, "What, do
you think I'm made of money?" Windows Media Player was set up to loop a
series of Beethoven, Jazz, and Talking Heads (the sample sound files
included with XP) while running a full screen visualization.
  [Source:; 17 Mar 2004]

  [Another report noted by George Michaelson in Dave Farber's IP.  PGN]

The RISKS of Risk Analysis

<Michael Bednarek <>>
Thu, 18 Mar 2004 00:02:58 +1000

A recommendation by a Government agency to allow banana imports from the
Philippines is being reviewed after finding an error in its risk assessment
report, reports the ABC [Australian public broadcaster]. (1)

According to the agency, Biosecurity Australia, it was a "transcription
error in the electronic spreadsheet used in the estimation of risk for this
particular IRA [import risk analysis]. The spreadsheet has now been
corrected." (2)

Well, it wasn't really a spreadsheet, but a MS Project file with the @Risk
add-on. (3)

A quote from the ABC's coverage: (1) "The Australian Banana Growers Council
says its opposition to banana imports has been vindicated.  Council
spokesman Tony Heidrich says a revision is not good enough and the
assessment process needs to start again from the beginning.  'We just don't
think you can continue to have faith in Biosecurity Australia's ability to
carry out this [import risk analysis],' Mr Heidrich said.  'We think there
could well be fundamental flaws going right back the first commencement of
the process.' "

The RISK? Surely one of the oldest chestnuts in computerdom: don't believe
something just because it's a computer printout.

(1) <>

(2) <

(3) <>

Michael Bednarek

  [This case was also noted by George Michaelson.  Incidentally, for those
  of you who have not seen it, you might enjoy Section 7.10 of my
  *Computer-Related Risks* book, pages 255--257, entitled Risks in Risk
  Analysis, drawn from an earlier *CACM* Inside Risks column from June 1991,
  written by Robert N. Charette.  It is still very relevant.  PGN]

Anti-spam lawsuit complaints

<Monty Solomon <>>
Fri, 12 Mar 2004 09:35:30 -0500

Spam Litigation

* Complaint and Exhibits (America Online, Inc. v. John Does 1-40)
(March 9, 2004)

* Complaint and Exhibits (America Online, Inc. v. Davis Wolfgang
Hawke, et al. (March 9, 2004)

* Complaint (Earthlink, Inc. v. John Does 1-25, et al. (March 9, 2004)

* Complaint (Microsoft Corp. v. JDO Media, Inc., et al. (March 9, 2004)

* Complaint (Microsoft Corp. v. John Does 1-50 d/b/a Super Viagra Group)
(March 9, 2004)

* Complaint (Yahoo!, Inc. v. Eric Head, et al. (March 9, 2004)

  [My unfiltered spam has gone through the roof again in the past two weeks.
  Thank you all for using the designated keyword in the subject line of your
  postings.  So, I have a new strategy.  I delete ALL of the unkeyworded NEW
  MAIL, and then check for exceptions.  In the past week, I have detected
  only a few legitimate messages that did not use the keyword.  The result
  is that even after SpamAssassin filtering, 95% of the residual e-mail is
  spam.  But this really simplifies my pain.  PGN]

Self adjusting firewalls in Longhorn

<Neil <>>
Wed, 17 Mar 2004 17:33:34 +0000

According to

"Longhorn engineers are packing new technologies into the OS to check
against a central patching Web service for security holes on computers. If a
user does not have a patch installed, Longhorn's active protection
technology will kick in to adjust the firewall or PC settings"

Great if it works and it doesn't break any critical functions.

RISKS? how about blocking communication to/from a heart monitor in an
intensive care ward?

Further examples are left as an exercise for the reader ;-)

According to Robert McLaws of Interscape Technologies, an independent
software partner of Microsoft, "if they don't care enough to keep their
systems secure, then they have lost that right to complain,"

Death of UK skydiver in Australia

<"Anthony Youngman" <>>
Thu, 18 Mar 2004 12:45:47 -0000

  Skydiving victim Clare Barnes was doomed from the moment she jumped from a
  plane at 14,000ft, an enquiry revealed yesterday.  What appears to have
  happened in this case is that all the cards have been stacked against her
  and have fallen the wrong way each time.  A parachute has a number of
  components. They are largely interchangeable, but not always.

She was apparently using her own equipment, and the incompatibilities meant
that there was no way that parachute was going to open successfully. The
risks are obvious and, sadly, tragic.

"Special Skills draft"

<Geoffrey Brent <>>
Thu, 18 Mar 2004 10:52:18 +1100

The USA's Selective Service System has begun working on developing
procedures and policies for a targeted military draft of Americans with
computer and foreign-language skills, although the SSS has emphasised that
such a draft is not imminent.

(A similar plan for selective drafting of medical personnel, the HCPDS, has
already been assembled. See for a brief
overview, or
for a friend's observations on the HCPDS - some of which may also be
pertinent to this latest project.)

It has long been known that conscripts are vastly less effective and less
reliable than volunteer soldiers; during the Korean War, the AP famously
reported that only one in four US draftees used their weapons even when
defending against enemy attack.

Computing is a field where a sloppy, unmotivated worker can all too easily
achieve negative productivity without immediate detection. A disgruntled,
_malicious_ worker can do far worse - compare the man-hours spent in writing
malware with those spent in repairing its effects.  Relying on conscripts to
supply the computer expertise the US armed forces might need strikes me as
an exceptionally bad idea.

Risks of automated pedophilia detection

<Nick Brown <>>
Thu, 18 Mar 2004 16:16:49 +0100

The BBC's web site reports on a "chatbot" program which is designed to run
in chat rooms oriented at children, and detect when the people chatting with
it may be attempting to lure children into "inappropriate" activity.


'The chatbot has already been used in many chatrooms and its creator claims
that, so far, no-one has caught it out.'  (Nothing unsubstantiated or
speculative there, then.)

'[The author of the software] said that information gathered by the
Chatnannies had already helped some police investigations.'  (Uh-huh.)

'"If this software works, then it would be marvelous because there is
nothing like this out there," Chris Atkinson, Internet safety officer at the
National Society for the Prevention of Cruelty to Children, said.'  (Can you
say "non-sequitur" ?)

The RISKs are left as an exercise to the reader, but to get you started:

- How will law enforcement officers tend to treat chatroom participants
  whose behaviour has been flagged as dubious by this program ?  Will they
  spend large amounts of resources to trap a pedophile, only to find that
  all they meet is an over-eager 13-year-old boy ?

- The claims made for this software seem to amount to passing the original
  Turing test.  That's quite an achievement.  I wonder if the software
  community will be allowed to verify these claims; or will the bot be kept
  secret "to protect the children"?

Nick Brown, Strasbourg, France

Latest e-mail worms use password trick to foil filters

<"NewsScan" <>>
Tue, 16 Mar 2004 07:09:31 -0700

The most recent versions of the pesky Bagle worm — Bagle N and Bagle O --
arrive in a compressed and password-locked .zip or .rar file with the
password included in the body of the e-mail along with a message urging the
recipient to open it right away. This latest technique is designed to foil
corporate e-mail filters that may block ordinary zipped attachments but
allow password-protected documents to pass through the network's defenses
unimpeded. Once the attachment is unlocked, the worm is then forwarded to
everyone in the victim's e-mail address book. "The worm's author is sneakily
trying to make it more difficult for antivirus products to scan inside the
password-protected files," says Graham Cluley, a researcher with U.K
cybersecurity firm Sophos.  [*New Scientist*, 15 Mar 2004; NewsScan Daily,
16 Mar 2004]

CORRECTION to "SSL is being severely stressed by phishing expeditions"

<"Alistair McDonald" <>>
Wed, 17 Mar 2004 08:44:55 -0000 (GMT)

I am indebted to David Wagner for correcting me when reporting on the
Netcraft News item, regarding plain-text SSL, in RISKS-23.27.  Those with
better knowledge than I have been discussing this, and, in David's own
words, the reports are "Hogwash".

David has provided a link to a newsgroup archive at Google groups: where the matter is discussed. If you're
interested, then please take a look.

The risks (to me): don't believe everything you read, even if it comes
from a normally reputable source.

Alistair McDonald  (+44)(0)7017-467386

Re: SSL is being severely stressed by phishing (RISKS-23.27)

<Isaac Morland <>>
Thu, 18 Mar 2004 08:37:06 -0500 (EST)

Of course, the ultimate fix to phishing would be an end to the
mixed-endian nature of URLs:  The domain name and user/password are
little-endian, while the rest of the URL is big-endian.  So for example, a
bogus url like

would look like this in big-endian form:

Note that even disallowing the user/password stuff would still allow an
URL like this:

Which again is quickly revealed as a fraud in big-endian notation.  So the
real fix is to use big-endian notation.  Of course, in real life this would
never work even if the technical aspects would be worked out because people
will just click on anything.  But we can dream.

Re: SSL is being severely stressed by phishing (RISKS-23.27)

<Nelson Minar <>>
Tue, 16 Mar 2004 16:40:03 -0800

"Alistair McDonald" <> writes:
>My advice on phishing avoidance: never click on a link in an e-mail from a
>financial institution, always navigate from a bookmark. If possible, avoid
>typing in web addresses too

Microsoft offered one more item to your advice: don't click on links
on web pages. Or as Microsoft Knowledge Base Article - 833786 said:

  The most effective step that you can take to help protect yourself
  from malicious hyperlinks is not to click them. Rather, type the URL
  of your intended destination in the address bar yourself. By
  manually typing the URL in the address bar, you can verify the
  information that Internet Explorer uses to access the destination
  Web site. To do so, type the URL in the Address bar, and then press

This absurd suggestion used to appear here:;%5Bln%5D;833786
It's since been removed and a patch for this problem has been issued.
(Search for the above quote to find many copies of the original.)

Something is seriously wrong with the state of Web security when the
approved way to verify the identity of a site is to look for a 16x16
icon in one corner of the screen and even that doesn't work in many
cases. It's not just MSIE URL display bugs or obscure SSL modes at
fault; the model is broken.

Re: When is a decimal point not a decimal point? (RISKS-23.27)

<"John Carlyle-Clarke" <>>
Wed, 17 Mar 2004 11:33:24 -0000

> Date: Thu, 11 Mar 2004 23:40:51 +1100
> From: "Darryl Smith" <>
> Subject: When is a decimal point not a decimal point?

> Unfortunately on systems where the locale has been changed to have
> a comma as a decimal place, then Visual Basic ignores the fact
> that I have specifically stated that I want to use a decimal point
> when I format the number into a string, and changes it to a comma.
> To be fair to Microsoft this is listed in the manual Visual Basic
> 6.

We encounter the same problem regularly with VB software that we produce.
We have made efforts to by default use Val and Str (which are non-locale
aware functions) unless a locale aware conversion is specifically needed.
We have also written our own non-locale aware Format replacement where
number formatting is needed.

A RISK here is that salepeople assume that producing French and German
versions of the software will be "just a matter of translating a few
strings", which ignores the many pitfalls.  This is before you even try more
complex problems like non-Roman alphabet languages, or even right-to-left

Another gotcha: if you change your locale on your development machine to
test the effects, VB breaks its own source code.  If the hidden part of form
files (text format, but concealed by the IDE) contains any non-integer
numbers, VB will save them using the locale settings.  Switching back can
make the project fail to load.

The RISK, it seems to me, is assuming that OS locale-handling functions will
deal with all these problems without the developer having to worry about it,
and approaching language or locale conversion as a "Phase 2" option, rather
than being aware of it from the outset.

Like many others, I imagine, this was learned the hard way for us.  (Perhaps
this is mostly a UK/USA problem?  Maybe developers in other countries tend
to be more aware of this.)

Re: When is a decimal point not a decimal point? (Smith, RISKS-23.27)

<Nick FitzGerald <>>
Wed, 17 Mar 2004 14:16:55 +1300

"Darryl Smith" <> wrote:

<<snip gory details>>
> Unfortunately on systems where the locale has been changed to have a comma
> as a decimal place, then Visual Basic ignores the fact that I have
> specifically stated that I want to use a decimal point when I format the
> number into a string, and changes it to a comma.  ...

Your description of what VB is doing is incorrect.  When you write and
compile your program on a system whose locale settings mean
"<digit>.<digit>" represents a "decimal number", VB is taking note of the
meta-information about locales, number (and no doubt, date, time and several
other) formats and representing that internally in a locale- independent

> ...  To be fair to Microsoft
> this is listed in the manual Visual Basic 6.

Precisely.  VB6 is designed to be localization sensitive and to more or less
automatically handle such things on behalf of the programmer (depending
where in Canada your correspondent is, there is a high probability that any
VB6 runtime error messages generated by your program will be displayed in
French too...).

> Of course since the NMEA sentence I am generating uses commas as field
> delimiters, the fields are getting totally messed up. And the mapping
> software is making its best effort to display the obviously incorrect
> position.
> The risk: using the same character to denote decimal places as for denoting
> different fields is not a good idea.

This is an historic issue with "soft" data formats where field and/or record
delimiters occur "in-band" (i.e. in the same transmission stream) _and_
where the set of such delimiters contains one (or more) characters that can
validly comprise part of a valid field value.

I think the greater risk you have described is that of a programmer using a
tool whose complete feature set s/he was not fully aware of.  This is a
class of risk that is probably much greater the "simpler" the tool is to use
(assuming it is a tool of modest power, as VB6 certainly is).  This is so
for (at least) two obvious reasons — if a powerful (and therefore complex)
tool is made simple to use much of its complexity is necessarily hidden (at
least from those of its likely users who are less widely experienced in that
field), and simple yet powerful tools are likely to attract the attention
(and use) of those who are otherwise prevented access to such power (because
other such tools are obtuse for not disguising their complexity, etc).

(I'm not a VB user, but suspect a simple, albeit perhaps not strictly
"correct" solution to the issue here might be to quote the field values, at
least for those fields that can contain such "ambiguous" data values.)

And finally, there was potential for an even larger risk in this story --
had your Canadian user had a GPS device that expected "locale- correct"
input and was configured for "French Canadian" language or somesuch, your
program would have worked for reasons you would not have understood _nor_
been unaware of...

Throwing out the baby with the bathwater: Crypto sigs

<Tim Panton <>>
Wed, 17 Mar 2004 17:32:28 +0000

What's wrong with this picture ?

> [demime 0.98b removed an attachment of type
> application/pkcs7-signature which had a name of smime.p7s]

So in order to protect me from a potential virus, the sending system has
removed the one thing that would have helped me judge the provenance of the

To be fair, stripping cryptographic signatures isn't entirely stupid if either:

(a) the crypto software is not sanity checking its inputs, or

(b) the mail client can be fooled into executing an attachment that
    the mail gateway took to be a data, i.e., a signature.

Unfortunately both of these conditions are true for most Outlook on Windows
setups (or at least were until the recent ASN1 patch).

This isn't really any different from the problems we saw with buffer
overruns in the from line permitting execution of arbitrary code. In that
case no one stripped from addresses as a protective measure!

We still have a prevalent mindset that sees security (in this case
authentication) as optional. I suppose that's what I'm complaining about.

By the way, as an author of an ASN1 decoder (for SNMP), I know how hard it
is to parse ASN1 securely. If you use the right language and design, it
really isn't that hard.

The sender is a mailing list with a strict no-attachments policy, so it
could be said that they are just treating the signature like any other

However it would be a sad day if this were the norm, as signatures should be
part of the solution to spam and viruses — not part of the problem.

Please report problems with the web pages to the maintainer