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 18 Issue 47

Thu 19 September 1996

Contents

o Electromagnetic interference, medical-device risks, and airplanes
PGN
o Lexis' P-Trak vs ptrax
Emma Pease
o Re: Minnesota disconnected from the world
Theodore M.P. Lee
Jeremie Kass
o Re: Microsoft VC++ property pages guaranteed to crash
Boyd Roberts
o More ATM risks
Rory Chisholm
o 411 needs 911
Kent Quirk
o Bringing Home the Anonymous Bacon
Peter Wayner
o Risks of not including appropriate manual overrides
William Hutchens
o Re: Failure-mode risks revealed by Hurricane Fran
Steve Holzworth
o Ariane 5 report, available on line
Richard J. Fateman
o ETHICOMP96 MADRID 6-8 November 1996
Centre for Computing and Social Responsibility
o Info on RISKS (comp.risks)

Electromagnetic interference, medical-device risks, and airplanes

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 17 Sep 96 18:29:21 PDT
INTERFERENCE WITH MEDICAL DEVICES

There is an article on the effects of interference on medical devices,
``Electromagnetic interference and medical devices'', *Health Letter*,
Public Citizen Health Research Group, 12, 6, June 1996, pp, 6-7.  Apnea
monitors have failed to sound the alarm when patients have stopped
breathing.  At least one implanted defibrillator has failed, responding to
EMI and delivering a shock to a normally functioning heart.  Power
wheelchairs have also been affected.  The greatest risk still appears to be
implanted heart pacemakers, for which various problems are included in the
RISKS archives.  EMI is particularly problematic in hospitals, where
sensitive monitors converge with radiating equipment (e.g., high-frequency
generators and electrosurgical, diathermy, MRI, and x-ray machines).
Cellular telephones are also a serious concern as emitters.  Wireless
technologies are likely to make things worse.

The July 1996 issue of *Health Letter* summarizes the reports of two more
recent studies on the effects of cellular phones on pacemakers.  In the
first study, tests of analog phones (90% of today's cellular phones) showed
minimal interference (3% of the time), while *all* of the digital phones
caused some level of interference.  In the second study, 30 types of
pacemakers were tested.  Motorola's MIRS (used in foreign markets) caused
EMI in 36% of those pacemakers within 3.5 inches or less.  North American
Digital Cellular phones interacted with 10% of the pacemakers within 1.5
inches.

MISCELLANEOUS MEDICAL DEVICE SOFTWARE PROBLEM

Incidentally, the September 1996 issue of *Health Letter* notes a Class II
recall of 7200-series microprocessor ventilators (in particular, 7200ae, e,
and sp with certain serial numbers, 8402 in all), which can stop operating
when they are first turned on -- due to defective software.  The
manufacturer is Nellcor Puritan Bennett, Carlsbad CA, 1-800-255-6773.  (2987
units of the model 7200 are also being recalled because of a defective
transducer that causes it to stop ventilation for certain data-dependent
settings.)

INTERFERENCE WITH AIRPLANES

There is an excellent article on the effects of electromagnetic inference on
airplanes: Tekla S. Perry and Linda Geppert, ``Do portable electronics
endanger flights?  The evidence mounts'', *IEEE Spectrum*, September 1996,
pp. 26-33.  Check it out.  I learned a lot.

  [ham@cs.utexas.edu (Hamilton Richards Jr.) summarized the *Spectrum*
  article as follows:
    The risk that RF emissions from carry-on electronic devices will affect
    avionics, although not high, is still high enough to warrant tougher
    government regulations.]


Lexis' P-Trak vs ptrax (Re: RISKS-18.44,45)

Emma Pease <emma@Kanpai.Stanford.EDU>
Fri, 13 Sep 1996 18:34:50 -0700 (PDT)
A copy of the warning letter crossed my display on 11 Sep 1996, and
immediately triggered the feeling of don't trust the information without
checking (the multiple levels of quoting by the time it got to my desk for
instance).  So, I decided to do some checking using alta vista and dejanews.

One of the first things I discovered was that the product in question is not
called ptrax (though Lotus produces something with that name) but rather
P-Trak and that warnings first went out in early June about it.[1] Before
that time Social Security Numbers were visible, afterwards they weren't
though they were still in the database.  I also found the description of the
product (date unknown, but I think June of this year).

  http://www.lexis-nexis.com/lncc/products/media/issue396.html

Lexis-Nexis also seems to have put the following up within the last day
or so:

  http://www.lexis-nexis.com/lncc/about/ptrak.html

I also noted that the database lists the person's maiden name (not the
person's mother's maiden name, as stated in the warning message), though
given a large enough database a searcher might be able to figure out your
mother's maiden name.  [It is also typically on your birth certificate,
                       which is public-record stuff.  PGN]

