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 24 Issue 01

Wednesday 10 August 2005

Contents

Russian remote controlled submarine failure
Martyn Thomas
Caltrans screwup
PGN
Lightning causing problems for lightning-detection system
Klaus Johannes Rusch
PGN
Navy jet has severe brake failure
PGN
US Navy to drop paper charts
Scott Peterson
PGN
Scott Peterson
Social Security Administration sends cards to the wrong place
Jonathan Kamens
German social services software drops changes
Debora Weber-Wulff
Hermann Chinery-Hesse and software in Ghana
James H. Haynes
Greeting answering machine!
R H Draney via Mark Brader
Every odd digit of number A, even digit of number B
Dan Jacobson
The risks of cell-phone auto-spellers
William Colburn
Credit-card obfuscation
William Colburn
Re: Car computer systems at risk to viruses
Adam Laurie
Re: Increasing sophistication of phishing spammers
Jonathan de Boyne Pollard
Re: Timezones and appointments
Sean Smith
Przemek Klosowski
Re: New Microsoft anti-piracy program circumvented
Peter Gregory
REVIEW: "File System Forensic Analysis", Brian Carrier
Rob Slade
Info on RISKS (comp.risks)

Russian remote controlled submarine failure

<"Martyn Thomas" <martyn@thomas-associates.co.uk>>
Tue, 9 Aug 2005 15:00:12 +0100

A British Royal Navy remotely operated vehicle cut free the Russian
submarine that was trapped 600 feet down. According to the British commander
of the rescue, interviewed by BBC Radio 4 on 8 Aug 2005, the Russians had
remote controlled vehicles of their own, but they failed because of a
software error.


Caltrans screwup

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 8 Aug 2005 15:58:55 PDT

Lauren Weinstein reported that Caltrans has started a 6-month experiment to
put real-time travel times on freeway signs.  The immediate result is
apparently that traffic is tied up all over, as people slow down to read the
signs!


Lightning causing problems for lightning-detection system

<Klaus Johannes Rusch <KlausRusch@atmedia.net>>
Wed, 03 Aug 2005 01:26:42 +0200

