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 7 Issue 54

Friday 16 September 1988

Contents

o CerGro voice mail hacked
PGN
o Re: Computer error in vote tallying
Andy Frake
o IEEE approval voting
Don Chiasson
o Reminder -- ROM is not necessarily nonalterable
Andrew Klossner
o Colwich Junction
Mark Brader
o Smoke Inhalation on Amtrak's "Crescent"
Mike Trout
o Computer assigned hotel rooms
Bruce Wampler
o Info on RISKS (comp.risks)

CerGro voice mail hacked

Really_From John Sheneman <Peter Neumann <neumann@csl.sri.com<>
Fri, 16 Sep 1988 12:23:47 PDT
"Voice mail user[s?] held up by hackers", by Paul Desmond, Staff Writer

LOS ANGELES -- A wholesale grocer here recently fell victim to a small band of
hackers that comandeered the firm's voice-messaging systems and used it to run
prostritution rings and pass information about drugs.
  The message system problems that have plagued Certified Grocers of California
Ltd. (CerGro) highlight a threat to which many unsuspecting users may be
vulnerable.
  Last October, some of CerGro's roughly 300 voice mail users began complaining
that they were unable to access their voice mailboxes because their passwords
had been invalidated.
  Upon investigation, Michael Marks, CerGro's communications supervisor,
discovered that hackers had overcome the security features of the system and
had reprogrammed up to 200 voice mailboxes for their own use.  The hackers were
accesssing the system using a toll-free 800 number CerGro maintained to let
travelling employees call in for messages.
  [The article goes on to indicate the mailboxes were being used for data on
stolen credit card numbers, cocaine prices, and male and female prostitution
rings.  CerGro removed the 800 number, and activity diminished.  However,
someone called to say that unless 10 voice mailboxes were established for their
use, the intruders would cause damage.  The mailboxes were established, but all
subsequent messages were recorded...]

[Source: Network World, 12 September 1988, courtesy of John Sheneman, 
8319 Kostner Ave., Skokie IL 60076]


Re: Computer error in vote tallying

FRAKE <andy@vax1.acs.udel.edu>
Thu, 15 Sep 88 12:03:58 EDT
A note was posted regarding a New York Times report of a data entry
error in a Delaware election.  The fact that 2828 was keyed in instead
of 28 is correct; Sam Beard was the recipient of these extra votes and
not S.B. Woo.  S.B. Woo, the current Lieutenant-Governor, now leads
Sam Beard by approximately 80 votes in the democratic primary for
Senator.  S.B. should be declared the official winner sometime
this morning.

Andrew Frake, Academic Computing Support, University of Delaware


IEEE approval voting

Don Chiasson <G.CHIASSON@DREA-XX.ARPA>
Fri, 16 Sep 88 11:41:36 ADT
     A couple of weeks ago, I voted in the annual election for the IEEE
executive.  This election has an interesting new procedure: approval voting.
In this method, you can vote for as many candidates as you wish.  The winning
candidate is the one who receives the most votes.  This offers a number of
fascinating options.  For example, you can can vote for the two best
candidates, or you can vote against someone by voting for everyone else.  I
like this more than the Hobson's choice of a simple yes to one candidate.
     What I would like to ask is: what can go wrong?  For example, someone
could alter ballots by marking additional places which would be difficult to
detect because the number of votes cast does not have to equal the number of
voters.  What else could go wrong?  What robust safeguards could be put in
place?
                                          Don

  [Some of the other problems are noted in the Saltman, Hoffman, Nilsson works
  recently cited, and in the talk by Eva Waskell summarized by Ron Newman -- 
  see RISKS-2.42 (14 Apr 86), also in ACM Software Engineering Notes vol 11 no 
  3 (July 1986, pp. 14-16).  PGN]


Reminder -- ROM is not necessarily nonalterable

Andrew Klossner <andrew%frip.gwd.tek.com@RELAY.CS.NET>
Fri, 16 Sep 88 12:15:46 PDT
   Re: Soviet Space Probe (dcf@ALLSPICE.LCS.MIT.EDU) (RISKS-7.52)
   Apparently, US craft have a "panic" mode that takes over if
   there is some problem ... are the panic commands in ROM so that
   they can never be overwritten?" 