Risks: Most of us seem to have accepted the message without much checking as
even the simplest check should have turned up the correct spelling of the
product name (though admittedly by phone p-trak and ptrax could sound the
same).  In this case, most of the information was correct -- but will this
always be true?

Emma Pease

[1] See http://www.epic.org/alert/EPIC_Alert_3.12.txt (The Electronic
Privacy Information Center, June 25th newsletter).  See also C-Net

http://www.cnet.com/Content/News/Files/0,16,1527,00.html
http://www.cnet.com/Content/News/Files/0,16,1539,00.html

for some articles on the matter in June.

   [There are lots of items on this subject in today's media.  Also,
   sidney markowitz <sidney@research.apple.com> notes the web address of
     <http://www.lexis-nexis.com/lncc/p-trak/p-trak.html>
   has a form to fill in and submit on-line, to remove yourself.  PGN]


Re: Minnesota disconnected from the world (RISKS-18.46)

Theodore M.P. Lee <tmplee@MR.Net>
Wed, 18 Sep 1996 22:02:39 -0500
Official statement form MR.Net, 16 Sep 1996, sent to a technical list:

> InternetMCI's network experienced periodic outages on national scale from
> approximately 3:30am til 10:00pm CDT yesterday.  The effects of the outage
> were not uniform network wide.  MRNet was one of the harder hit, CICNet and
> NorthWestNet were also badly hit.  The Seattle area seems to be the hardest
> hit.  Some InternetMCI customers are said to have seen nothing but slow
> downs.  At one point the BGP routing to several of NAPs were affected.

> The outage was caused by a bug in Cisco routers that was triggered certain
> network events.  The nature of these events and why they have not shown up
> until now has not been determined.  InternetMCI is still investigating all
> the data gathered from the failure, until this is complete nothing is
> being suggested or ruled out."

   [swb@mercury.campbell-mithun.com (Shawn Barnhart) updates Ted's R-18.46
   message, noting that *not all* of Minnesota gets its connection through
   MR.Net -- Minn-Net and at least one other use uu.net.  PGN]


Re: Minnesota disconnected from the world (RISKS-18.46)

Jeremie Kass <jeremie@umich.edu>
Tue, 17 Sep 1996 23:30:06 -0400
We at U of M were disconnected from the world for more than 12 hours.
Starting at ~5am on Sunday the 15th, MCI was upgrading their routers.  The
engineer I talked to at the the MCI NOC said that something went wrong
during the upgrade and all the software (I'm not sure if it was the actual
software, or the routing information) was fried.  Our connectivity to the
Internet was pretty much gone at that point ... some of MCINet's peerings
worked as we could get to msn.com, but not to microsoft.com.  To compound
problems, at about the same time, PSINet lost two of their BGP routers at
MAE-East & MAE-West. This affected me since many of my customers & our
corporate network are on PSINet, so I couldn't get to PSINet from MCINet
(actually, mich.net, the academic ISP for Michigan) since their peering was
at MAE-East.[*]  By Monday morning all was resolved, including PSINet's
problems.

Happy ending to a bad weekend for the 'net, but at least the engineer I
talked to at MCINet was able to joke about it.

Jeremie Kass, Information Technology Consultant, Ciara Systems, Inc.
University of Michigan  jeremie@umich.edu * jeremie@ciaraweb.com

  [* I would have thought they were peering at MAE-West.
  You know, "Come up and C(++) me some time."  PGN]


Re: Microsoft VC++ property pages guaranteed to crash (RISKS-18.46)

Boyd Roberts <boyd@france3.fr>
Wed, 18 Sep 1996 12:06:14 +0200
Reading the article written by John Vert <jvert@MICROSOFT.com> and then the
two cited KB [Knowledge Base] pages it strikes me that the real RISK is the
complexity of the software offered by Microsoft.

