The RISKS Digest
Volume 25 Issue 57

Friday, 20th February 2009

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…

Contents

Taiwan immigration computer down again
jidanni
Wikipedia prankster dupes German media
Allen Hainer
The Trouble with Trusting Trend Micro
Kevin Way
ESTA visa waiver online doesn't provide existing waiver ref number
George Michaelson
Stove's Bad Crash Handling
Gene Wirchenko
Dates of birth are not unique identifiers
Steven J Klein
Re: Train brake failure; broken valve
Matt Roberds
Re: Collision - UK and French Nuclear subs
Richard I. Cook
Geoffrey Brent
Re: What if you can't pull the plug?
Michael Loftis
David Lesher
Re: Windshields and Windows combine to provide malware vector
Tom Perrine
Re: Godel and correctness
Martyn Thomas
Re: Tony Hoare: "Null References"
Dimitri Maziuk
King Ables
Re: The mystery of `Ireland's worst driver'
David Cantrell
Re: Opening event goes with a bang
Mark Brader
Re: Risks of reading RISKS
jidanni
Martyn Thomas
Scott Miller
Info on RISKS (comp.risks)

Taiwan immigration computer down again

<jidanni@jidanni.org>
Sun, 15 Feb 2009 14:28:20 +0800

I swear I'm not making this up just trying to give itty bitty
countries who can't fend for themselves a bad name, see:
http://www.taipeitimes.com/News/taiwan/archives/2009/02/14/2003436061

IMMIGRATION: Airport system crashes again

The immigration computer system at Taiwan Taoyuan International Airport
experienced another breakdown yesterday morning, lasting 20 minutes. Added
to the two more serious breakdowns suffered last month, yesterday's incident
marked the third system breakdown this year.  National Immigration Agency
Deputy Director-General Huang Pi-hsia said that yesterday's incident
happened because of a system database capacity shortage when the agency was
converting files in the database. No flight delays were caused as a result
of the incident and no one banned from leaving or entering the country
passed immigration during the 20-minute stoppage.

(Including Ex-President Chen "Count TheTowels" Shuibian, still safely
in the slammer.)


Wikipedia prankster dupes German media

Allen Hainer <risks@hain-veilchen.de>
Thu, 12 Feb 2009 16:51:58 +0100

"An article meant to poke fun at the lengthy royal name of new Economy
Minister Karl-Theodor zu Guttenberg turned out to be a joke on daily *Das
Bild* and other German publications who revealed their reliance on Internet
encyclopedia Wikipedia when they published his name incorrectly this week."
  http://www.thelocal.de/society/20090212-17397.html


The Trouble with Trusting Trend Micro

Kevin Way <kevin@insidesystems.net>
Thu, 12 Feb 2009 10:26:24 -0500

Many of us use blacklists such as those provided by Trend Micro's MAPS
program as part of an anti-spam solution.  However, by doing so we're adding
significant risk due to ineffective (or absurd) administrative procedures on
the part of the list provider.

For example, a datacenter I use has IP space incorrectly listed on Trend
Micro's MAPS DUL.  When they attempted to have the static space removed (15
blocks totaling 159,744 IPs), Trend Micro responded that they would not
remove the IPs from their blacklist unless the rDNS for every IP in the
space was modified to include the word 'static'.

Trend Micro was unwilling to offer any alternative way to correct the DUL,
and indicated that since the center hadn't changed rDNS on all of the IPs
that their space would remain listed, incorrectly, on the DUL.

The damage done by such mistakes is then magnified by the common anti- spam
practices of either silently dropping the mail, or delivering the mail to a
"Junk Mail" folder which often remains unchecked.  In both cases, the sender
is unaware that a problem has occurred, and that an alternate means of
communication must be established.

The experience made me wonder how many blacklist consumers really understand
and recognize the amount of risk they're accepting, when they trust a
third-party blacklist so thoroughly that they will silently squelch
communications according to that list.


ESTA visa waiver online doesn't provide existing waiver ref number

George Michaelson <ggm@apnic.net>
Thu, 19 Feb 2009 15:39:58 +1000

The US Government instituted an online mandatory visa waiver process for
travelers.  The visa waiver consists of a 16 character alphanumeric string.
If you visit the URL: https://esta.cbp.dhs.gov/esta/esta.html
you can either apply for a new waiver, or re-update an existing one.

If you HAVE one, you cannot use the new application side: it terminates 5
screens in. this is not made plain to you until you have completed the
entire I94w equivalent "no I am not a former nazi" declaration (cute, that
they removed the "nor am I a member of the communist international")

If you HAVE one, but don't know the number, then the site cannot send you
your number, not tells you your number. Therefore, unless you record your
number offline, you are locked out.

Sure, there are risks of telling people their number. But one presumes that
the system at least understands people might have forgotten a 16 digit magic
number.

72-hour deadline. You have to do it, or you risk being offloaded by the
airline.  Nice!


Stove's Bad Crash Handling

Gene Wirchenko <genew@ocis.net>
Sun, 15 Feb 2009 13:40:56 -0800

Following is a post from alt.folklore.computers about a stove's software
crashing.  The risk is what happens: it turns everything on at lowest
setting.

Date: Sun, 15 Feb 2009 18:20:55 +0100
From: Morten Reistad <first@last.name>
Subject: Re: I need magic incantation for a power conditioner

In article <proto-9E06BD.11220115022009@news.panix.com>,
Walter Bushell  <proto@panix.com> wrote:
 >In article <v318ng.lht.ln@eden.reistad.name>,
 > Morten Reistad <first@last.name> wrote:
 >
 >> In article <19tep4l1vgahtate1dofomm0aks3u0ai4d@4ax.com>,
 >> krw  <krw@att.bizzzzzzzzzzz> wrote:
 >> >On Sat, 14 Feb 2009 07:39:23 -0500, jmfbahciv <jmfbahciv@aol> wrote:
 >> >
 >> >>Charles Richmond wrote:
 >> >>> jmfbahciv wrote:
 >> >>>> sidd wrote:
 >>
 >> >>>>
 >> >>>> I was thinking of the field.  The way I stopped the modems
 >> >>>> from getting busted was to ban the cleaning lady from the
 >> >>>> the terminal room.
 >> >>>>
 >> >>>
 >> >>> Aside:  Did you leave your stove that interfered with you
 >> >>> AM radio... when you moved to your new house???
 >> >>>
 >> >>You betcherass I did.  It is Mass. law that a stove be
 >> >>left on the premises.
 >> >
 >> >Ok, gotta ask...  Does the new stove kill the radio like the old?
 >> >
 >> >... or as completely as congress is about to?
 >>
 >> Or does the new stove have software crashes, like I discovered
 >> ours has.
 >>
 >> "Sorry Dear, dinner is late, had to reboot the stove."
 >>
 >> — mrr
 >
 >Now that is just wrong, putting Microsoft in critical life support
 >equipment. It says in the contract that it is not to be used in mission
 >critical equipment.

I have no reason to believe there is Micro$oft in$ide; the whole controller
box with 8-character display is around 5x5xsub 1 cm, 2x2x1/3rd inches. It
has three cable attachments plus power; one to the touch panel, one to a
series of BIG regulators, and one to a front panel.

It went "Error 32" (ISTR) blinking, while all active positions went on, but
on the lowest possible setting. (A fencepost error in the error handling
code?) This means it turns ON the stove, but at a very low setting, on
crash. Sheesh.

It then just said "beep" when trying to manipulate something.

We had to drop the fuse for around 5 seconds before it restarted, beeped
loudly, said "Error 32" again, then a couple of other diags, including a hex
value, and then went back to being happy again.  — mrr


Dates of birth are not unique identifiers

Steven J Klein <steven@klein.us>
Wed, 11 Feb 2009 02:13:23 -0500

USAA is a membership-based financial services company; existing members like
myself can create memberships for family members — even minor children.

Recently I used their web site to try and create memberships for my kids.
It worked for my son, and the first of my three TRIPLET daughters. (Some of
you have already guessed where this is going.)

But after putting in all the info for my 2nd daughter (name, social security
number, date of birth, and other data), I got an error message saying "We
have canceled your request. To add this person, please call ..."

As their customer service rep later explained to me, there was some concern
that careless users might accidentally try to add the same child more than
once. To overcome this, their programmers decided to use the birth-date as a
unique identifier.

But it's not unique for twins, triplets, etc. It's also possible (though
less likely) for two step-siblings in a "blended family" to have the same
date of birth.

Why not use the social security number, which is guaranteed to be unique?  I
don't know, and neither did the person who answered my call.
  [* It is probably illegal, unethical, and subject to misuse.  PGN]

(It is interesting to note that 2 of my triplets received sequential social
security numbers, but the 3rd differs by 1,930.)

Steven J Klein, CompTIA A+ Certified,Apple Certified, Your Mac & PC Expert
Phone: (248) YOUR-MAC or (248) 968-7622


Re: Train brake failure; broken valve (Lesher, RISKS-25.56)

Matt Roberds <mroberds@att.net>
Fri, 20 Feb 2009 15:12:41 +0000

In RISKS-25.56, David Lesher commented on a report of a rail accident in the
UK.  Following the release of that report, there was also a bit of
discussion in news:misc.transport.rail.americas .  (Part of the summary
posted to RISKS appears to be from the first post in that thread.) There was
also a discussion a few weeks earlier in news:uk.railway .  Links:

http://groups.google.com/group/misc.transport.rail.americas/browse_thread/thread/2e15e2405ed0114a
http://groups.google.com/group/uk.railway/browse_thread/thread/48705d7fd6838040

The discussion shows that the risks of not having an independent emergency
valve have been known for some time; one poster cited a steam locomotive
built in 1913 that had two such valves, presumably as standard equipment.
There was speculation that the accident locomotive probably had an
independent emergency valve from the factory, but that it was later removed.
(This is likely a well-known story on RISKS: your computer (locomotive) can
have as much buggy hardware as you want if it's just sitting in the corner
(running around the quarry) by itself.  Once you plug it into the network,
though, you can cause problems for everybody.)

A couple of posters also echoed the statement in the accident report that if
the train driver had _released_ the locomotive brakes, the dead-man system
would have started operating again, and would have applied the train brakes,
probably stopping the train.  As noted briefly in the report, this is a
training issue.  As Stephen Furley put it, "When you're running downhill,
with a heavy stone train behind you and the train brakes have failed, it's
not exactly obvious that the best thing to do is to release the only
functioning brake that you do have, even if that's not managing to stop the
train."  (Two more well-known stories: training and user interfaces.)

Anyway, I think that the problem here wasn't so much that a new critical
failure mode was discovered, but that part of the system that was designed
to cope with a known failure mode was disabled.  (Another well-known
story.)


Re: Collision - UK and French Nuclear subs (Wood, RISKS-25.56)

"Richard I. Cook" <ri-cook@uchicago.edu>
Thu, 19 Feb 2009 20:11:31 -0600

Charles Wood hypothesized the collision was the result of...

(1) ...one of the submarines stalking the other, and as an unexpected
    outcome, colliding with the target?
or
(2) ...current submarine navigation systems constrain the vessels to travel
    at specific, and integral, depths and tracks?

(1) is extremely unlikely. The vessels are strategic nuclear submarines
(missile launch platforms) and unsuited to pursuit and shadowing. This
function is provided by 'attack' submarines which are smaller, more agile,
and armed differently. (BTW, the number of attack submarines in the
U.S. fleet is maintained at number sufficient to have at least one follow
each Soviet sub as it leaves harbor and this has been the practice for a
very long time.)

(2) is probably closer to the mark, although the reasons are different.  The
ballistic and accuracy characteristics of each country's sea-launched ICBMs
are quite similar because of the physics of flight.  The targeting of these
missiles is also likely to be similar because potential targets are all in
the few nuclear-armed and potentially hostile countries. Given the ocean
characteristics which effect the 'hiding' of strategic submarines and the
interior location of their major targets (mostly Russian missile silos,
etc.), the number of cruise routes that allow a strategic sub to carry out
its mission is actually rather limited. Remember that the entire purpose of
strategic nuclear submarines is deterrence and for deterrence to be credible
it has to be continuously present — that is, unlike other weapons systems,
strategic nuclear submarines must always be prepared to launch their
missiles against their targets. This is a rather severe requirement that
makes the useful ocean relatively small. For this reason, it is not at all
unlikely that two strategic subs would collide.

BTW, all of this info is publicly available...you just need to know where to
look.


Re: Submarine collisions (Wood, RISKS-25.56)

Geoffrey Brent <gpbrent@optusnet.com.au>
Sat, 21 Feb 2009 02:37:36 +1100

Charles Wood suggests that integral depth settings might be a cause of the
recent submarine collision (perhaps this problem could be avoided if the
British agreed to use imperial units and the French metric?)

Another consideration is that while there are about a billion cubic
kilometers of water in the Earth's oceans, some of them are much more
attractive than others for submarine commanders - seafloor topography and
gradients in water temperature or salinity can have a lot of influence on
stealth. Increasing precision in measuring these things might also have
something to do with why the French and British commanders ended up hiding
on top of one another.


Re: What if you can't pull the plug?

Michael Loftis <mloftis@wgops.com>
Tue, 10 Feb 2009 21:57:07 -0700

One thing about all the current apple devices is that the power button (or a
combination of buttons on the iPods) have a supervisory power circuit system
that can, and will, disconnect the main software controlled power supply
when held down.  The macbook air, new macbook pro, and even all the old
macbook pro's are no different.  The power management subsystem cooperates
with the software in the OS, but is itself a separate, and very simple,
embedded device.  So if you hold the power button down, even if there's no
OS going, it'll go off.  But it will take ~10 seconds.

This is in fact a very common behavior (and architecture) for many battery
operated devices.

For the iPod there's a set of supervisory circuits that allow you to cause
the power to be turned off/on, and for the reset line to be triggered on the
CPU.

I've not used an iPhone, but I think it does have a power button.  Apple's
engineers however, are usually a little more thorough with details than some
other companies, so I can't say that this holds true for all hardware
manufacturers, but it does for most.


Re: What if you can't pull the plug? (RISKS-25.55)

"David Lesher" <wb8foz@panix.com>
Wed, 11 Feb 2009 01:03:16 -0500 (EST)

> Software-controlled power switches
> Long-life batteries that can't be removed
> Continuous wireless Internet access via WiFi or mobile phone networks

I agree with the risk, but have a suggestion.

Place in plastic bag.
Wrap with foil.
Insert in freezer.

Not only is it as good a RF cage as your house likely has; the reduced temp
will sap the battery's enthusiasm...

Alternately, you can but RF-proof zipper bags, but they are rather costly.

Of course, if the FBI is tracking you/listening via same; you'll soon
get a visit... {The OTHER RISK of never-off devices...}


Re: Windshields and Windows combine to provide malware vector

Tom Perrine <tperrine@scea.com>
Wed, 11 Feb 2009 12:23:42 -0800
  (RISKS-25.55)

This may just be my former "cold war" past rising up after all these
years, but Grand Forks is an interesting place to see this happen (first).

Grand Forks is the home of a US Air Force base for aerial refueling and
airlift.  The refueling and airlift commands have information about the
missions of all the groups that they support, and are a prime source of
military planning and readiness data.

The malware had 3 components:  1) join to botnet, 2) steal passwords,
and 3) buy fake A/V software.

Items 1 and 2 would be great vectors to get "on base", if a home or
laptop computer of a military member became infected.

But, it's probably just someone trying to make a buck on the fake A/V.


Re: Godel and correctness (Was: Tony Hoare ...)

Martyn Thomas <martyn@thomas-associates.co.uk>
Wed, 18 Feb 2009 10:51:30 +0000

In the context of Schaefer's posting, I assume
 * Correct = self-consistent = code implements the specification.
 * Complete = "The specification doesn't omit anything I consider important".

The issue of whether the specification actually describes the system that,
with hindsight, you would wish you had specified is also helped by formal
specification (because you get faced by a lot of questions that force you to
think hard about the properties you want your system to have and the
consequences of those properties). But no formal system can guarantee 20/20
hindsight.

Martyn Thomas CBE FREng  http://www.thomas-associates.co.uk


Re: Tony Hoare: "Null References" (Franklin, RISKS-25.56)

Dimitri Maziuk <dmaziuk@bmrb.wisc.edu>
Fri, 20 Feb 2009 09:48:32 -0600

Sometimes I think the problem with C is that they're teaching it
backwards. What they should teach is "here's how you create a memory area,
here's how you use pointers to fill it with values of the same type. Here's
how you can emulate multi-dimensional arrays, and here's how you emulate
one-dimensional array of printable bytes that you can use as a close enough
approximation of a string."

Once they're certain the students got it, then they could say "oh, and by
the way, for our convenience we've created this square bracket notation and
this nifty zero-byte hack. Keep in mind they're just handy shortcuts, there
are no strings. Nor arrays."

There are languages that have built-in string data type and no buffer
overflow in gets. There are languages with array data type that knows its
own size, has bounds checking and often lets you indexed elements from
e.g. -3 to 5. C just isn't one of them. All it is is glorified assembler and
all it really has is what the computer has: integers and floats. With some
integers getting special treatment because they represent memory addresses.


Re: Tony Hoare: "Null References" (Franklin, RISKS-25.56)

King Ables <king.ables@alumni.utexas.net>
Fri, 20 Feb 2009 06:13:25 -0600

> The inventors of the C language did not merely omit array bounds checking
> from C; they encouraged C programmers to omit manual bounds checking as
> well.  This is what really bothers me.

I think one has to be older than "a certain age" to understand the mindset.

This was a time when many people wrote in assembly language. For many
writing in "high-level languages," that language was FORTRAN (and the 1966
standard, at that). What you wanted from a high-level language was data
structure and functional convenience without losing any of the direct access
to any location in memory that you were accustomed to in assembly code (this
is why peek() and poke() stayed around so long in early PC languages, they
were useful). I'm the programmer, I'll keep track of what I'm doing and
where I'm putting things, thank you.

When you had a buffer overflow, it was because your own code did something
you didn't intend, and the only result was your program crashed. Your only
incentive to fix your bug was to prevent the crash. Buffer overflows with a
specific and malicious intent were unknown. There was no Internet. Nobody in
another country was pushing data into your program, nor could you conceive
of any such an eventuality. Heck, you were happy when the operator mounted
the right tape with the right input file on it.

I'm not defending it, clearly, with the benefit of hindsight, it was the
wrong choice. But it wasn't such a bad choice at the time. There were good
reasons for doing it that way. Try telling a caveman that one day he'll
leave his cave and build a house out of wood and then that fire he just
invented will be dangerous so he'd better go invent the fire extinguisher
right now. His biggest problem today is keeping the fire going, why would he
ever want to put it out? He has no context in which to see your issue.

Assigning blame for the current state of things when we have much more
information than those to whom we may try to assign that blame is unfair.
We're all making choices today that people 20 or 50 years from now will look
back and wonder "what where those idiots thinking?"


The mystery of `Ireland's worst driver' (Power, RISKS-25.56)