I can't answer the question, but note that, for software operating in
the occasionally high-radiation environment of space, "being in ROM"
doesn't mean "can't be overwritten."

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]


Colwich Junction (UK, 1986)

Mark Brader <msb@sq.sq.com>
Wed, 14 Sep 88 05:17:54 EDT
A month or two ago, I wrote (RISKS-7.22) describing the Colwich Junction
train collision, on which a summary of the official report had appeared in
Modern Railways magazine.  To summarize briefly, the accident was caused by
driver error; a contributing cause was overcomplication of the signal
system; and another contributing cause was poor braking.  (One person--the
other driver--was killed; 32 of about 900 passengers were admitted to
hospital.  Fair, for a 90-100 mph head-on collision.)

Modern Railways and/or I implied that the reason for the poor braking was
that the wheel slide prevention (WSP) system, i.e. anti-lock braking, had
acted.  Several Risks readers said that this must be wrong, because antilock
braking should improve the braking, by keeping the wheel-rail friction
static rather than dynamic.  [That's not actually obviously true, because
the wheel-rail coefficient of friction must be closer to the coefficient of
friction within the brakes in a train than are the corres- ponding values in
a car.  And static friction at one place implies dynamic at the other.  But
it seems probable that WSP should improve braking.]


I have now obtained further information, including the official report (thanks,
Clive Feather!).  But the principal points (no pun intended) remain obscure.

First, I should point out that the WSP systems on British trains are not
actually designed to minimize the stopping distance.  They are installed to
stop wheelslip for two *other* reasons:

  - If a wheel slips during acceleration, it can spin so fast that the
    frictional heat will damage both wheel and rail surfaces.
  - If a wheel locks during braking, it will develop a flat spot,
    requiring its surface to be reground.

The general principle is to compare speeds of different axles, and assume
slipping if they differ by more than some threshold.  This obviously makes
the assumption that slipping wheels will slip unequally, which may not
actually always be true in the case of braking.

According to the official report on a different accident, the typical
coefficient of static (non-slipping) friction between rail and wheel on a
dry day is 0.3, and on a wet day 0.2; 0.1 suffices for normal braking, and
0.05 to prevent overrunning of signals (assuming no driver error).  The last
two figures may vary from one line to another, and thus not be exactly right
for the Colwich Jct. area.  Values worse than 0.05 occur only in conditions
such as heavy falls of leaves, or icing.

The unexplained part is this.  All witnesses agreed on the speed of the
train.  The driver and the other man in the cab agreed on where the brakes
had been put to emergency.  A witness heard a repetitive air sound coming
from several cars, indicating that the WSP was operating and therefore that
the brakes were indeed on hard.  But all witnesses also agreed that the
train decelerated more gently than in emergency braking.  The investigating
officer made a considerable number of tests, and reproduced the actual
stopping distance only by driving the train about 10 mph faster than
everyone said -- and running the test on wet track, when on the day of the
accident it was dry!

The WSP operates independently on every car, so multiple failures tending to
apply "too much protection" are not plausible.  Actually, some of the
surviving WSP units did have faults in that direction, but not enough of
them to explain what happened.

The report's conclusions and recommendations read in part:

#   Suffice it to say that I am satisfied that [the driver], once he
#   realized that he was about to run past Signal CH23 at Danger,
#   made a full emergency application of the brakes and there is no
#   substantial evidence to show whether or not the brakes operated
#   within the normal limits of efficiency.  ...

#   It is impossible to determine to what extent the operation of the
#   wheel slide prevention equipment or any other factor reduced the
#   efficiency of the braking, but there is no doubt that it was
#   reduced to a certain extent.

Notice that this leaves ambiguous whether it was reduced by the WSP or
by something else.  This is the report of an investigator who is stumped!

#   A full emergency application of the brakes is likely to introduce
#   wheel slide, even on dry rails, particularly if adhesion is reduced
#   by any contaminant,