Fortunately there were only a few minor injuries when a plane overshot a
runway at Pearson International Airport.  According to a CBC report
(http://www.cbc.ca/story/canada/national/2005/08/02/pearson-plane050802.html)
most operations on the airport had been suspended due to bad weather: "... a
spokesperson with the Greater Toronto Airports Authority said lightning was
causing technical problems with the airport's lightning-detection system."
Why would one expect that lightning-detection systems could cope with
lightning?

Klaus Johannes Rusch  KlausRusch@atmedia.net http://www.atmedia.net/KlausRusch/


Lightning causing problems for lightning-detection system

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 3 Aug 2005 14:59:40 PDT

My favorite meta-lightning event occurred was when I was giving a lecture in
my Survivable Systems course at Maryland, and I was talking about the time
at Wallops Island where they had several missiles ready to launch because
they wanted to study the effects of lightning on the missile controls.  As
some of you may remember, lightning hit the launch platform and triggered
the launching of one of the missiles (which I mentioned most recently in
RISKS-20.42).  Just at that point in the lecture, lightning hit the lecture
room and took down the computer controlling the outfeeds to remote
classrooms and our own video monitors.  Some of the students wondered how I
had managed such a theatrical effect.


Navy jet has severe brake failure

<"Peter G. Neumann" <neumann@csl.sri.com>>
Fri, 5 Aug 2005 11:22:36 PDT

The F/A-18 Hornet has had a series of recent accidents many of which are
being attributed to a very thin $535 electrical cable that controls the
antiskid brakes.  An investigation also concluded that cockpit procedures
were confusing when pilots were confronted with brake failures.  The
U.S. military owns 561 Hornets, best known for their use by the Blue Angels.
[Source: AP report, 4 Aug 2005; PGN-ed]
http://www.rednova.com/news/general/197786/ap_navy_jet_has_severe_brake_problems/


US Navy to drop paper charts

<Scott Peterson <scottp4@mindspring.com>>
Wed, 03 Aug 2005 00:51:24 -0700

Given some of the stories that have been posted here about the problems with
electronic navigation systems, the mind boggles at the potential for
disaster in this decision.  [SP]

The U.S. Navy has committed to replacing its traditional paper nautical
charts with advanced, interactive, electronic navigation systems throughout
the fleet.  The Electronic Chart Display and Information System - Navy is
based on the voyage management system software programs developed by
Northrop Grumman's Sperry Marine business unit, and operates with digital
nautical charts -- a global database of digital charts produced by the
National Geospatial Intelligence Agency.  The Navy plans to equip the entire
fleet of surface ships and submarines with Ecdis-N by the end of 2009,
and no longer use paper charts after the electronic system is certified.
[Source: Lloyds List, 2 Aug 2005; PGN-ed]


Re: US Navy to drop paper charts

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 3 Aug 2005 14:55:04 PDT

Risks might occur when their Net connection is down and they cannot get
their updated maps online!  Remember the sub that ran into a rock.  I wonder
whether that rock has ever shown up on an online map since then?


Re: US Navy to drop paper charts (RISKS-23.96)

<Scott Peterson <scottp4@mindspring.com>>
Wed, 03 Aug 2005 17:38:50 -0700

>  I wonder whether that rock has ever shown up on an online map since then?

Actually part of the report on why that happened was because they were using
the wrong paper charts and were not updating them properly.  The correct
charts did show a navigation hazard in that area.
  http://navysite.de/ssn/ssn711.htm

On 9 May 2005, the Navy announced the completion of the investigation into
the accident. The report states that "The findings of fact show that SAN
FRANCISCO, while transitting at flank (maximum) speed and submerged to 525
feet, hit a seamount that did not appear on the chart being used for
navigation," and that "Other charts in SAN FRANCISCO's possession did,
however, clearly display a navigation hazard in the vicinity of the
grounding. SAN FRANCISCO's navigation team failed to review those charts
adequately and transfer pertinent data to the chart being used for
navigation, as relevant directives and the ship's own procedures required."
The report continues "If SAN FRANCISCO's leaders and watch teams had
complied with requisite procedures and exercised prudent navigation
practices, the grounding would most likely have been avoided. Even if not
wholly avoided, however, the grounding would not have been as severe and
loss of life may have been prevented."


Social Security Administration sends cards to the wrong place,

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Sun, 7 Aug 2005 22:30:35 -0400
  won't admit it's due to buggy software they need to fix

The following is the introduction to
http://www.mit.edu/~jik/ssa-zip.html
-- which tells the whole story in sordid detail.

		      * * * * * * * * *

The software that the Social Security Administration (SSA) uses to
canonicalize mailing addresses when sending out social security cards has a
bug which causes correct ZIP codes in some addresses to be replaced with
incorrect ZIP codes.

This bug has been present for at least five years and has caused the social
security cards for three of my children to be "lost" in the mail after their
births.

The first two times this happened to me, the SSA resent a duplicate card
when I contacted them and complained that the original had never arrived.

The first two times this happened to me, the SSA refused to investigate why
the original card never arrived.

The third time this happened to me, I finally convinced the SSA to
investigate, and the bug was exposed.

The SSA refuses to admit that the behavior of their software is a bug,
despite the fact that any competent software engineer familiar with
address-canonicalization technology would understand immediately that it is
after being given a test case illustrating it.

The SSA refuses to issue a duplicate card for my youngest child unless I
file a form SS-5, which requires that I either (a) send original, personal
identification documents through the mail, which I am unwilling to do
because of concerns about identity theft and document loss, or (b) submit
the form SS-5 in person at one of their offices, which I am unwilling to do
because I think it's entirely unreasonable for me to have to miss work to
correct the SSA's error.

The SSA has already admitted that my youngest child's card was lost in the
mail and that they know why this happened. They've been corresponding with
me at the address to which the card was supposed to have been sent, which is
in their records, which means that they know for a fact that I am the father
of the child whose card was lost and that I am legally allowed to receive a
copy of the card. That they nevertheless refuse to issue a duplicate card
has no legitimate justification and can be explained only as bureaucratic
inertia or a stubborn refusal to admit fault.

		      * * * * * * * * *

If there is anyone reading this who works for or has connections at the SSA
and who has the knowledge and experience to understand the bug I'm trying to
get them to fix (I've yet to reach anyone at the SSA who has admitted to
understanding it), please help!


German social services software drops changes

<Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>>
Tue, 09 Aug 2005 12:23:38 +0200

http://www.heise.de/newsticker/meldung/62595

The online computer news service heise.de reports that an error in the
software system A2LL, which computes welfare and jobless subsidies as well
as administering the system, has dropped over 100.000 changes that should
have been reported to health insurance providers.

New registrants, people going off welfare, address changes and the like were
registered with the system and then the changes were automatically
rescinded.

The error cropped up after a new version of the software was installed on
the central servers. [Perhaps they installed a test system by mistake that
just pretends to accept changes? -dww]

The missed changes will not affect the insurance status of the people
involved, but staff at the insurance companies must take care of all of the
changes by hand.

Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik
10313 Berlin  +49-30-5019-2320  http://www.f4.fhtw-berlin.de/people/weberwu/


Hermann Chinery-Hesse and software in Ghana

<jhhaynes@earthlink.net>
Tue, 9 Aug 2005 13:58:34 -0500 (CDT)

There is an interesting article in the August 2005 issue of IEEE Spectrum
on the above subject.  Mr. Chinery-Hesse runs a very successful software
business in Ghana.  Some of the high points:

* Software that is lean and efficient, so it runs well on old PCs such as
  386/486.  These are affordable in Ghana.
* Software design for robustness under third-world conditions.  For example,
  frequent writes to disk to minimize work lost of the power goes off, as it
  frequently does.
* Rather extreme measures to protect proprietary software, such as updates
  installed in personal visits by software company employees.  This to cope
  with conditions in a country where any sense of ethics is practically
  nonexistent.
* Shunning of open source software, on the grounds that having the source
  makes it too easy for unscrupulous users to modify the code so as to line
  their own pockets.

This last item could well be criticized as security through obscurity.
Surely the incentives are there for users to make a considerable effort to
tamper with closed source proprietary software.  One could argue that open
source software would be easier to audit for unauthorized modifications.
But then who audits the auditors?  And how can they be sure that the code
actually running in the machine is accurately represented by the source code
they can see.

This suggests a larger research topic: how can we make computer systems that
are guaranteed to "work right" when they are to be installed in a den of
thieves?  Seems like this has applicability to the problem of electronic
voting systems in the U.S.


Greeting answering machine! (R H Draney)

<msb@vex.net (Mark Brader)>
Mon, 8 Aug 2005 01:56:48 -0400 (EDT)

* From: R H Draney <dadoctah@spamcop.net>
* Newsgroups: alt.usage.english
* Subject: Re: greeting answering machine!
* Date: 6 Aug 2005 18:40:47 -0700
* Message-ID: <dd3oqv02rdc@drn.newsguy.com>

Tony Cooper filted:

> I am unconventional, though.  Just yesterday I called a doctor's office
> and told them they'd left a message on my machine that was intended for
> someone else.  Neither my (first) name nor number registered with the
> person in the doctor's office that left a message that "my" appointment
> had been canceled because the doctor would be out-of-town.  I thought it
> was the considerate thing to do.

My mother has been getting a series of calls from some lawyer's office in
North Carolina, telling her (or rather someone whose name is unintelligible
on the message) to call back at such-and-such a number...she's tried calling
the number several times and they always start off by asking her to punch in
her case number...as she has no case to number, the attempt to straighten
out these people ends there, with (1) some lawyer's client wondering why his
counsel hasn't called him, (2) the lawyer raising the penalty to the next
level for failing to make contact, and (3) my mother getting more and more
recorded messages....r


Every odd digit of number A, even digit of number B

<Dan Jacobson <jidanni@jidanni.org>>
Thu, 04 Aug 2005 07:55:26 +0800

The Taiwan telephone company has done it again. On their work order
notification they only show every odd digit of the phone number to be
serviced, 2*8*4*8*, and then for extra security, only every even digit of
the contact number, *5*5*7*0. But if contact number == phone number, all is
revealed, 25854780.


The risks of cell-phone auto-spellers

<"Schlake (William Colburn)" <schlake@nmt.edu>>
Thu, 4 Aug 2005 15:24:23 -0600

(my phone made me look like an idiot)

The first time I tried sending an SMS message on my new phone, I was
horrified at what happened.  Attempts to type in a word generated huge
blocks of garbage text, beeping, and a refusal of the phone to continue.  I
was trying to do it the "old way", by hitting a key multiple times to tell
which of the three letters I meant.

"That would make me happy." -> "8442809666885553062553304427 79991"

The space represents a pause in my typing to wait for it to reset the letter
selector.  The new phone has smart spelling, so I can type a single number
for each word and it will magically spell the word I want.  I resisted, but
the lure of magic won me over, and now I can SMS faster with many less key
strokes.  I'm very happy with it almost all the time.  Magic is great stuff!

Today I sent an SMS message.

"That would make me happy." -> "8428096853062530630427791"

Except....

"8428096853062530630427791" -> "That would make if happy."

My cat is named "If", so now it suddenly looks like I'm talking about my cat
(and I misspelled his name), and not me.

I immediately sent a followup message where I manually corrected the
spelling of "me" and appended a second sentence: "I have to pay more
attention to the auto speller."

The reply was: "You mean pay more attention."

First thought: Oh no, what I did I send?  Thankfully, I only sent "I must
pay more attention to the auto speller."

It is embarrassing that I made the same error in my message correcting
myself.  The risks are that magic isn't a DWIM.  If the phone could 'do what
I meant' then I could talk to my phone in plain english to transmit my
message to someone halfway across the country[1], and not have to manually
type my message into it.  Another risk is complacency: I have grown to
depend on auto-spelling, which is right so often that I've stopped reading
what it is doing and I just continue merrily typing away assuming that
everything is golden.

[1] I find it surprising how many people I know who consider their phone to
be a text-messaging platform that happens to have voice-chat capabilities
instead of a voice-chat platform that happens to have text-messaging
capabilities.


Credit-card obfuscation

<"Schlake (William Colburn)" <schlake@nmt.edu>>
Tue, 9 Aug 2005 10:24:29 -0600

I made a purchase from Bibliomania! today.  I wasn't able to get the book I
wanted through either amazon.com or ecookbooks.com, so I used the site
suggested by the author of the book.  I'm pretty mistrustful of online
merchants, but this one had an SSL page for the credit card info and I
really wanted the cookbook, so I went for it.  The confirmation page that
came up, that it encouraged me to print, obfuscated my credit card number by
"x"ing out the last four digits.

The risk is that the last four digits are normally the ones not "x"ed out by
every other credit card processor that I've ever seen, so this confirmation
plus any other confirmation gives you 20 digits of a 23 digit credit card
number, and most places don't ask for the last 3 digits yet (card number
yyyy yyyy yyyy yyyy expires yy/yy series zzz is 23 numbers).