David Cantrell <d.cantrell@outcometechnologies.com>
Fri, 20 Feb 2009 15:23:15 +0000

"Max Power" wrote:

> Ultimately, in Greater Europe (from Vladivostok to Iceland to Saint Helena)
> the traffic-oriented part of the police forces must be trained in knowing
> all the variants of driver's permits in their region.

Within the EU, the layout of drivers' licences is standardised.  So even if
you don't know the Polish or Finnish or German or whatever for "name" and
"surname" you can still tell which fields they are.

Here are licences from Germany, the UK, and Poland:

http://www.bundesdruckerei.de/pics/produkte/fuehrerschein/fuehrerschein_front_internet.jpg
http://www.day-tripper.net/xzi/xphotodriving-licence.jpg
http://www.eng.pwpw.pl/rep/f39/r48/min_prawo_jazdy.jpg

Fields 1 and 2 are surname and forename.

There are, of course, still some people driving around with old
pre-standardisation licences, and I don't know how far along the road to
standardisation Ireland is, but Irish police should already be familiar with
the layout, as it's already commonly used elsewhere.

David Cantrell, Outcome Technologies Ltd, BUPA House, 15-19 Bloomsbury Way,
London WC1A 2BA ENGLAND  Registered in England, No: 3829851


Re: Opening event goes with a bang (Alexander, RISKS-25.56)