It is difficult to use many of the Microsoft API's because the things they
act on are inherently complex.  Often, to do a 'simple' thing you have to
call multiple APIs and many of these have a non-trivial number of arguments
and/or must be passed complex data structures.  In many cases these
parameters set to 'defaults', so why have them in the first place?  In any
case, just how can all the combinations be tested?

This situation is made worse by the incomprehensible documentation.  I find
that his article and the KBs verge on the incomprehensible.  This is rampant
through Microsoft documentation.  I'm a University educated, native English
speaker with 12 years in computing and much of the Microsoft documentation
contains semantic contradictions, before it even gets to the technical
level.

At the technical level one wonders why anyone would design it they way it
was designed [writing on a read-only object being permitting based on some
perverse set of rules].  Combined with the confusing nature of the
documentation you are left wondering if how you thought it worked is
actually how it does work.

Sometimes, as a last, turgid, resort you just have to try it out and see how
it does work and hope that you are using it in the way it was intended and
in the right context.  This is no way to write software.  I don't want to
hope that it works.  I want to know that it works.

Looking at Windows 95 I see something that is maybe an order of magnitude
more complicated than Windows 3.1, still only solving the same problem.
Doing the same with more is not progress.  Exploiting Moore's Law may be
possible, but it's not desirable.


More ATM risks

<rchishol@math.ethz.ch>
Wed, 18 Sep 1996 21:00:44 +0200
Late last Monday night an interesting sight met me when I went to get cash
from an ATM.

These ATMs come with a small color screen a numeric keypad with a cancel and
an ok key, and 8 keys next to the screen. Normally you are first prompted to
insert your card and type in your key, after which you are presented with a
graphical menu allowing you to redraw money, check your account balance
change your PIN or retrieve your card.

This time things were different. First the person in front of me left the
ATM cursing loudly. When I got there, instead of the graphical menu the
screen was black with characters in white, several lines of "bad command or
filename" ending on a "C:\exe>" prompt.

After a little experimenting I found the keys 0-9 were mapped, as expected,
to 0-9, while the OK key was mapped to <ret> and the CORRECT key was mapped
to <del>. The keys next to the screen (of which there were 8) turned out to
be mapped to A,B,C,D,.,<esc> respectively, with the 2 last keys apparently
doing nothing. Since I didn't have a full keyboard, and lacked an <alt> key
I couldn't enter anything useful, so after some brief experimenting I left
it alone. I then called the banks 24 hour hot-line and told them their ATM
needed rebooting. I got a rather vague response along the lines of "oh well
just wait a few minutes and see".

The risks ?

Well where should I start...

1) It should never be possible for the user of an ATM to access it's operating
   system (if ms-dos + win 3.11 was the operating system, if not it shouldn't
   be possible to access to front-end either).

2) More to the point it shouldn't be possible to use anything but the
   authentication program prior to authentication. Note that during my
   experimenting with the ATM I hadn't put my card in.

3) I had always assumed that ATMs ran some kind of well designed embedded
   system. "Well designed" doesn't come to mind when talking about ms-dos.
   I am on the other hand certain that a pc with dos/windows is the cheapest
   way of building an ATM (cheap standard components, lots of programmers
   available for the platform, cheap standard tools available for development).
   What does this say about the general quality of the information resources
   used by this bank ?

4) Does the bank ever run virus-scanners on the pc in the ATM ? Having
   one of these things infected could lead to all kinds of problems. Of
   course virus-scanners are never 100% reliable.

Seeing the problems these machines seem to have, it is only fair for me to
report one occasion recently when my local ATM got something right: On
requesting a certain amount of money, the ATM always hands your card back
first, and then hands you the money. Last week my card jammed in the ATM and
I got neither card nor money. I went to the local branch of my bank
immediately, expecting to find the money I hadn't received deducted from my
account, but apparently it hadn't been, indicating that at least this time
the designers of said ATM got things right.

Rory Chisholm  rchishol@math.ethz.ch


411 needs 911