Thankfully the unencrypted confirmation e-mail they sent didn't mention
anything about the credit card at all, and it came in plain text and not
HTML.

  [Note: PGN changed occurrences of "x" to y and z, to avoid filtering.]


Re: Car computer systems at risk to viruses (RISKS-23.96)

<Adam Laurie <adam.laurie@thebunker.net>>
Tue, 09 Aug 2005 11:19:13 +0100

Car kits are not only vulnerable to viruses, but also to privacy invasion
through eavesdropping of audio via the telephony microphone, as well as
social engineering attacks or simple 'nuisance calls' by pushing audio into
the car speaker systems... The proof-of-concept tool "Car Whisperer" can be
found here, along with more details of the attack:

   http://trifinite.org/trifinite_stuff_carwhisperer.html

Adam Laurie, The Bunker Secure Hosting Ltd., Shepherds Building, Rockley
Road, London W14 0DA UK  http://www.thebunker.net  +44 (0) 20 7605 7000


Re: Increasing sophistication of phishing spammers (Wallach, RISKS-23.60)

<Jonathan de Boyne Pollard <J.deBoynePollard@Tesco.NET>>
Wed, 15 Dec 2004 20:47:28 +0000

W> ... should pay attention to referrer information to refuse images being
W> sent to pages other than their own.