Mark Brader
Thu, 19 Feb 2009 22:58:10 -0500 (EST)

Well, it's not the first time a ceremonial opening has turned lethal.
Look up how William Huskisson died in 1830; there must have been others.
Destroying the building as well is a nice touch, though.

Mark Brader, Toronto  msb@vex.net


Re: Risks of reading RISKS (Horrocks, RISKS-25.56)

<jidanni@jidanni.org>
Fri, 20 Feb 2009 10:44:34 +0800

BH> For example, hands up how many of you read "390,000 to access child
BH> database ... of all under 18 year-olds in England" and assumed that
BH> this means all 390k have full access to the whole database?

Ah, [It will cost one] 390,000 [British pounds] to access the child database...
wherein the "pounds" symbol is not ASCII and went bye-bye... :-)

  [Noted in the archive copy of 25.56 as well.  PGN]


Re: Risks of reading Risks (Horrocks, RISKS-25.56)

Martyn Thomas <martyn@thomas-associates.co.uk>
Fri, 20 Feb 2009 10:26:05 +0000

Most RISKS readers understand that the risks from improper access to data
involve the nature of the data, who has access to it, and what they can do
with it.

For example, if access to the child database were limited to those in the
geographic area where the child data subject lived, it would greatly reduce
the number of people who had access to any particular child's data, without
significantly reducing the risk to children from the data being abused - as
most abuses would involve people who know or have access to the child, and
most of these will be in that geographic area.