Kent Quirk <kentq@world.std.com>
Wed, 18 Sep 96 14:13:51 -0500
My family and I have just recently returned from a year's assignment
overseas and have moved back into our old house, which we rented out for the
year.  Of course, we gave up our old telephone number (though I kept my
e-mail address -- first things first!).  When we returned this year, it was
easy to get a new phone number; they still had my old account information
handy.

We've been gradually re-establishing contact with our friends.  This week,
two old friends told me that they'd been trying to call me, but that the
number information gave them was "not taking calls at this time".  I asked
what number it was, and they told me our *old* number from last year!  I
called information (411 for local information) myself, and was given the
correct number.  I asked one of them to check again; again she was given our
old number.  She tried to explain that she KNEW it was the wrong number, and
was told the equivalent of "Sorry, lady, that's what the computer says."
She had dialed 555-1212 (the standard for non-local information questions)

I called NYNEX service to ask what was going on.  She checked the records --
they were correct.  With me on the line, she called 555-1212 and was given
the right number.  She explained -- reasonably -- that she couldn't fix a
problem that didn't seem to exist.

My friend tried again.  Was again given the wrong number.  She then
explained, again, that the records were wrong.  At my request, she asked for
the information on exactly which company she was talking to and where they
got their data.  She explained that they were contractors for NYNEX, Then
she asked my friend for the correct information so she could change it!

The RISKS?  The usuals:

a) Assuming that old data is good data; somebody somewhere seems to have
decided that the same name at the same address must have the same number.

b) Changing the data without having any proof at all that the new data is
valid or that the change is authorized.  Can you imagine someone doing this
to a competitor?  It was awfully easy.

c) Our assumptions that there is somehow, somewhere, God's database of
telephone numbers managed and maintained by The Almighty Telephone Company,
and that changes propagate intelligently.  'Taint so, folks.

So, I THINK that my phone number is now correctly stored in the information
systems --- unless it gets overwritten by some other glitch somewhere else.
I guess I have to keep testing it for a while.

Kent Quirk, Acton, MA, USA   kentq@world.std.com
Phone: Call information ... if you dare.


Bringing Home the Anonymous Bacon

Peter Wayner <pcw@access.digex.net>
Tue, 17 Sep 1996 13:04:47 -0400
The *Baltimore Sun* reports in its 17 Sep 1996 issue that people in
Baltimore are paying for drugs with meat (page A1! [pretty saucy!]).
Perhaps this is not yet anonymous digital cash, but certainly anonymous.

   [Now someone is going to propose keeping a database of all sides of beef,
   and steganographically watermarking the meat in the context of digitally
   signed scannable grade-stamps.  Perhaps the next step in monitoring the
   private drug-meat trade would be to escrow the inspectors' private keys,
   derived from the product of two U.S. Primes, and put the database up on
   the net: the T-bone connected to the M-bone, etc.?  PGN]


Risks of not including appropriate manual overrides

William Hutchens <wthutchens@usa.pipeline.com>
Sun, 15 Sep 1996 05:44:01 GMT
Dave Schulman's recent contribution ("Failure-mode risks revealed by
Hurricane Fran" RISKS-18.42) reminded me of an incident that happened to me
a little while ago.  Back in December 1995, I was interviewing for a
residency position at a hospital in Toledo, and the hospital was being
generous enough to put its applicants up in one of the better hotels in the
city (which shall remain nameless).

The hotel had recently changed over to an electronic card system on their
doors rather that the traditional lock and key system.  The morning of my
interview, I was coming back from breakfast, and was planning to get my
suit jacket from my room and check out.  When I got to my room, I inserted
the keycard into the lock and, instead of getting the green LED and hearing
the mechanism unlocking, I was greeted with a series of all three LED's
blinking, in what I assume was an error code.

I went to the front desk and explained my situation to the manager who got
the 'master key' card and tried it in my lock, and got the same response as
my key.  She went back to the front desk and put in a call to maintenance.
A few minutes later, the maintenance man showed up with what was supposed to
be a supermaster card.  No dice, same result.

He went away and returned after a long wait with two other keycards.  (He
said that it took a while for him to get in touch with his supervisor who
gave him some 'special codes').  He tried the two cards in the lock; they
obviously did something since the LED's blinking pattern changed, but the
lock still wouldn't open.

