The RISKS Digest
Volume 22 Issue 03

Monday, 15th April 2002

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

Bank merger in Japan causes numerous problems
Jeremy Epstein
Online banking system failure in a big way
Ishikawa
Computer crime way up, says FBI
NewsScan
Can you trust a "trusted traveler"?
NewsScan
SMS, Net voting to be used in local UK elections in May
Anura Samara
Patient overflow avoided: P1M, not Y2K
David Shaw
More UK air traffic control failures
Mich Kabay
Interface simplification
Devon McCormick
Re: Just because it's funny doesn't mean it isn't real
Michael Walsh
Achim Nolcken Lohse
Re: When is fail-safe not fail-safe?
Anthony W. Youngman
Is your e-mail watching you?
Stefanie Olsen via Monty Solomon
The Risks of using the wrong address
Dan Birchall
Re: Yahoo Groups spam alert
Jim Horning
Ray Bradbury's Fahrenheit 451, revisited
Marc Rotenberg
REVIEW: "Hacker's Challenge", Mike Schiffman
Rob Slade
Info on RISKS (comp.risks)

Bank merger in Japan causes numerous problems

<"Jeremy Epstein" <jepstein@webmethods.com>>
Mon, 8 Apr 2002 14:52:15 -0400

Three of the twelve largest banks in Japan merged.  The results weren't
pretty, including "more than 30,000 transaction errors and 2.5 million
delayed debits" and "2.5 million of the 3 million automatic debits scheduled
to be processed on 1 Apr 2002, including utility and credit card bills,
couldn't be made on that day".

The problem was that each of the banks ran a different system (Hitachi, IBM,
and Fujitsu, although no software was mentioned).  They build some
integration glue, but it didn't work.

http://www.computerworld.com/storyba/0,4125,NAV47_STO69943,00.html


Online banking system failure in a big way

<Ishikawa <ishikawa@yk.rim.or.jp>>
Sat, 06 Apr 2002 18:16:32 +0900

This news seems to be reported over foreign wire services, and so may have
been reported already but here it goes in any way.

Japan's Mizuho Financial group that operates the Mizuho Bank, which has been
born out of the merger of three large banks, Dai-Ichi Kangyo bank, Nihon
Kogyo bank, and Fuji bank, has started its merged new operation starting on
1 Apr 2002.  (There is also another holding bank, but the Mizuho bank is the
one where ordinary people have accounts carried over from the three banks.)

Since that day, the online banking transaction system of the new bank has
been plagued with problems.  On 1 Apr, the ATM malfunctioned and many users
of the new bank could not withdrawal or deposit money. That continued until
the next day.

I thought this was a labor pain often found in a new operation, but no the
problem persisted and the cause seems to run much deeper than I originally
thought.

Now for the last few days, the online banking transactions for payment of
utility bills such as gas, electricity, water, and credit company payments
are delayed heavily due to problems of unknown cause.

This morning's Asahi Shimbun newspaper (Yokohama edition) carried a top
article that stated the management of Mizuho FG admitted the back log of
transactions amounts to more than 2.5 million.

About three million such payments expected to take place on the 1 Apr
could not be finished on time and 105,000 transactions remains unfinished
even as of 5 Apr. The delay affected the subsequent processing of other
transactions and the unfinished count exceeded 2.5 million on April 5th.
(The fifth day of each month is the payment day of credit companies and thus
there were many transactions to take place yesterday.)

About 30,000 incorrect double withdrawals, and about 5,000 double deposits
were found and corrected.  (Not all of them, it seems, to the evening NHK
news I just heard.)

According to the bank, the current accumulation of delayed transaction would
need the whole next week to finish.

The completion notification of utility bills payment to utility companies is
also delayed very much.  Such delayed notices are believed to be more than 5
million cases.  (It seems as if the bank don't know exactly the status of
the payment...)

The bank management admitted that although they have tested the integrated
online transaction systems many times before the complete merger and the
start of operation on 1 Apr, their expectation of the workload was not
accurate enough.  (Above is my own translation.)