Martyn Thomas CBE FREng  http://www.thomas-associates.co.uk


Re: Risks of reading RISKS (Horrocks, RISKS-25.56)

Scott Miller <SMiller@unimin.com>
Fri, 20 Feb 2009 09:10:44 -0500

It might also be helpful if those who appear to be claiming that a
submission is inaccurate, incomplete, or misleading would supply some
specific information regarding the perceived deficiencies.  Otherwise a RISK
exists of evoking an analogy involving cooking vessels.  Is Mr.  Horrocks
stating that the 390,000 did *not* have full read access to the entire
database?  In that case, what are some examples of the limitations?  If that
access was limited, did the limitations meaningfully restrict access to all
government employees who might be careless enough to leave it laying about
unprotected on a laptop or portable media (of course this would be
unprecedented in the UK)?  Was it restricted to all (hypothetical)
government-employed pedophiles in such a way as to protect the vital
information of the children from would-be predators?  The only statement
regarding access that I find in the article cited by A. Shapir is from
Minister Morgan, "For someone fleeing domestic violence for example it is
important we make sure the ContactPoint directory can shield in some way."
Coming from someone who should be thoroughly familiar with whatever
confidentiality measures are planned, had I the welfare of such a child
entrusted to me, I would find that example of vague bureaucrat-speak more
distressing than reassuring.  As a long-time RISKS reader, I am convinced
that the choice made to submit the incident with only those facts that were
available was consistent with established RISKS practice, and the correct
decision.  Some risks are adequately and succinctly self-defining by
description, and I believe this is an example.  I'm also pretty certain that
my comment clearly indicated my additional perceived risk (albeit somewhat
sarcastically): assuming that government regulations, employees, and systems
exist solely to serve the public interest and typically succeed in that
endeavor.

Please report problems with the web pages to the maintainer

x
Top