He went away again, and he then returned along with the manager and two
other people.  The manager pulled out a laptop computer connected to a
probe which fit into the keycard slot.  While she was working, one of the
two other people identified herself as the 'head concierge' and began
furiously apologizing to me.  The manager did succeed in opening the lock
this time.

This anecdote illustrates a risk touched upon be Mr. Schulman -- the
problems with not including a manual override in a computer controlled
system.  Had the laptop computer not been able to convince the lock to
open, I don't know of any way short of brute force of getting the door open
as there were no openings in the lock other than the keycard slot.  (During
the times I was left waiting in the hallway, I was half expecting the
maintenance man to return with a sledgehammer).

Although I'm not intimately familiar with the internal workings of
electronic locks, I don't believe that it would be a problem to include a
conventional mechanical keyway in the lock.  In the ideal system, the
mechanical keys would be kept secure (say, in a safe in the office) and only
the electronic cards would be given to guests.  This would keep the
advantages of the electronic locks (convenience, the ability to change locks
easily whenever a guest leaves) without having to keep track of mechanical
keys.

Bill Hutchens  wthutchens@usa.pipeline.com


Re: Failure-mode risks revealed by Hurricane Fran (Schulman, R-18.44)

Steve Holzworth <sch@unx.sas.com>
Fri, 13 Sep 1996 13:52:51 -0400 (EDT)
I must take exception to most of what Dave states here. I'm a life-time
resident of North Carolina, and have lived in the described area
(Research Triangle Park) in central NC for twenty years.

>The area was clearly unprepared for a disaster of this magnitude, ...

Was Florida prepared for Homestead?  [>...]

1) Raleigh-Durham is over 100 miles inland from the coast. Hurricanes rarely
effect the area with more than peripheral tropical-storm-type weather. Fran
was a major exception to the rule. Flooding along the rivers and lakes here
qualified as "200-year flood" waters, meaning that you should expect floods
of this type only once every 200 years. Normal civil engineering for
building sites relies on meeting the "100 year flood" limit in most cases.

2) Power lines are aerial still throughout much of Raleigh because Raleigh
has been here a long time. It is impractical to bury all of the power lines
due to the sheer number of miles of cable involved. Most subdivisions and
other developments built in the last 15 years do have underground utilities.
In Cary nearby, building codes require it.

3) The central NC area is covered in trees. Many of the streets in the area,
particularly older parts of town, have large oaks with canopies extending
over the streets. The trees are one of the things that gives the area its
charm.

Most widespread power outages were caused by the downing of high-tension
distribution lines. More importantly, several gas leaks resulted from
uprooted trees pulling lines UP out of the ground, so burial is far from a
cure-all.  Major trees are down throughout the central NC area. The storm
had sustained winds of 67 mph in Raleigh, with gusts of up to 117mph.
Remember, this is over 100 miles inland...  [>...]

The telling point: "where hurricanes are an established fact of life."  Much
of Florida's vegetation is tropical, which is suited to severe winds and
storms. In contrast, Raleigh is known as the City of Oaks. Many of those
trees are over 300 years old. Many are uprooted or broken apart now.

Many power lines did come down. A week later, most people living in
municipalities have power restored. While inconvenient, I can deal with a
week of no power if the alternative is to cut down all of the trees anywhere
near a power line. In the hurricane aftermath at Homestead, FL, some people
didn't have power for months.  [>...]

Having a sole entrance gate that fails closed is stupid, but not
particularly unsafe. Virtually all mechanical entrance gates are designed
with shear pins in the mechanism. In the event of fire, the fire department
simply drives through the closed gates, that's what those big bumpers are
for.  Most municipalities here will not allow you to build a subdivision or
apartment complex with only one entrance. A tree could have blocked said
entrance just as easily as the closed gate.

Now compare this with the alarm system my neighbor's place of work has.  He
went to work to check on things in the aftermath of the storm. It turns out
that after the backup battery on their system wears out (approx. 3 hours),
the system OPENs all of the locks on the doors. Note that typical
card-key-locked doors have a manual handle on the inside to open the door
anyway if power is off, in addition to a mechanical key for entrance, so the
risks of being locked in or out are minimal. In his case, NOBODY was locked
out. Just what you need in the aftermath of a storm, when the opportunists
are about.  [>...]

It's a near miracle that more people didn't die, but it has nothing to do
with the utilities. The height of the storm was at approx. 3:00 AM, so most
people were at home. The eye of the hurricane went directly over Cary,
approximately 7 miles west of Raleigh. Carolina Power & Light and Duke Power
both scrambled to obtain line crews from other regional utilities even
before the storm had gone through the area. They have reciprocal agreements
with other utilities to supply crews in the event of an emergency of this
nature. Everyone actually expected the problems to occur along the coast.
BellSouth sent their generating units there to maintain power on their
cellular towers. They were dismayed to find that the problems occurred
exactly where they had just dispatched their crews from... While there was
extensive damage at the coast, the major damage was actually inland. Wake
County alone has estimated damage in excess of 900 million dollars.

Steve Holzworth SAS Institute Open Systems Cary, N.C.
R&D VMS/MAC/UNIX sch@unx.sas.com


Ariane 5 report, available on line (Re: Frisbie, RISKS-18.45)

"Richard J. Fateman" <fateman@peoplesparc.CS.Berkeley.EDU>
Fri, 13 Sep 1996 11:03:36 -0700
ARIANE 5 Flight 501 Failure, Report by the Inquiry Board,
The Chairman of the Board : Prof. J. L. Lions
is in fact available (in English) as
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

It is not that long, and explains that the proximate fault was a conversion
of a 64-bit float to a 16-bit integer.  [See RISKS-18.27,28,29,45.  PGN]

"The internal SRI [inertial reference system, en francais] software
exception was caused during execution of a data conversion from 64-bit
floating point to 16-bit signed integer value. The floating point number
which was converted had a value greater than what could be represented by a
16-bit signed integer. This resulted in an Operand Error. The data
conversion instructions (in Ada code) were not protected from causing an
Operand Error, although other conversions of comparable variables in the
same place in the code were protected.  "

The circumstances surrounding the code, testing, simulation, etc., are
probably worth reading, though the suggestions as to how to prevent such
problems in the future are mostly nontechnical, and where they are
technical, do not provide any great insight, unfortunately.

Richard Fateman, UC Berkeley


ETHICOMP96 MADRID 6-8 November 1996

Centre for Computing and Social Responsibility <ccsr@dmu.ac.uk>
Mon, 16 Sep 1996 20:39:07 +0100 (BST)
The third International Conference on Ethical Issues of Information
Technology, University of Salamanca in Madrid, Spain

Two international conferences have been held which address these issues. The
first was in the USA at Southern Connecticut State University and the
second, ETHICOMP95 was at De Montfort University in the UK. Both conferences
have been recognised as milestones in furthering the study and understanding
of the societal and ethical issues of IT. ETHICOMP96 brings together leading
international speakers to debate the current and future impact of IT and the
societal and ethical issues consequently raised. Madrid is an ideal location
for this conference as it is a major European capital with a high cultural,
academic and commercial reputation.

* Keynote Speakers

Professor James Moor, Dartmouth College, USA
Reason, Relativity and Responsibility in Computer Ethics

Professor Porfirio Barroso, University of Salamanca in Madrid,
A European dimension to codes of ethics for the computer profession

* A. Organisation and society structure and the location of work
* B. Privacy, property and computer misuse
* C. Value and accuracy of data and information
* D. Developing information systems now and in the future
* E. The IT Profession
* F. Education
* G. Frameworks

Conference Administrator, Maria Angeles Nevado
Conference Chairman, Porfirio Barroso
Contact address: Porfirio Barroso (ETHICOMP96), Clinica Puerta de Hierro,
  San Martin de Porres 4, 28035 Madrid, Spain
  Telephone and Fax: +34 1 3866775
  (To send a fax when you hear the answer machine press START)
  E-mail pbarroso@capilla.cph.es

To directly reach the ETHICOMP96 Homepage:
        http://www.cms.dmu.ac.uk/CCSR/ccsr/conf/ethicomp/ethicomp96.html

[Centre for Computing and Social Responsibility, Dept of Computer Science,
De Montfort University, The Gateway, LEICESTER, UK LE1 9BH ccsr@dmu.ac.uk
http://www.cms.dmu.ac.uk/CCSR/ ]  [This item excerpted for RISKS.]

Please report problems with the web pages to the maintainer

Top