The RISKS Digest
Volume 19 Issue 68

Thursday, 16th April 1998

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…


Commerce Secretary calls U.S. encryption policy a failure
IRS to spend $1 billion to fix Y2K problems
Declan McCullagh
Only 1/3 of popular Microsoft apps are Y2K compliant
Chris Stamper via Declan McCullagh
Y2K and the eagle talon
Josh Rivel via Dug Song
Gas station owners forbid use of mobile phones ...
Steven Slatem
Tacoma, WA 911 computer problems
Jonathan Clemens
Comvor: Hamburg police computer system
Martin Virtel
Risks of being a pioneer: KL International Airport
John Lim
AT&T network failure takes a toll on commerce
AT&T frame relay network effects
Brian McMahon
HP200 data integrity woes
Fred Cohen
Webmaster's copyright risks
Mario Profaca
Re: Cypherpunks break GSM digital cell phone encryption
Stewart Fist
CFP: Dependable Computing for Critical Applications 7
Chuck Weinstock
Info on RISKS (comp.risks)

Commerce Secretary calls U.S. encryption policy a failure

Edupage Editors <>
Thu, 16 Apr 1998 19:57:16 -0400
Distancing the Commerce Department from the position held by the Federal
Bureau of Investigation, Commerce Secretary William M. Daley says that the
Clinton Administration's controls on encryption technology are hurting
America's ability to compete with other countries.  "There are solutions out
there.  Solutions that would meet some of law enforcement's needs without
compromising the concerns of the privacy and business communities.  But I
fear our search has thus far been more symbolic than sincere... The cost of
our failure will be high.  The ultimate result will be foreign dominance of
the market.  This means a loss of jobs here, and products that do not meet
either our law enforcement or national security needs."  (*The New York
Times*, 16 Apr 1998; Edupage, 16 April 1998)

IRS to spend $1 billion to fix Y2K problems