Since many Japanese companies have its fiscal year ends at the end of March,
and starts a new fiscal year in April, the Monday being the first week day
of April had more workload than expected according to the statement found in
the newspaper article.

I noticed that the three banks closed the banking systems on Friday evening
of the previous week and so I thought they took the time to move to the
unified operation smoothly.

But, after the fact, some articles in newspapers suggested the previous
testing period of the whole merger and unified operation was not long enough
for the large scale operation at all.  Also, there seems to have been a long
period of discussion as to how the operations were to be unified and thus
the implementation period became shorter than expected.  Dai-ich Kangin used
Fujitsu, Fuji used IBM, and Nihon Kogyo used Hitachi computers.  The unified
system seems to have been designed by Hitachi. The computes seem to be the
mainframe UNIX types. As of now, it is not clear where/whether the problem
lies in the integrated system hardware components and vendor supplied
software or is in the application programmed by Mizuho.

I have an account at Dai-ichi and so is now a Mizuho customer.  One solace
is that the bank responded to the customer concern quickly and opend
telephone hot line to track one's payment status, etc.. I have not tried the
telephone number yet.  The bank stated publicly it will cover the cost
incurred due to the delayed transactions. A big financial loss to the bank,
I guess.

A failure in a spectacular manner. This will remain in Japanese banking
history.


Computer crime way up, says FBI

<"NewsScan" <newsscan@newsscan.com>>
Mon, 08 Apr 2002 09:19:51 -0700

Eighty-five percent of respondents report having been victims of computer
crime, costing them millions of dollars, according to a survey by the
Computer Security Institute and the FBI. The study, which polled 583
computer security experts in business, government agencies, medical
institutions and universities, concluded that the most serious losses
stemmed from theft of proprietary information. In addition, almost all of
the organizations had suffered from computer virus attacks last year, and
90% said they had been victims of Web site defacement in 2001, up from 64% a
year earlier. "Organizations that want to survive in the coming years need
to develop a comprehensive approach to information security, embracing both
the human and technical dimensions," says Patrice Rapalus, director of the
Computer Security Institute. In response to the growing threat of
cybercrime, the FBI has set up the National Infrastructure Protection Center
and has formed regional Computer Intrusion Squads in several offices
throughout the U.S.  [BBC Online 8 Apr 2002; NewsScan Daily, 8 Apr 2002]
http://news.bbc.co.uk/hi/english/sci/tech/newsid_1916000/1916655.stm


Can you trust a "trusted traveler"?

<"NewsScan" <newsscan@newsscan.com>>
Tue, 09 Apr 2002 09:32:41 -0700

One proposal for improving airport security has been the creation of
hard-to-counterfeit "trusted traveler" ID cards for frequent travelers, but
software developer Richard P. Eastman asks the obvious question: "What makes
a trusted traveler? The guy who travels all the time; who travels on
business; who has a reason to travel. Does that mean the terrorist can't
penetrate that group? Of course he can." Beyond objections of that sort,
civil libertarians have been arguing that ID cards for travelers will set a
dangerous precedent. Barry S. Steinhardt of the American Civil Liberties
Union predicts, "Quickly enough, policy makers are going to say, 'If this
works, let's require everyone to go through background checks before they get
on a plane.'" [*The New York Times*, 9 Apr 2002; NewsScan Daily, 9 Apr 2002]
  http://www.nytimes.com/2002/04/09/technology/09PASS.html


SMS, Net voting to be used in local UK elections in May

<Anura.Samara@facs.gov.au>
Wed, 10 Apr 2002 09:30:54 +1000

Local U.K. governments in Liverpool and Sheffield are gearing up to allow
citizens to vote using SMS (Short Message Service) text messages and the
Internet in elections 2 May 2002.

  [http://www.computerworld.com.au/idg2.nsf/All/E7E9EB212B30B99FCA256B960079B1B2!OpenDocument&NavArea=Home&SelectedCategoryName=News]


Patient overflow avoided: P1M, not Y2K

<"David Shaw" <David.Shaw@itvworld.com>>
Wed, 10 Apr 2002 09:00:22 +1000

The 2 Apr 2002 edition of *The Australian IT* (australiait.com.au) ran a
story about the Royal Children's Hospital in Melbourne, Australia.

They've just finished upgrading their patient administration software. The
software hasn't yet replaced the need for paper records but provides the
foundation to do so. It uses a browser front-end.

Four years in the implementation, one of key drivers was the old software
was unable to support patient numbers of more than six digits. The software
went live on February 11. The 1,000,000th patient arrived in March.


More UK air traffic control failures

<Mich Kabay <mkabay@compuserve.com>>
Wed, 10 Apr 2002 08:50:06 -0400

On 10 Apr 2002 at 0605 BST, air-traffic control computers failed at the West
Drayton control center near Heathrow Airport, causing subsequent failures at
the control center in Swanwick, Hampshire.  Disruptions lasted up to two
hours, with controllers working by hand to track planes.  According to a BBC
report http://news.bbc.co.uk/hi/english/uk/newsid_1920000/1920527.stm this
is the second breakdown in ATC in Britain in two weeks.  Although the
current failure is being attributed to "creaky" old systems that are
unstable, the previous incident was attributed to a data-input error.

  [Comments from MK: The comment on data-input error conveys a belief that
  having a system crash because of incorrect inputs is understandable and
  acceptable.  It isn't.  Good design includes edit checks on inputs,
  especially inputs that can cause kernel panics.  When there are forbidden
  combinations of inputs, table-driven checks can exclude such combinations
  before they are sent for further processing.]

M. E. Kabay, PhD, CISSP — AssocProf Information Assurance
Dept CompInfoSys, Norwich University, Northfield VT
http://www2.norwich.edu/mkabay/index.htm


Interface simplification (was Re: Computers to Cars)

<Devon McCormick <devonmcc@yahoo.com>>
Fri, 5 Apr 2002 09:17:35 -0800 (PST)

An example of the risk of "simplifying" an interface: while on vacation
recently, I rented a new-model car. One reason I rented it was to take my
daughter to a drive-in movie since these are rapidly disappearing and I
wanted her to have this experience.

This drive-in, in Tucson, Arizona, does not have the speakers you attach to
your car window.  Instead, you tune your radio to a specified FM channel to
get the sound for the movie.

As I started up the car to drive to the movie that night, I noticed that the
headlights came on by themselves, presumably because it was dark out.  We
got to the movie, parked, found the radio station with the movie's
soundtrack, and discovered that there is no way to turn off the headlights
while keeping the power on to the radio!

One can imagine the (overly) clever engineer thinking "why would anyone want
to sit in a car with the lights off and the power on?"  Whereas some of us
could come up with at least a couple of reasons for doing this, evidently
Detroit isn't that imaginative.

Devon H. McCormick, CFA  devon@acm.org


Re: Just because it's funny doesn't mean it isn't real

<Walsh Michael <michael.walsh@wmdata.fi>>
Fri, 5 Apr 2002 11:50:44 +0300

Like Donald A. Norman, BMW's announcement of their intelligent 7 Series sent
a shiver up my back.

In my case this was based on my experiences with an early version of one of
their intelligent cars (a 1986 520 injection I was still using in 2001).

When BMW transfered (in connection with the Rover disaster) their dealership
in Finland to a different company, they lost all expertise among their
mechanics of the era before "computer-based" maintenance. This led to such
funnies as my car refusing to start once in the middle of summer after a
break of about 10 minutes in use; then me getting it to start after a couple
of hours of leaving it alone and taking it to the dealership only to be told
that by starting it it meant they were unable to download the details of why
it went wrong.

What should I have done ? Bring it immediately next time the same thing
happens. I then pointed out that this meant waiting to be stranded and
getting a tow truck. Yes, they replied.

The very next day, that did in fact happen and I was towed all the way to
the BMW dealership who then discovered that my model didn't have this
download functionality as it was too old ...

You can perhaps see why relying on a BMW's intelligence is not appealing !

(A further funny was with the BMW extra I bought in Germany to enable me to
pre-warm the car before using it. You set a clock in the car to the time
this pre-warming should start (using petrol from the tank) and it warms the
motor and inside of the car until you get into it. This worked perfectly
when the temperature was around zero but at a few degrees less refused to
click into action - not much use in Finland then. On the other hand at
temperatures at around +25 degrees Centigrade it did jump into operation
when you were driving along (and were in desperate need of more heat, NOT
!)! )

Mike Walsh, Helsinki, Finland  englantilainen@hotmail.com


Re: Just because it's funny doesn't mean it isn't real (RISKS-22.02)

<"Achim Nolcken Lohse" <lohse@rockies.net>>
Sat, 6 Apr 2002 02:00:59 -0700

Volkswagen has also thrown prudence to the winds in its rush to adopt high
tech.

We bought a 2002 VW Golf earlier this year, and within a week, the alarm
system malfunctioned.  The first symptom was the unprovoked appearance of
the "open door" icon on the dash. The next symptom was the sounding of the
alarm some time after locking the car in the normal manner - ie. by clicking
the remote or turning the key in the driver's lock.

The only way to prevent the alarm from going off was to lock the
car manually, a procedure the misplaced confidence of the cars
designers had made fiendishly difficult:

1. close the driver's door

2. lock all doors with remote

3. unlock the driver's door only with remote and reopen it

4. reach back to the rear door and unlock it with the handle latch

5. close the driver's door

6. open the rear door

7. reach forward from the rear and lock the front door  by
depressing the mechanical lock button

8. depress the mechanical lock button on the rear door and close it.

This is the only way to lock the car without arming the alarm.

Of course, the problem was intermittent. And the designers had not provided
any diagnostics for the system. So on the first trip in to get the problem
fixed, the dealership was unable to identify or solve it.

The solution had to wait until the problem had escalated to the point where
the hatchback could not be opened (in ANY manner! - there is no purely
mechanical way to operate the hatchback latch).  At this point the
technicians' suspicion fell on the lock mechanism of the hatchback, which
they then replaced, apparently fixing the problem.

The potential problems are actually worse than appears from above, as the
car has only two keylocks, that in the driver's door, and the one in the
hatchback.  The hatchback lock (when it's working) can only be operated by
the battery-operated master key (the valet key won't work on it).  So it
would seem that if you have only the valet key and the driver's lock jams,
there's no way to get into the car, other than breaking a window.

Volkswagen supplies two of the master keys with the vehicle, and
of these, the battery of one died in the first month.  You're allowed
to buy up to two more, but they cost more than CDN$200 each!


Re: When is fail-safe not fail-safe? (Rose, RISKS-22.02)

<"Anthony W. Youngman" <Anthony.Youngman@ECA-International.com>>
Mon, 8 Apr 2002 11:46:50 +0100

> The risks — fail-safe modes must be carefully designed for the system
> application: don't rely on the component default fail-safe mode.

Surely, for them to fail any other way would be life-threatening? Okay, the
prison needs an outer containment mechanism (and should have a backup
generator), but if the power failed due to a fire within the prison, and all
the doors failed locked, the prisoners would be trapped in their cells.

Given the design of those cells, death due to smoke inhalation could happen
extremely quickly - from what I've seen typical design is cells opening onto
walkways round a central "courtyard" - this would fill with lethal smoke in
short order, should the fire be in the accommodation block. (And don't
forget, many prisoners may well be "innocents" awaiting trial...)

Always think of the consequences of "safety" modifications. Like one
incident I remember. An HSO demanded that a unprotected pulley belt be
enclosed "for safety", despite the company concerned protesting most
strongly that they'd never had anybody hurt, and it was a safety feature
that it *wasn't* enclosed. Within months of doing as ordered, they'd had a
serious accident, and the security housing was blamed in no uncertain terms
as the cause of a minor incident turning into a major catastrophe. When one
employee had an accident, his colleague had been unable to stop the machine
by yanking the belt off the pulley, and by the time he'd run the length of
the hall to the emergency stop button the trapped employee had been
seriously injured.


Is your e-mail watching you?

<Monty Solomon <monty@roscom.com>>
Sat, 6 Apr 2002 15:39:42 -0500

  [Stefanie Olsen, CNET News.com, 4 Apr 2002]

Watch out--the spam choking your e-mail in-box may be loaded with software
that lets marketers track your moves online, and you may not even be aware
that you've been bugged.  Web sites have long planted bits of code called
"cookies" on consumers' hard drives to tailor Internet pages for returning
visitors and better target ads. Now, enhanced messages that share the look
and feel of Web pages are being used to deliver the same bits of code
through e-mail, in many cases without regard for safeguards that have been
developed to protect consumer privacy on the Web.

"All of the security and privacy issues on the Web now relate to e-mail,"
said Adam Shostack, director of technology at Zero-Knowledge Systems, a
Montreal-based privacy and security company. "The shame about this behavior
is that it's going on surreptitiously and people are not given an obvious
way to opt out."  [...]

http://news.com.com/2100-1023-875992.html


The Risks of using the wrong address

<Dan Birchall <i_charge_100_bucks_per_spam@nospam.danbirchall.com>>
10 Apr 2002 20:47:48 GMT

As a longtime spamfighter, I've learned to be a little careful about who
gets my various e-mail addresses.  If I wouldn't let someone call me
collect... maybe they don't really deserve my personal e-mail address
either.

As a longtime human, I make mistakes.  A few months back, for example, I
submitted a piece to RISKS from... my personal e-mail address.  Whoops.
Now it's available on the web at no fewer than 8 URLs.

Thus far, it's only gotten one piece of spam... I'll just hope other
spammers and address-scraping 'bots are smart enough not to scrape addresses
from a RISKS archive.

Dan (using the correct address this time)


Re: Yahoo Groups spam alert (RISKS-22.02)

<Jim Horning <horning@intertrust.com>>
Fri, 5 Apr 2002 14:24:09 -0800

Turns out you can't even log in to Yahoo to turn the options off unless you
accept a cookie whose Compact Privacy Policy is unacceptable (to me, anyhow,
your mileage may differ).  At least I couldn't.


Ray Bradbury's Fahrenheit 451, revisited

<Marc Rotenberg <rotenberg@epic.org>>
Thu, 11 Apr 2002 13:54:31 -0400

It seemed both appropriate and ironical to review Ray Bradbury's
Fahrenheit 451 at this point in time. Earlier this month the US
Congress began consideration of a bill that would ban the
unauthorized reproduction of digital works.  At almost the same
time, federal prosecutors urged a court in Philadelphia to require
technology in public libraries that would block access to
information that some consider offensive.

There is no kerosene dripping from the pages of books in Washington
or Philadelphia, but digital words would not burn. The methods of
eradication must be more subtle, the technique more sophisticated.

It is tempting when reading Bradbury's classic work on censorship to
draw parallels to book burnings from an earlier era, to make the
obvious connection between the firemen in Bradbury's novel who set
aflame houses that contained the printed word and those who gathered
not so long ago to burn the words of Albert Einstein, Thomas Mann,
Marcel Proust, Margaret Sanger, and H.G. Wells.

But Fahrenheit 451 is not simply about book burning. This is a world
where the culture of censorship has permeated the public and the
private. There is no intellectual life. There is no political life.
Interactive broadband technology provides endless entertainment
through the full-screen images that appear on the walls of a parlor
room. Words of meaning cannot be transmitted in any physical media.
They must be memorized and passed on as they were before the
printing press, before the written word.

The protagonist Guy Montag, a fireman who will disavow his
profession, confronts this reality in a series of encounters. First
with a young woman who asks questions he cannot answer. Then with an
old teacher who recalls a past that cannot be recorded. And finally
with his boss, the Chief Firefighter who can quote Pope, Milton and
Shaw, and then smile as a house and its contents are engulfed in
flames.

Montag's future is not without hope. He will fare better than
Orwell's Winston, Kafka's K, or the Prisoner before Dostoevsky's
Grand Inquisitor. Still, the reconstruction of culture, literature,
and history once recorded words are banished cannot be assumed. When
a single person can recall only one essay of Thoreau's or a chapter
from Bertrand Russell, the unique quality of information — its
ability to flow without bounds — is effectively exterminated.

Perhaps it is unfair to compare the current legislative efforts to
protect copyright interests or to prevent children from being
exposed to images and words that are beyond their years with the
unambiguous horror of burning a book because of the ideas contained
inside. But technology does not make such distinctions, and
capability creates opportunity. Already software filters have been
turned on controversial ideas and unpopular organizations. And new
copyright techniques will digitally incinerate recorded words that
might otherwise be widely available.

In this year when many city mayors are urging residents to share the
experience of reading a common book, Los Angeles Mayor Jim Hahn has
asked those in L.A. to read Fahrenheit 451. And Ray Bradbury's
presence last week at a new mid-Wilshire bookstore, more than fifty
years after the first publication of Fahrenheit 451, is a powerful
reminder of the value of the written word.

Marc Rotenberg

http://www.epic.org/bookstore/powells/redirect/alert907.html


REVIEW: "Hacker's Challenge", Mike Schiffman

<Rob Slade <rslade@sprint.ca>>
Tue, 2 Apr 2002 08:32:57 -0800

BKHKRCHL.RVW   20020221

"Hacker's Challenge", Mike Schiffman, 2001, 0-07-219384-0, U$29.99
%A   Mike Schiffman
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   2001
%G   0-07-219384-0
%I   McGraw-Hill Ryerson/Osborne
%O   U$29.99 +1-800-565-5758 +1-905-430-5134 fax: 905-430-5020
%P   355 p.
%T   "Hacker's Challenge"

Initially, I was skeptical of the title, considering the wording to be
simply jumping on the current security bandwagon, with "hacker" this
and "hacker" that on every bookshelf.  In an odd way, however, the
title is quite appropriate.  This volume contains a series of twenty
tests that are supposed to challenge your ability to analyze network
data (most of the scenarios are network based) in order to identify
and assess intrusions.  Unfortunately, there are some problems in the
implementation.

The book is divided into two parts.  First come the twenty scenarios,
with varying types and degrees of detail about the problems.  Then
come twenty "solutions," which are supposed to point out how you
should have approached the situation, and what indicators should have
tipped you off to the intrusion and intruder.  This physical division
is rather meaningless: it isn't as if the solutions were short phrases
that had to be printed upside down at the bottom of the page so that
the reader doesn't inadvertently read the answer to the riddle while
thinking about it.  There is no reason that the solutions could not
immediately follow the stories.

Actually, the pieces were written by thirteen different authors, and
the amount of detail varies tremendously.  Therefore, all the possible
mistakes that could be made in a work of this type are represented.
Sometimes the audit logs presented to us in the scenario contain the
relevant details and very little else, but the explanation is very
sparse.  In other pieces readers are presented with huge amounts of
log data, and the relevant points are lost.  There are scenarios which
are not complete, and the data necessary to solve the problem is not
given until the solution write-up.  A few pieces contain almost no
data for the reader in the problem section, while the solution
presents almost no detection information or forensic exegesis.  In one
case we are given pages of log data and almost no analysis at all in
the solution.  There are articles that simply reproduce earlier
situations with different characters.  One solution makes no sense in
terms of the data given in the problem outline.  Some pieces are
unclear, some simplistic, and some can only be described as
misleading.

The occasional scenario is written up almost poetically, and isolated
solutions do have tutelary explanations of how to read network audit
logs.

If you are very good at forensic network analysis, you might enjoy
pitting yourself against these challenges.  Of course, if you are good
at forensic network analysis you have more work than you can handle,
and no time for games.  If you are weak at network analysis, this book
doesn't have very much to help you out.

copyright Robert M. Slade, 2002   BKHKRCHL.RVW   20020221
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

x
Top