(One might guess that *that's* the answer, but there was no evidence.)

#                       and thus activate the wheel slide prevention
#   equipment where fitted.  Full emergency brake applications ... are
#   made ... almost inevitably only when there is a true emergency.
#   A very small distance may make all the difference ... and thus with
#   the full emergency application of the brakes I believe that all
#   brakes should be fully applied, even if wheel slide does occur
#   and wheel flats are made on the wheels.  I recommend, therefore,
#   that consideration should be given to the fitting of equipment
#   to automatically eliminate the operation of wheel slide prevention
#   equipment in the event of an emergency brake application being made.

In short, the investigating officer, Major P. M. Olver, does not appear to
have considered the matter of static and dynamic friction; or perhaps Olver
is concerned more with the possibility of the WSP acting "by mistake" due to
a problem with it, but does not state this explicitly.  One wishes that in
addition to trying to reproduce the accident, the test runs had included
some with the WSP disabled.  The effect of that on the stopping distance
would have been highly germane to the recommendation of overridable WSP.

By the way, there have been several letters about the accident in Modern
Railways, but all commenting on the (pun coming) signal aspect.  Perhaps
I'll write a letter about this point myself.

Mark Brader


Smoke Inhalation on Amtrak's "Crescent"

Mike Trout <miket@brspyr1.brs.com>
15 Sep 88 17:35:00 GMT
Taken without permission from _The_Call_Board_, publication of the Mohawk &
Hudson chapter of the National Railway Historical Society, which in turn took
it from _Callboy_ of the Massachusetts Bay chapter, which in turn took it from
_The_470_ of the Portland chapter:

"About 125 children and 30 adults suffered from smoke inhalation after someone
pulled the emergency brake cord on Amtrak's "Crescent" while it was in a tunnel
near Washington Union Station on May 12, sending exhaust fumes spewing into the
cars.  The "Crescent" departed Washington southbound with two engines, 16 cars,
and about 400 passengers and 18 crew aboard.  Five minutes later, as the train
was in the tunnel, an unknown person for unknown reasons pulled the emergency
brake.  The train stopped in the tunnel with its emergency brakes applied, and
the second engine stalled or died.  The train crew, thinking that an air hose
that controls the brake system had parted, walked the train looking for such a
problem.  Finding none, the crew searched the cars and found that the emergency
brake handle in the first car had been pulled.  Unable to release the brakes,
the crew shut down the lead engine.  Trains that leave Washington Union Station
going south immediately enter a 3,900-foot tunnel that roughly goes under the
grassy Mall stretching form the Capitol to the Lincoln Memorial.  Another
Amtrak engine pulled the train back to the station, and buses retrieved the
passengers from the hospitals to take them to hotels for the night."

Would it not be fairly simple to install sensing devices in locomotive
cabs, indicating when an emergency brake handle had been pulled?  If the crew
knew at once the cause of the automatic brake application, they would not have
wasted time looking for broken air hoses.  And why, upon finding the real
cause, was the crew unable to then release the brakes?  Emergency brake systems
have been around for many, many decades.  One would think that they would have
been "perfected" by now.  Comments from railroading experts?

Michael Trout     UUCP:brspyr1!miket
BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110  (518) 783-1161


Computer assigned hotel rooms

Bruce Wampler <wampler@unmvax.unm.edu>
Wed, 14 Sep 88 19:20:26 MDT
I have also had the experience of getting occupied hotel rooms mixed up by a
clerk or computer, but which revealed a true software problem in the hotel's
billing system.

My wife and I had just arrived in LA from a 19 hour flight from Fiji, and
missed my connection, so was jet lagged. The clerk gave us the key for room
456, but apparently entered 546 into the machine (as I found out the next
morning.)  456 was unoccupied, so I didn't have any problem at the start.
Unfortunately, about 3 a.m., someone else was assigned to 456 and woke us up.
The dead bolt kept them out, but it sure messed up what little sleep we were
getting.

When we first arrived, we made several long distance calls that we expected to
be billed to the room.  Well, when we tried to pay the next morning, there was
no bill. Since the computer listed 456 as empty (the 3 a.m. person was assigned
another room, we were told), then there was no provision for recording phone
calls. I would have preferred the sleep, but at least we got free phone calls
for the trouble.  However, the hotel lost revenue because the billing software
didn't account for phone calls from empty rooms. I suppose if the staff knew
that, they could take advantage.

Bruce Wampler

Please report problems with the web pages to the maintainer

Top