Declan McCullagh <>
Thu, 16 Apr 1998 10:56:16 -0700 (PDT)
[If, as is widely predicted in Y2K circles, the IRS's computers go south,
maybe we'll have that national sales tax after all. --Declan],1042,1909,00.html

The Netly News, April 16, 1998

How is it that millennial fever is focused so far on 30-year-old lines of
COBOL code, as opposed to, say, the second coming of a messiah? Yesterday
the head of the IRS used his agency's biggest day of the year to proclaim
Year 2000 the "most unfortunate but most essential problem" — and one that
will cost $1 billion to fix. This is up from $850 million two weeks ago, and
$250 million six months ago. "We simply, absolutely must devote all of our
resources to fixing the year 2000 problem," Charles Rossotti said at a
National Press Club luncheon. If the problem is not solved, he said, the
result will be "very dire indeed." Only 625 days to go.

  [To subscribe: send a message to with this text:
subscribe politech
  More information is at ]

FC: Only 1/3 of popular Microsoft apps are Y2K compliant

Declan McCullagh <>
Wed, 15 Apr 1998 17:35:32 -0700 (PDT)
[Time for the government to step in and start licensing programmers! Just
kidding, folks — but I know industry lobbyists here who are getting
worried.  --Declan]

>Date: Wed, 15 Apr 1998 15:40:30 -0700 (PDT)
>From: Chris Stamper <>

  By Chris Stamper
  April 15 - Some Microsoft products used on thousands of computers will
  have problems after Dec. 31, 1999, and Bill Gates turned the light on
  the Year 2000 bugs in his software today.  Microsoft's new Year 2000
  Resource Center is now alive on the Web. There's a picture of Gates on the
  home page, reassuring millions of customers that "we are committed to
  providing the information you need."

Microsoft Reveals Y2K Problems On New Web Site:

  [Declan's POLITECH mailing also included an article by Mary Jo Foley
  <> pointing out that
  MS reports that only 21 of MS's top 60 software products are Y2K
  compliant, primarily because of MS Internet Explorer 3.X and 4.X.
  Windows 95, Windows for Workgroups 3.11, NT Server 4.0, NT Workstation
  4.0, various versions of Office 95, Visual Basic 5.0 and Visual Studio
  Enterprise 5.0 and also reported as noncompliant.  PGN]

Y2K and the eagle talon

Dug Song <>
Wed, 15 Apr 1998 20:46:03 -0500 (EST)
>Date: Wed, 15 Apr 1998 20:18:52 -0400
>From: Josh Rivel <>
>Subject: GeeK: interesting implications of Y2K non-compliance

I'm on a mailing list related to Eagle Talons/Mitsubishi Eclipses/Galant VR4's
anyway, it seems the code in the ECU's for the 1st generation of those cars
(1990-1994) has an interesting problem with Y2K compliance.

The following excerpt was written by Todd Day <> who is the
list moderator, and ECU (Engine Control Unit, aka car computer) wizard.

 [All you guys with 1989-1994 DSMs might want to take another car to the
 parties on Y2K eve...  or arrange for a tow truck.  1995-98 ECUs seem
 to be Y2K compliant, as far as I can tell (an OBDII requirement).  If
 you don't want to be seen at the party without your DSM, for $100, I
 can fix your ECU so the overflow problem won't happen until 2089.

 I've set my ECU to the bewitching hour, and the results aren't
 pretty.  The overflow causes a mask bit to be set which prevents the
 spark plug in cylinder 3 from firing, but doesn't stop the fuel flow.
 The fuel flow in that cylinder actually doubles due to a side-effect
 of the spark bug.  This creates some pretty spectacular backfires, I
 must say...  One hell of a way to welcome in the new century.

 Oh yeah - this bug happens at December 31st, 1999 at midnight (or
 January 1st, 2000, depending on how you look at it) in the CENTRAL
 time zone.  That's because the cars were all built in Illinois.  So
 for you East Coasters, it will occur at 1am, and West Coasters will
 experience it at 10pm.

 -talon mgr]

Josh Rivel  Senior Network Engineer  Digital Telemedia, Inc.

Gas station owners forbid use of mobile phones ...

IntelliTech Media <>
Thu, 16 Apr 1998 21:02:29 +0200
Gas station owners forbid use of mobile phones, claiming EM waves are
disrupting their data networks

PRAGUE, CZECH REPUBLIC (NBISN, 04Apr1998) — Mobile phones, which used to be
an extravagance for the elite, are now cursed by many of the thousands that
have adopted them since networks and phones based on the digital mobile
standard GSM became available over one year ago. Users have been warned that
use of the phones while driving can be dangerous, use in banks is forbidden
due to use by robbers to target cash-heavy bank clients, use in hospitals is
forbidden because of interference with equipment, use on airplanes is
forbidden (and usually useless even if it wasn't), they just plain don't
work in the underground, use on ground-bound public transportation is
frowned upon by other passengers (or grinned upon by snoops) and now use at
many gas stations is forbidden. Gas station chain owners, such as Benzina,
are posting signs with a big X over the picture of a mobile phone and
claiming that they have a legal right to forbid the use of these devices as
the rascals interfere with data transfer over payment card networks such as
CCS, Mlada Fronta DNES, a leading Czech newspaper, reported on 04Mar1998.

But CCS claims that mobile telephones can in no way affect the operation of
the CCS system and that not a single case as such has been reported, MF
DNES quoted Hana Sevcikova, business manager at CCS, as saying.

A Benzina spokesman, Pavel Schinkmann, however, says that the cases are
fresh and thus maybe not everyone has heard about them yet... and that the
phones are indeed forbidden at all of its over 400 stations throughout the
Czech Republic. Benzina, who holds an ISO certificate, links all its
stations via a network, apparently with some wireless connections.

MF DNES quoted one Benzina spokesman as saying that "electromagnetic waves
can disrupt computers and sometimes can cause an explosion."

But MF DNES did cite at least one concrete case: A spokeswoman for the
Benzina station in Prostejov, Bozena Hochwaldova, said the mobile
telephoning brought down the whole CCS system not long ago.

Some Shell stations have also forbidden the use of mobile phones for the
first time just days ago but some operators such as OMV say they will
tolerate their usage.

Tamoil, recently exposed as having Libyan capital behind it by the English
language Prague Business Journal,, will probably not
be one of those to forbid mobile phone usage since they are already
starting to lose enough business as is.

Maybe the list of where you can actually use mobile telephones should be
published — it will soon certainly be much shorter than the list of places
where you can't.

- Steven Slatem, IntelliTech Media, Inc.,,

Tacoma, WA 911 computer problems

Jonathan Clemens <>
Thu, 16 Apr 1998 08:40:13 -0700 (PDT)
>From <>

"Glitches in a new 911 computer system are slowing critical communications
between local emergency dispatchers and officers.

"The sporadic problems have become severe enough to jeopardize officer
safety and must be fixed immediately, police say." [...]

The article goes on to describe how the "windows based" solution by
Unisys was one full year behind schedule, was pulled out of service for 18
months of software repair, and is still unusable under heavy load.

The contract (US$ 1.4M) seems relatively small to be plagued by such
problems. Yet, it is another reminder that poor project execution, no
matter with whom the blame lies, can be hazardous to life and safety.

Jonathan Clemens, CCP  Intel Corp.

Comvor: Hamburg police computer system

Martin Virtel <>
Thu, 16 Apr 1998 20:30:15 +0200 (MEST)
Since 1989, some 120 Million (estimated) Deutschmarks (US$ 70 million) have
been wasted trying to design and install a new computer system ("Comvor")
for the police in Hamburg, Germany. The system, designed to ease the load of
paperwork on the police, never worked.

So far nothing new, the reports have going on for month, if not years. Red
tape wasting our money, one thinks. What strikes me are three conclusions of
the whole affair that appeared in Hamburger Abendblatt (April 16th, p. 13)

- 356 jobs have been cut (some of them because they "won't be necessary
after the system starts working", some of them to save money for buying the
computers in the first place), and there are no plans re-employ
people. Instead, police officers do the paperwork that the computer system
was supposed to do, and money has to be found to buy new computers.  The old
system (the one "Comvor" was built to replace) sucks in 340.000 Deutschmarks
a month for maintenance.  (Lean government is more expensive, in some ways.)

- The consultant firm contracted for designing a new computer system blames
part of the mis (or non-)achievements of Comvor on the fact that police
people were in charge of the development team.  "Software design was not one
of their core competences", reads the quote from Uwe Kirchhoff, the boss of
the consultant firm. (And I thought it were the software people who make
computer systems that don't work in the real world.)

- Interior minister Hartmuth Wrocklage blames the misachievements on the
fact that "the complexities (of the whole venture) had been underestimated".
(This one ranks first in the top-ten of "Why our software doesn't work", I

To me, it looks a bit like a case of "Hey, how can we save money and at the
same time stick to the weird and inefficient way we do our job? By putting
the whole thing into a computer?" Contracting a software firm in a situation
where you should buy advice from a management consultant.

Big risk: "The Computer will solve our problems".

Martin Virtel, DIE ZEIT im Internet (  +49 (0)40-3280-562

Risks of being a pioneer: KL International Airport

Thu, 16 Apr 1998 10:38:42 +0800
Malaysia is getting a state- of-the-art airport for its capital (Kuala
Lumpur), but it has been plagued with delays. Portions of an article is from
the Far East Economic Review.  ---

"With the (Malaysian economic) slowdown, demand will come down and we'll
have some excess capacity on opening day," admits Clifford Herbert, who
heads Kuala Lumpur International Airport, the government-owned company
responsible for the 9-billion-ringgit ($2.4 billion) project. But he rejects
notions that the airport is too extravagant. "In terms of cost, we have
something very functional," Herbert says, pointing out tha the airport was
almost completed before the currency crisis struck. "I don't think we wasted

Whether airlines and passengers agree will depend on the airport's teething
problems in the months ahead. The opening has already been postponed twice:
most recently from April to late June. Some of the biggest anxieties centre
on the 700-million-ringgit (US $200 million) Total Airport Management
System, a computer network that links 16 sub-systems ranging from flight
information to baggage handling.

The airport will be the first in the world to link all these functions into
one set-up. But pioneers often pay a price. Reports say that when the
baggage-handling system was tested for the first time, with 200 bags, not
one ended up where it should have. "In theory it sounds great, but there are
a lot of intricacies in linking so many computers," says a second foreign
airline manager in Kuala Lumpur.  ( Shades of Denver airport ! - john)

Some airline operators fear Malaysia is stressing pizzazz over efficiency.
"Kuala Lumpur strikes me as state-of-the-art. They've tried to put all the
best things into the airport," says the first foreign airline executive,
whose airline lands in both Kuala Lumpur and Hong Kong. "Hong Kong is trying
to make an efficient airport," he says. (Hong Kong's new airport is slated
to open in early July.) "What we've heard so far about Kuala Lumpur is that
it's more grand than functional."

-- My comments - John Lim: I was formerly employed by a company heavily
involved in bidding for IT systems for the KL International Airport and I
can attest to the dream of the politicians approving the project were more
grand than functional.  In fact when my former company were bidding for the
project, most of the big IT companies in Malaysia felt that the ambitions
were too great given the tight schedule. But most of these companies,
including my former company still went in to bid anyway. PS: we knew about
Denver airport back then in 1994/5.

The Risks:
For companies: Some projects are felt to be too big and prestigious to walk
away from; particularly in a small country like Malaysia.  For governments:
Be very sure you have the resources to implement your ambitious plans;
particularly in a small country like Malaysia.

John Lim         Natsoft Malaysia  Tel:(60)3 7061216 Fax:(60)3 7061210

AT&T network failure takes a toll on commerce

Edupage Editors <>
Thu, 16 Apr 1998 19:57:16 -0400
The failure earlier this week of AT&T's national high-speed network didn't
affect conventional or cellular telephone service, but did manage to disrupt
the portion of the network that carries data for transactions involving
credit cards, bank accounts, travel reservations and the like.  "This sort
of thing is going to happen infrequently, but more and more in the future,"
says the managing director of the Yankee Group.  "And it makes you realize
how vital to the lifeblood of the economy these complex computer networks
have become."  There is no way to gauge how many transactions were forfeited
as a result of the blackout, but analysts are saying the losses are likely
huge, with thousands of businesses affected.  (*The New York Times*, 15 Apr
1998; Edupage, 16 April 1998)

AT&T frame relay network effects

Brian McMahon <BMCMAHON@Cisco.COM>
Wed, 15 Apr 1998 11:32:46 -0700 (PDT)
Among the many places that felt an immediate and severe impact from the
outage was our Access support group, which handles ISDN and modem dialup
issues.  ISDN and async are both popular backup solutions for FR links, and
lots of people found out in a hurry just how good their backup configs were.
It hailed high-priority "network down" calls all afternoon here, both from
customers who didn't have backup links in place and were scrambling to set
them up, and from customers who had something that they thought would work,
but didn't.

This illustrates an often-overlooked risk.  Backup strategies are no good
unless they actually work when needed.  To be reasonably assured that they
will work when needed, you have to test them.  And (here's the kicker) your
test has to cover the WHOLE THING.  But a *complete* test is (almost
inevitably) disruptive, and risky in itself.  Therefore, the more important
the thing being backed up, the less likely it is to be properly tested.

For instance, the only REAL test of a backup circuit for frame relay
involves shutting down the production FR circuit and seeing if your backup
does the right thing.  Less drastic tests (e.g., can we dial the backup
number) won't tell you if the whole thing will do what you need — which is
not just to get two routers talking, but to get packets to the appropriate
destinations.  That takes more than just a connection between the two
routers, though.  (You need to make sure that routing updates happen
correctly on both sides, to name just one popular failure point.)

Management is often reluctant to allow full-scale backup tests of critical
links, but those are the ones you want to be especially sure of.  Catch-22.
An incompletely tested backup may even be worse than no backup at all,
because it encourages unwarranted complacency.

Similar problems apply for tape backups, by the way.  The best test of your
backup is a restore, which usually means system downtime.  And if your
restore fails, then what?  You have a scrozzled system, that's what.
Ideally, you'd run your test on a spare system, but not everyone has that

(Then there was the customer whose telco turned off their backup ISDN line
"because it wasn't being used...."  Sigh.)

Brian McMahon <>, Customer Support Engineer, Cisco Systems

HP200 data integrity woes

Fred Cohen <>
Thu, 16 Apr 1998 10:14:17 -0700 (PDT)
I just had an amazing conversation with Hewlett Packard's support services.

My HP200 lost it's mind this morning and corrupted the content of it's RAM
disk. I was able to reboot the computer and get a copy of the data onto a
PCMCIA memory card and put it onto other computers at my site. The next step
was to try to recover the content, so naturally, I called HP's support line.

They told me that the palmtop computers they were selling only a few months
ago used formats for their calendar and quicken databases that they did not
know how to read. They claimed that they went directly to their own
engineers who had designed the products and that these folks did not know
what the data formats were - even for their own proprietary file formats!

I guess it's the end of an era when a company with a long reputation for
high quality and reliability doesn't even know how their own products work.

I guess I'll just have to hack their software to get my data back.

  [Added later:]

So I tried to call Intuit to get technical support for data recovery from
corrupt pocket quicken data files, and wouldn't you know...

The Intuit Web page refers you to HP for support of the HP-based quicken
products, but as we already know, HP doesn't know the format information
required for file recovery. So next I tried the number for Intuit's corporate
headquarters as posted on their Web page - 1-800-446-8848

But lo and behold, the area code for the area I live in recently changed
from 510 to 925, so apparently the phone switch at quicken decided I was
calling from Canada. Instead of technical support, I got a new telephone
number to call that was toll-free from Canada - but of course it doesn't
work from the United States.

Next I tried the operator (not the quicken operator - no such option on
their answering machine and buttins like 0 don't work) and got a number in
Mountain View for the real Quicken headquarters - which I called. Naturally,
I finally did get an operator - and I found out that there is a number for
quicken technical people - it's 520-618-7292 - but the operator told me that
it wouldn't help to have the number today (Thursday) since all the employees
were having a party today to celebrate that 15th anniversary of the founding
of the company. I tried anyway and got a fast busy signal.

So my denial of service was caused by:

  A human design failure in my willingness to trust a computer with my
  upcoming appointments.

  A hardware failure in a palmtop computer.

  A software failure in the inability to read the hardware-corrupted files.

  A business failure by HP not having the necessary information on
  their own products.

  An information failure in the Intuit Web page not leading you to
  technical support that knows the answer to your questions.

  An infrastructure failure in the telephone system deciding I am from

  A business model failure in my expectation that during normal
  business hours a company that is supposed to be a major player in a
  financial industry would be available to support their products.
  A support failure in that they were not available to support their product.

The probability of all of this set of events must be astronomically small by
the calculations of any competent risk analysis system, but that just goes
to show you - tightly coupled systems with interdependencies... yada yada

As a postscript, by now I have recovered most of my data — using an old
fashioned text editor and the normal tools available from Unix. Under DOS
or Windows there was no hope.

Fred Cohen & Associates: - - tel/fax:510-454-0171

Webmaster's copyright risks

"Mario Profaca" <>
Wed, 15 Apr 1998 03:36:33 +0200
I do not know if it happens to other www owners, designers and webmasters,
but from time to time some smart fellows, kleptomaniacs, used to come to my
web site to "collect" my animated gifs, although there is a precise and
clear copyright notice at all of my 300+ web pages. The
catch_as_catch_can_minded "webmasters" simply download it and put it on
their web pages. And, of course, they are also claiming copyright for the
entire contents of their web pages...

>From time to time I go to a research expedition throughout the Cyberspace
looking for animated gifs stolen from my web site (Mario's Cyberspace
Station <>)

In past few years so I found my little animated red devils at others
web pages in Croatia, Slovenia, U.S.A., Japan, Spain, Australia, and Taiwan.

When discovered, I used to send a kind message to the webmaster asking them
to remove my images (animated gifs) from their web site for it is my
copyright. And they always did. Some of them sent to me a sort of apology,
somebody did not answer to my message but simply remove it.

But this last case is the worst of all. This Australian lady-webmaster did
not answer to my messages, although I was tracking her and saw she received
it. And, "of course", she did not remove my animated gif from her web site.

What makes this case the worst is that she put my animated gif novine.gif,
<> my little red devil reading
newspaper ("novine" in Croatian language means "newspaper"), at "her"
animated gifs collection even asking her visitors to feel free to use those
images on their web pages (!)

Hope somebody shall learn something out of this case:

The lesson (or just a question) is:
  Is such little theft worth this publicity on Internet?

Mario Profaca, Mario's Cybrspace Station

Re: Cypherpunks break GSM digital cell phone encryption

Stewart Fist <>
Thu, 16 Apr 1998 09:53:26 +1000
Declan McCullagh <> quotes TIME Magazine, April 20, 1998
as reporting: " Now crooks scanning the airwaves can remotely tap into a call
and duplicate the owner's digital ID. "We can clone the phones," brags Marc
Briceno, who organized the cracking. His advice: manufacturers should stick to
publicly vetted codes that a bunch of geeks can't crack in their spare time."

My understanding is that they managed to crack the code on the SIM or smart
card, not any radio-transmitted information.  They repeatedly asked the card
to identify itself, and so cracked it by brute force.

The article also says: ``What was even more intriguing than the security
threat, however, was that cracking the code yielded a tantalizing hint that a
digital key used by GSM may have been intentionally weakened during the design
process to permit government agencies to eavesdrop on cellular telephone conversations.''

This has been known for years.  The use of GSM in Australia, for instance, was
blocked on the day of the official launch because the security and police
services wanted an easier code to break.  At that time, I understand, they
just switched encryption off. This was also widely reported in Europe at the
time, and openly admitted.

The original A5 encryption was promoted as being "NATO level security" which
was a bit of overkill for a mobile phone that is probably going to be used
with an insecure wireline link, and often used in public places.

Now it appears that they've cut the 64-bit key down to an effective 54-bit by
adding trailing zeros to make it easier to crack.  It would still be a pretty
healthy sort of encryption even at this level however.

Stewart Fist, 70 Middle Harbour Road, Lindfield, 2070, N.S.W, Australia
+61 2 9416 7458

CFP: Dependable Computing for Critical Applications 7

Chuck Weinstock <weinstock@SEI.CMU.EDU>
Wed, 15 Apr 1998 11:33:45 -0400
  Call for papers: Seventh IFIP International Working Conference on
       Dependable Computing for Critical Applications (DCCA-7)
            January 6-8, 1999 in San Jose California, USA

Various versions of the CFP, together with additional information and links,
are available from the DCCA-7 Web page at .
The paper submission deadline is 3 August 1998.

General Chair
 Charles B. Weinstock, SEI, USA
Program Chair
 John Rushby, SRI International, USA
Organized by
  IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance
In cooperation with (pending approvals)
  The Software Engineering Institute, Carnegie Mellon University
  IFIP Technical Committee 11 on Security and Protection
  IEEE Computer Society Technical Committee on Fault-Tolerant Computing
  EWICS Technical Committee 7 on Systems Reliability, Safety and Security

Please report problems with the web pages to the maintainer