Checking referrer headers at the content HTTP server is not necessarily the
wisest course of action.  It is easy to do wrongly, has maintenance problems
for the publisher, and is conceptually shaky as well.  And it isn't
addressing the issue actually at hand, in any event.  The far better way to
address the issue at hand is one that many people have been advocating for
quite some time now, for this and other reasons: ensure that all MUAs are
designed *not to automatically fetch external content* when displaying
messages (with body parts of any sort, not just "text/html", moreover).

<URL:http://homepages.tesco.net./~J.deBoynePollard/Proposals/gnksoa-mua.html#NoAutoFetchExternalContent>

The RISK?  Thinking that RFC 2017 is a good idea.  (-:

I'm not aware of anything as detailed as the GNKSoA and the GNKSoA:MUA for
web browsers and HTML display engines, but were there one, one of my
suggestions for inclusion in it, that pertains here, would be the display of
(CIS) URLs broken-down into their component pieces, preventing the confusion
between domain parts and usernames that is often also exploited by these
electronic mail scams.

W> Probably the only true answer is for eBay, my credit card company,
W> and all of these other vendors to start digitally signing their mail.

It is interesting to note how many of these same companies make a point of
noting that they provide end-to-end validation when one is accessing their
web sites (For the case of eBay, for example, see
<URL:http://pages.ebay.com./securitycenter/avoiding_fraud.html#secure>.),
and yet fail to do the same thing for their electronic mail communications.

However, one should always bear in mind that the architecture of SMTP-based
Internet electronic mail is the architecture of paper mail.  The former is
simply, and solely, cheaper ("There are fewer electrons in an electronic
mail message than in a sheet of paper.  So it's cheaper by weight."),
allowing the architectural flaws to be revealed more readily.  Digital
signatures *are* the tool for determining whether a message came from whom
it purports to have come from.  However, look at paper mail and consider:
When you last received a paper communication from such a company, was it on
mass-printed stationery with a computer-printed copy of someone's signature
at the end?  How did you know that that was the correct signature?  What
steps did you take to validate it?  Do you even know what the person's
correct signature is supposed to look like?  When you next contacted the
company, did you use the contact information (telephone number, et al.)
supplied at the bottom of such a letter?  When you telephoned the company's
customer account line using the telephone number from the letter, did you
supply your account number and password to the complete stranger on the
other end of the line?


Re: Timezones and appointments (Rothwell, RISKS-23.96)

<Sean Smith <sws@cs.dartmouth.edu>>
Wed, 3 Aug 2005 19:22:52 -0400

I've had the inverse happen: a timer program that allows me to turn my
laptop into an alarm clock insisted on working according to the local time
back home in the US, rather than local time in the UK where I was---even
though the system time zone had been changed to the UK.

Sean W. Smith, Ph.D.  sws@cs.dartmouth.edu  www.cs.dartmouth.edu/~sws/
Department of Computer Science, Dartmouth College, Hanover NH USA


Re: Timezones and appointments (Rothwell, RISKS-23.96)

<przemek klosowski <przemek.klosowski@gmail.com>>
Thu, 04 Aug 2005 22:36:27 -0400

I suspect that Nr. Rothwell stored the appointments for his US trip in US
local time values, but didn't tell that to the computer. Consequently, the
PDA assumed that he meant UK times, and shifted the values.

My left or your left? or rather, my 6 PM or your 6 PM? Most people would
raise this issue when setting an appointment across time zones. What we need
is a good user interface that allows, but doesn't always force us, to
specify the time zone in which the event is being entered. Perhaps the UI
should put up a time zone wizard if it matches "airport,flight,travel,etc."
among proximate events.


Re: New Microsoft anti-piracy program circumvented (RISKS-23.95)

<Peter Gregory <petergregory@yahoo.com>>
Wed, 3 Aug 2005 12:25:54 -0700 (PDT)

In my opinion, the most amazing part is that Microsoft DOES NOT CONSIDER
THIS TO BE A SECURITY FLAW.  Will they respond in like manner when large
numbers of cars fall victim to the first wide-spreading, car-infecting worm?

Peter Gregory, CISA, CISSP, Chief Security Strategist,
VantagePoint Security LLC, Bellevue, WA  phg@vantagepointsecurity.com

  [Source: Hackers break into Microsoft's anti-piracy system.  PGN]
  http://www.techworld.com/security/news/index.cfm?NewsID=4134


REVIEW: "File System Forensic Analysis", Brian Carrier

<Rob Slade <rslade@sprint.ca>>
Mon, 8 Aug 2005 08:09:38 -0800

BKFSFRAN.RVW   20050608

"File System Forensic Analysis", Brian Carrier, 2005, 0-321-26817-2,
U$49.99/C$69.99
%A   Brian Carrier
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   2005
%G   0-321-26817-2
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/0321268172/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0321268172/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321268172/robsladesin03-20
%O   Audience a- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P   569 p.
%T   "File System Forensic Analysis"

The preface states, correctly, that there is little information for
the forensic investigator on the topic of file system structures and
internals that are useful for providing direction on tracing and
tracking information on the disk.  The author also notes that there
are a number of worthwhile texts that address the general topic of
investigation.  Therefore, the author intends to address the former
rather than the latter.  At the same time, there is an implication in
the initial section that this work is only the merest introduction to
the subject of computer forensics.

Part one is aimed at providing foundational concepts.  Chapter one, in
fact, does provide a quick review of the investigation process, and a
list of forensic software toolkits.  A sort of "Computers 101" is in
chapter two, with a not-terribly-well structured collection of facts
about data organization, drive types, and so forth, with varying
levels of detail.  Chapter three addresses different factors and
problems in hard disk data acquisition, although the inventory is
neither complete nor fully explained.

Part two deals with the analysis of drive volumes or partitions, with
chapter four outlining basic structures.  DOS (FAT [File Allocation
Table] and NTFS) and Apple partition details are discussed in chapter
five.  Chapter six reviews various UNIX partitions.  Multi-disk
systems, such as RAID (Redundant Array of Inexpensive Disks) are
covered in chapter seven.

Part three delves into the data structures of the file system itself.
Chapter eight introduces concepts used in considering file systems.  Details
of the FAT system are in chapters nine and ten.  A very detailed explanation
of the disk and file structures of the NTFS system, as well as
considerations for analysis, is provided in chapters eleven to thirteen.
The Linux Ext2 and Ext3 structures are discussed in chapters fourteen and
fifteen.  Chapters sixteen and seventeen cover the UFS1 and UFS2 schemes,
found primarily in BSD (Berkeley Systems Distribution) derived versions.

This book does provide a wealth of detail, once it gets into the
specifics of partitions and structures.  The introductory material,
writing, and technical level are quite uneven, which makes it
difficult to use.  Still, those seriously involved with the data
recovery aspect of digital forensics should consider this work a
valuable resource.

copyright Robert M. Slade, 2005   BKFSFRAN.RVW   20050608
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer