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 10 Issue 75

Monday 7 January 1991

Contents

o NY area fiber-optic telephone cable severed; extensive effects
PGN
o British military information stolen
Charles Bryant
o Wargames and Reality
Robert Firth
o Re: Vicious elevators
Tom Lane
Mark Brader
Roland G. Ouellette
Jake Livni
o Re: Dehumanization by old Cobol programs
Karen Ward
o Re: "Computer Models Leave U.S. Leaders Sure of Victory"
Henry Spencer
o Re: "Computer Age Causes Key U.S. Data To Be Lost Forever"
Rick Smith
o Re: "Little pitchers have big ears": ATM Risk
Michael McKay
o Cars and Automation [again]
Balakumar
o Info on RISKS (comp.risks)

NY area fiber-optic telephone cable severed; extensive effects

"Peter G. Neumann" <neumann@csl.sri.com>
Sat, 5 Jan 1991 12:33:40 PST
An AT&T crew removing an old cable in Newark NJ accidentally severed a
fiber-optic cable carrying more than 100,000 calls.  Starting at 9:30am on 4
Jan 91, effects included shutdown of the New York Mercantile Exchange, several
commodities exchanges, disruption of FAA air-traffic control communication in
NY, Washington and Boston, causing lengthy flight delays at those and impinging
airports, and blockage of 60% of long-distance telephone calls into and out of
NY, for much of the day.  (AP, 5 Jan 91).  This came as we approach the
anniversary of the 15 Jan 90 nine-hour outage due to a self-propagating bug in
the recovery software.


British military information stolen

Charles Bryant <ch@dce.ie>
Thu, 3 Jan 91 16:56:55 GMT
An article in `The Irish Times' Jan 3 states that extremely sensitive
information relating to British military operations in the Gulf may
still be on a computer which was stolen from a staff car beloning to
Wing Commander David Farquhar on December 17th. The laptop was stolen
along with some documents. The documents were later found in a skip,
but the computer is still missing.

Presumably the inherent value of the computer made the thief keep it.

Charles Bryant (ch@dce.ie)

  [A skip is an open-top container for rubbish (garbage) which is about the
  size of a small car and is delivered and collected by a special type of
  vehicle. It must be called something different in the US.]  [Dumpster]


Wargames and Reality

<firth@SEI.CMU.EDU>
Fri, 4 Jan 91 11:14:00 -0500
I too am concerned at the seemingly naive acceptance by the Department of
Defense of the trustworthiness of simulated combat.  Others have pointed out
that the military cheat at war games, citing especially the Battle of Midway.
That is a clear risk.  As another example, the German General Staff often gamed
the Schlieffen Plan, and also often cheated.

However, there is in my opinion a further, and equally significant risk, even
in an honestly conducted simulation, and that is the risk that the simulation
incorporate some fallacy critical to the simulated outcome.  As an example,
consider how, in the 1930s, a possible German invasion of France would be
gamed.  On the map, the Ardennes would be clearly labelled 'heavily wooded:
impassable to tanks', as was the general opinion of the time.  A German player
who attempted an armoured breakthrough at that point would be immediately
stopped by the referee, and informed of his rule violation.  But we all know
what happenned in 1940.

To relate this to today: the performance figures for military tanks,
helicopters, aeroplanes &c are usually taken either from nominal specifications
or from the results of field exercises in temperate terrain.  However, for the
present terrain and climate, values for speed, range, manoeuverability and
endurance should be adjusted downwards, by some unknown but probably drastic
amount.  Has this been done?  If so, where did the numbers come from?

Robert Firth


Re: Vicious elevator door failure recovery (RISKS-10.74)

&om.Lane@G.GP.CS.CMU.EDU>
Thu, 3 Jan 1991 21:39-EST
Actually, I believe that elevators with mechanical door sensors (strips)
are also programmed to override the sensors and close anyway after a
certain number of tries.  (I know for sure that the ones in Wean Hall at
CMU do this; they are of '60s vintage.  They even have the warning buzz
you describe.)  The reasoning, presumably, is the same as you gave: to
defend against sensor failures and denial-of-service attacks.

However, the door closing mechanisms (at least at Wean Hall) are not
strong enough to actually hurt a person; in fact they can be forced back
by a reasonably determined push.  This strikes me as a far better failsafe
design than relying on a backup sensor, which is what I think you are
advocating.  (Think about common-mode failures...)  The doors *are* strong
enough to be uncomfortable, which I'm sure is deliberate.

Of course, that's not to say that the elevator you encountered is actually
designed properly; but the mere use of electrical rather than mechanical
sensors does not seem to me to increase the risk in a properly designed
system.  Mechanical sensors fail, too.
                                                tom lane
      ...!cs.cmu.edu!tgl   tgl%cs.cmu.edu@cmuccvma    >internet:tgl@cs.cmu.edu


Re: Vicious elevator door failure recovery

Mark Brader <msb@sq.com>
Fri, 4 Jan 1991 11:52:00 -0500
On some elevators this sensor is not a discrete strip, but is built into
the seemingly rigid edge of one of the two layers of door.  Either it
senses flexing of the edge, or it senses resistance to the door being
closed; I can't tell which.  It does require more force to operate than
the traditional rubber strip, but not so much as to make a "meaningful
attempt to crush" the user.  Perhaps the elevator in question actually
had this type of sensor, but it was not working.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com


Other vicious elevators

Roland G. Ouellette <rouellet@pinnacle.crhc.uiuc.edu>
Fri, 4 Jan 91 11:31:15 CST
The University of Illinois is suing Otis Elevator because of a pair of
these hungry elevators.  They've bitten a few people, most notably
people pushing computers and/or huge boxes onto and off of the elevator.


Re: Vicious elevator door failure recovery (Jackson, RISKS-10.74)

jake@mars.bony.com &ake Livni>
Fri, 4 Jan 91 14:32:15 EST
Curtis Jackson writes about elevator doors that close, regardless of who's in
the way.  I know of such elevators, too.  (Incidentally, they may use some
other sensing mechanism like micro-switches rather than mechanical panels or
light beams; an elevator engineer once told me that some elevators use
micro-switches in the floor to estimate load and then adjust motor settings
accordingly.)

The elevator doors I have seen withdraw several times before becoming
insistent, then slowly beep their way closed.  This, however, is always
followed a few seconds later by a voice on the intercom from a guard downstairs
asking if anything is wrong.  A human gets into the loop.  Guards are always on
duty, though I don't know what controls over the elevator they might have from
their station.
                                        Jake     <AKE@DBCLUA>


Re: Dehumanization by old Cobol programs

Karen Ward <wardk@cse.ogi.edu>
Fri, 4 Jan 91 08:59:43 -0800
Darrell D. E. Long writes of thoughtlessly-designed billing software that
assumes that all people have only one middle initial.  This is not, as he
implies, only a risk of old COBOL programs.  Instead, he has identified one
aspect of a larger ongoing problem: balancing the desire to edit to ensure data
validity against the need for sufficient flexibility to accomodate unusual
cases.  Within the past year alone I have had to argue against system designs
that would assume that:

- All names look like "Given I. Family" (I have no middle initial,
  and my SE has only one name.  Many of our customers prefer their
  family name printed first)

- All children share their parents' family name

- Leading zeros should never print (There are both post-office boxes
  and street addresses in Portland, Oregon that have significant leading
  zeros, that is, the same number without the leading zero represents a
  different address)

- Zipcodes are always 5 (or 9) digits (non-USA zipcodes?)

- Names never contain special characters (Hyphens?  Also, some
  businesses have exclamation points and numbers in their names)

- All names start with a capital letter followed by lower case (I know
  of at least one person whose name starts with a lower case and contains
  an embedded upper case.  I know of another whose full name is III,
  pronounced "three")

For the applications I most frequently work with - business systems for
a public utility - I try to keep limiting assumptions about personal
information (names, addresses) to a minimum, and to edit with warnings
that can be overridden.  Our customers will forgive a one-time error
far more quickly than they will forgive our inability to correct that error.

Karen Ward (wardk@cse.ogi.edu)


Re: "Computer Models Leave U.S. Leaders Sure of Victory"

Henry Spencer <henry@zoo.toronto.edu>
Fri, 4 Jan 91 21:11:59 GMT
>  ...Red Force electronic warfare is reduced or eliminated because its
>  success causes a complete breakdown in exercise force command and
>  control...

After a discussion several years ago on a vaguely similar theme, I had
a bit of correspondence with a fellow who'd spent some time in electronic
warfare in the Army.  (I suspect I should not identify him.)  He said that
they were normally under severe restrictions in what they could do as part
of field exercises, and as a result the folks who were supposed to benefit
from said exercises had gotten very blase' about communications practices
and the like.  Then the EW people, after a lot of begging and pleading,
got permission to take the gloves off just once and show the commanders
what serious EW could do.  His summary of the results:  "we paralyzed them".

Henry Spencer at U of Toronto Zoology  henry@zoo.toronto.edu   utzoo!henry


Re: "Computer Age Causes Key U.S. Data To Be Lost Forever"

Rick Smith <smith@SCTC.COM>
Sun, 7 Jan 90 11:18:14 CST
I've been a packrat for most of my life and I've done historical research
and I've worked with databases. But I'm finding it very hard to mourn the
*general problem* of fading and decomposing magnetic media.

For one thing, the data is meaningless if you don't know how it was
collected. NASA has zillions of tapes, but do we really know how all
of that data was collected? Which sensor? What setting? Once this
information is lost, the data itself is just a tombstone.

For another thing, data has no value for its own sake. If there's a
researcher that can use some of the computer readable data out
there, then that's great. But I don't think we should save every
last byte "just in case" someone wants to use it in their dissertation
on rat populations in rural Podunk. The pot only holds so much. What
do we discard instead?

Sure, we should save what is "reasonable." For lack of a better
measure, let's save what people will use. For example, we might want
to establish a "computer research data recovery fund" which paid the
costs for grad students to recover "threatened" digital data and use it
in their research. The costs would pay for converting the data to work
on the researcher's PC or whatever and for a copy of the data in an
archival format. This is somewhat similar to the way that various
(usually state) historical societies are making microfilm collections
of community newspapers.

I don't know what a good "archival format" would be, however. I read recent
descriptions of de-lamination problems with CDs, and I have personal experience
with the unreliability of paper tape ...

Rick Arden Hills, Secure Computing Technology Corporation, Minnesota


RE: "Little pitchers have big ears": ATM Risk

<CKAY_MICHAEL@atalla.com [tandem.com?]>
3 Jan 91 16:38:00 +1600
I am currently the sustaining software engineer for the product mentioned by
zowie in his posting (11-25-90), and I wanted to clarify some things.  He was
disturbed by hearing modem tones during an ATM card activation at a Wells Fargo
Bank branch.  In fact, recording the 300 BAUD transaction (or tapping the phone
line) would not reveal his friend's PIN.  The PIN is encrypted by the terminal,
using DES and a "Unique Key Per Transaction (UKPT)" algorithm (our newer
terminals conform to ANSI 9-24, Wells Fargo still uses some older terminals
that predate 9-24 with a psuedo UKPT).

Once the transaction is reported to the host, a hardware security box
translates the PIN from the terminal's key to some irrreversible internal
format.  Once the PIN is entered into the terminal, it never appears in the
clear (that is to say unencrypted) in any computer.  This is much better than
the usual situation, where you would either be assigned a PIN, or have to write
down your PIN and have somebody enter it for you.  If anybody would like more
details on the process, feel free to contact me.

Michael McKay   (MCKAY_MICHAEL @ tandem.com)  (408) 435-8850

US MAIL: Atalla, A Tandem Company, 2304 Zanker Road, San Jose, CA 95131


Cars and Automation [again]

&ala.Kumar@IUS3.IUS.CS.CMU.EDU>
Fri, 4 Jan 1991 14:18-EST
We were driving at 70 mph [automatic transmission, new car < 1 K
miles]. All of a sudden the speedometer cable got cut [I believe] and
the needle fell back to 0 mph. In addition there was a heavy noise and
could feel the drag on the engine. I pulled out, put it in neutral and
raised the engine hood. Nothing wrong with the engine. All other things were
OK. Car moved without much problem up to 15 mph.  Beyond that it felt
like driving at Ist gear. Auto mechanic checked it too. Conclusion:

"Either auto transmission or fuel injection system is taking the input/cue from
the speedometer. They think the car is at a lower speed and act accordingly"

Could someone explain the situation?

We could have got into a major accident. Sure, the cause of the accident would
have been careless driver....  When I called the rental company for
replacement, they could not locate my file on the computer [god knows why] and
it took three hours ........
                                         -balakumar    pbk@cs.cmu.edu

    [Please respond directly to balakumar, unless this really is a
    computer-related problem.  Otherwise, try the two brothers in Boston
    on NPR.  PGN]

Please report problems with the web pages to the maintainer

Top