The RISKS Digest
Volume 12 Issue 62

Tuesday, 12th November 1991

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

Leaves cause railway signal failure
Graeme Tozer
Computer controlled train is unsafer
Bob Devine
More air scares and phone moans
PGN
RISKS of infrared car door locks
Andrew Evans
Summary of responses on UK phone card risks
Graham Toal
Re: Licensing of Software Developers
Brinton Cooper
David Parnas
Searching a library database
Matthew Merzbacher
Audi Pedal Pushers
Bob Ayers [and others]
Religious bias in RISKS posts is counter-productive
Bill Gray
Re: Radar
Eric Florack
Security failure: recycled "unlisted" phone number
Steven J. Edwards
You can help build the National Public Network.
Gerard Van der Leun
Call for Papers: 5th Annual Computer Virus & Security Conference
Jack Holleran
Info on RISKS (comp.risks)

Leaves cause railway signal failure

Graeme Tozer <graeme@inmos.com>
Tue, 12 Nov 91 13:32:02 GMT
The following story was reported in "Computer Weekly", November 7th.

AUTUMN LEAVES FOX BR'S SIGNAL SYSTEM, by Tony Collins.

Autumn leaves have taken British Rail's latest computerised signalling system
by surprise.  BR'S Integrated Electronic Control Centre (ICC), based on three
parallel systems, is designed as a fail-safe answer to the older
electromechanical processes.  Installed at Liverpool Street, Newcastle, York
and Leamington Spa the IECC is supposed to tell signals staff exactly where
trains are located by displaying positions on a visual display unit.  But BR
discovered this week that the system is only fail-safe when tracks are free of
Autumn leaves. It found that leaves under wheels cause trains to `disappear'
from computer circuits.  The leaves form an insulating paste, preventing the
wheels making contact with sensors which tell systems the train's position.

On Monday hundreds of passengers were stranded at stations as services were
canceled or delayed as BR struggled to identify the location of trains.  A BR
spokesman said the problem was being overcome by using older, heavier trains
whose wheels make better contact with the signalling sensors. He stressed that
the problem of Autumn leaves would in no way affect BR's plans to expand its
use of IECC systems.

Graeme Tozer, iq Software Group, INMOS Ltd., 1000, Aztec West, Almondsbury,
Bristol BS12 4SQ, UK.  +44 454 616616  graeme@inmos.co.uk ...!ukc!inmos!graeme

   [Leaves something to be desired?  NO WAY.  But if you tried to count how
   many there were, you would probably take leaves of your census.  PGN]


Computer controlled train is unsafer

Bob Devine 12-Nov-1991 1302 <devine@cookie.enet.dec.com>
Tue, 12 Nov 91 12:17:22 PST
From "The Denver Post" comes a story of a train crash caused by the elimination
of a safety device for a modern locomotive engine.

The root cause of the crash was that the engineer fell and hit his head causing
him to lose consciousness momentarily.  Meanwhile the 4 engines started rolling
down a slight hill.  None of the engines were running but because of their
weight (380,000 pounds each) and the distance they rolled (about 25 miles), the
engines went as fast as 75 mph.  They finally stopped when they hit a parked
train.

The computer risk in this is (quote from Post):

    Years ago, locomotives had a "dead man's control" to stop
    a train if the engineer released tension on the throttle.
    Now rail engines use sophisticated electrical devices to
    determine if something is wrong with the engineer [the NTSB guy] said.
    In this case, they did not apply because there was no engineer aboard.

The article did not say what the seemingly omniscient "sophisticated electrical
devices" are nor does it say if the locomotive engineers have to be running to
generate electricity for those devices...
                                                      Bob Devine


More air scares and phone moans

"Peter G. Neumann" <neumann@csl.sri.com>
Sun, 10 Nov 91 17:48:10 PST
An AP item from 10 Nov 91 adds a few more air and phone problems to our
burgeoning archives.  Here are a few excerpts:

   The Federal Aviation Administration, in a report to a House subcommittee,
said that from August 1990 to August 1991 there were 114 "major
telecommunications outages" across the country that led to flight delays and
generated safety concerns.
   On May 4, four of the FAA's 20 major air traffic control centers shut down
for five hours and 22 minutes. The cause: "Fiber cable cut by farmer burying
dead cow. Lost 27 circuits. Massive operational impact."
   A year ago, the Kansas City, Mo., air traffic center lost communications for
four hours and 16 minutes. The cause: "Beaver chewed fiber cable."
   Other causes include lightning strikes, misplaced backhoe buckets, blown
fuses and computer problems.
   Most recently, two technicians in an AT&T long distance station in suburban
Boston put switching components on a table with other, unmarked components,
then put the wrong parts back into the machine.  That led to a three-hour loss
of long distance service and flight delays at Logan International Airport.
   On Sept. 17, AT&T technicians in New York attending a seminar on warning
systems failed to respond to an activated alarm for six hours. The resulting
power failure blocked nearly 5 million domestic and international calls and
crippled air travel throughout the Northeast. Some 1,174 flights were canceled
or delayed and 85,000 passengers including Al Sikes [FCC Chairman] and Ervin
Duggan [panel member] were inconvenienced.  [See RISKS-12.36, 38, 43...]

    [I guess that got their attention!  An example of Sikes-seeing?
    Of course, crossing the Kansas City tale with Graeme Tozer's fall
    rail saga above, we get "Leave it to Beaver's high-fiber diet."
      <Yes, you're right.  It is getting late again.>  PGN]


RISKS of infrared car door locks

Andrew Evans <andrew@airs.com>
12 Nov 91 19:18:20 GMT
In the current issue of "Car and Driver" is an article about the new
Mercedes-Benz 400 SE.  One of the features mentioned was its infrared remote
locking/unlocking system, in which the transmitter on the key and the receiver
in the door would recode themselves each time they were used to prevent
unauthorized entry.

This leads me to wonder: could you use one of those programmable universal
infrared remote controls to learn the pulse sequence of an infrared key, and
use the programmed remote to unlock the car?  Anyone have both a car and a
remote to test this?

    [NEW POLICY ON SUCH TOPICS: PLEASE RESPOND TO THE ORIGINAL CONTRIBUTOR
    AND HOPE THAT HE OR SHE DISTILLS THE RELEVANT RESPONSES SUFFICIENTLY THAT
    THEY ARE INTERESTING, RELEVANT, etc. TO RISKS READERS.  RESPONSES ONLY TO
    RISKS WILL BE IGNORED BY ME.  THANKS.  THE MANAGEMENT.  PGN]


Summary of responses on UK phone card risks

Graham Toal <gtoal@gem.stack.urc.tue.nl>
11 Nov 91 22:11:13 GMT
I posted recently of the risks of UK calling cards - the PIN is dialed
as an extension of the number, and therefore can be logged on call-loggers,
as used in hotels, businesses, local government offices etc.

I wondered how this had been solved in the US, as I hadn't heard of the
the problem before and would have expected the US to hit it first.

The answer is that the US thought about it in advance! :-) [typical BT] The US
system effectively succeeds in placing a call *before* dialing the PIN,
therefore the PIN goes through as data and not part of the number.  BT could
perhaps consider switching to such a system.  However I *think* the US system
would mean that pulse-dialing phones would be unusable.  The UK system
certainly works on pulse-dial phones.

Thanks for all the replies.                Graham


Re: Licensing of Software Developers (RISKS-12.58)

Brinton Cooper <abc@BRL.MIL>
Sun, 10 Nov 91 23:39:21 EST
David Parnas writes

>   I don't believe that we can
> afford to ignore the issue of qualifications for software professionals, but
> the question we should be debating is what those qualifications should be and
> who should be covered.  It is not an all-or-nothing problem.

Earlier in the same contribution, he wrote:

>  This is exactly analogous to the situation in Medicine.  Government's decide
>  that you must have a medical license to perform heart surgery.  Doctor's decide
>  who can have such a license.  Doctor's consider themselves a self-enforcing
>  profession, but the government does not allow them to determine their own
>  "scope".

This indicates a principal difficulty with licensing software professionals.
In medicine, law, and engineering, the applicant for license has already been
through a program of instruction and clinical practice that has been accredited
by a nationally-recognized professional society.  Applicant must provide some
evidence of experience and pass some sort of formal examination. Thus, the
licensing process has (at least) three components: formal and recognized
education, practice, and formal examination.  In the main, I believe it works
well in all three professions.  At least it sets lower bounds to competence
with a high degree of reliability.

On the other hand, some of our finest software professionals have skipped or
prematurely terminated the "formal" part of training in accredited (or
otherwise) institutions.  Thus, a licensing authority would have to review
their cases solely on the basis of (claimed) experience and a formal
examination.  There seem to be too many points of competence that are missed
under these conditions.

Anticipating the next argument, I am well aware that we would be lots poorer
without the notable works of a few university drop-outs and at least one who
never even finished high school!  I dare say that medicine, law, and
engineering, in their respective infancies, produced similar genius-level
practitioners.  But today, these are no longer allowed.  I fear that licensing
of software professionals would deny us the talents of similar visionaries.

Are we ready for this?  ACM, et al., have been accrediting CS departments for
only a few years.  Academics continue to debate whether CS belongs in the
school of engineering or of arts & sciences in the university.  Perhaps it is
appropriate that we begin this discussion now and carry it on for a very long
time.
                                      _Brint


Re: Licensing of Software Developers (RISKS-12.58)

David Parnas <parnas@qusunt.eng.McMaster.CA>
Mon, 11 Nov 91 13:58:05 EST
We certainly are ready.  The engineering societies already have mechanisms for
handling people who do not have accredited degrees.  I believe that the only
error was made 25 years ago when people treated "computer science" as a science
rather than as an engineering speciality.
                                                       Dave


Searching a library database

Matthew Merzbacher <matthew@lynn.CS.UCLA.EDU>
Tue, 12 Nov 91 01:21:48 GMT
Orion, UCLA's online library database, has a reasonable user interface, but
sometimes it's just too smart.  Orion's title matching algorithm is to take the
user-provided phrase, remove punctuation, compress blanks, do some other
routine stuff, and then check the online index.  Thus, if you asked for works
by J.P. Morgan, you'd also get works entered under J P Morgan (without the
periods).

The problem is, that Orion also does its transformations on keywords and
titles.  Pity the poor user who wanted to find all the books with "C++"
as a keyword or title word.  Orion dutifully transforms the request and
finds all books with "C" as a keyword or title word.

And, according to user services, there's not a darned thing that can be
done about it.  There's no bypassing that particular "feature" of Orion.

Matthew Merzbacher   UUCP: ...!{uunet|rutgers|ucbvax}!cs.ucla.edu!matthew


Audi Pedal Pushers (Re: Seecof, RISKS-12.60, Reed, RISKS-12.61)

Bob Ayers <ayers@Pa.dec.com>
Fri, 8 Nov 91 11:41:46 -0800
I suggest that you filter out references, especially incorrect ones, to the
supposed Audi problem of a couple of years ago.

RISKS-12.61 repeats the claim that the pedals of the Audi were especially close
together and easy to confuse.  In fact, they were, as I recall, in the 2nd
quartile of closeness, and Audi's were *not* the most popular car to suffer
'sudden acceleration' incidents.

   [Good idea.  We had extended discussions in RISKS-4.17 and 7.25 on the
   Audi.  RISKS-8.87 discussed the pedal puddle.  More in RISKS-9.01.
   The Aud-acious bogosity of Audi pedal propinquity was also noted by
   trt@cs.duke.edu (Thomas R. Truscott) and hsu@eng.umd.edu (David Hsu), along
   with other comments somewhat peripheral to the original discussion.  On the
   other foot, Norman Yarvin <yarvin-norman@CS.YALE.EDU> notes the desirability
   of pedal propinquity for heel-and-toe shifting.  And
   chaz_heritage.wgc1@rx.xerox.com suggests that perhaps

     "... American customers simply lack the skill necessary to drive a
     sophisticated car like an Audi successfully? The American driving tests
     are notoriously lax; few Americans can drive a manual-transmission car;
     and Americans are far more prone than Europeans to being so grossly
     overweight that they have difficulty getting into, let alone driving
     safely, an average-size car.  American cars are in general badly designed,
     usually by marketing suits who don't `wanna-be' engineers at all, and with
     the intention of pandering to ill-informed fashion (e.g., front-wheel drive
     for limos) rather than producing anything worth having; they are
     excessively large and heavy, and their handling (I speak from experience)
     is utterly diabolical, barely safe in a straight line."

   [Excerpt from a message that was probably not relevant anyway, but it might
   make a few folks think...  Remember, many of the risks are in THE PEOPLE AS
   WELL AS IN THE TECHNOLOGY...  Sorry if I have truncated any other worthy
   opinions...  PGN]


Religious bias in RISKS is counter-productive (34AEJ7D, RISKS-12.61)

<gray@s5000.rsvl.unisys.com>
Fri, 8 Nov 91 15:30:16 CST
I quote from your masthead:

   "The RISKS Forum is moderated.  Contributions should be relevant, sound, in
    good taste, objective, coherent, concise, and nonrepetitious."
    ^^^^^^^^^^  ^^^^^^^^^
Now I quote from a recent post received here on 8 November 1991:

Date: Mon, 04 Nov 91 11:36:47 EST
From: 34AEJ7D@cmuvm.bitnet
Subject: Another smart card risk

   ...  I believe the VVC is in use, or testing, in the
   Mormon-owned Safeway foodstore chain.
   ^^^^^^^^^^^^
First, I see an assertion that a particular church owns a food store chain.  No
attribution for this claim is given, not surprising since it is false.  I took
an entire 60 seconds to call the Piper Jaffray & Hopwood stock brokerage office
in Minneapolis and learn that Safeway Stores is publicly traded, had a 52-wk
high of 21 5/8, a 52-wk low of 11 1/4, and closed off a half point at 18 1/4.

Even if the church in question did own the stores, how is that relevant to the
story--except as a feeble attempt to smear a church with the stain of
profiteering?  That datum, even had it been true, contributed nothing to
anyone's appreciation of any RISK.

Yellow journalism like this coming from a biased reporter is unsurprising.
For it to slip past a credible editor is most disappointing.

I call upon you to retract that allegation and avoid similar jabs at
religious groups in the future.
                                                  Bill

    [Bill, Sorry.  I should have yanked that one.  But I do wish contributors
    would exercise a little more self-discipline.  Remember that on-line
    newsgroups are a wonderful opportunity for maturity to emerge on the
    part of the discussants.  However, the expectations that your moderator can
    catch EVERYTHING is unreal.  On the other hand, I really should have caught
    that one.  Thanks for the reminder.  PGN]


Re: Radar

<Eric_Florack.Wbst311@xerox.com>
Mon, 11 Nov 1991 12:44:36 PST
I've noted with some degree of wry humor, all the glowing reports (pun
intended) about the good that radar can do.  Clive Dawson, for example:

<>What about other uses for unattended radar?  I know of several residential
neighborhoods that use huge(!) speed bumps (the kind would rip out your
suspension at anything over 15 mph but are a pain at any speed) to enforce
speed limits.  I can imagine a system in which radar could raise physical
devices which would make speeding noticeable (1-inch bumps), unpleasant (4-inch
bumps), or impossible (parking-lot-style spikes?! ;-), thus allowing a smooth
ride for vehicles within the speed limit.<<

Consider, however: Simply running through a radar trap exposes the driver and
passengers to more X-band radiation than OSHA law allows.

Consider: Cops in one state (I forget which) refuse now to use the radar `guns'
after being diagnosed as having cancer as a direct result of using the devices.

Seems perhaps another way to achive the goals is in order.

I can't allow the foregoing to go out without adding that I've always thought
speed radar had far less to do with public safety than with making money for
the state.


Security failure: recycled "unlisted" phone number

Steven J. Edwards <sje@xylos.ma30.bull.com>
Fri, 8 Nov 91 14:49:58 EST
Security failure: recycled "unlisted" phone number (Steven Edwards)

    Four months ago I obtained an unlisted telephone number by New England
Telephone as part of the service for a new residence.  I was told at the time
that this number had not seen recent use and was not assigned to anyone else,
nor was it present in the NET telephone directories or from NET directory
assistance (555-1212).  There was a fairly hefty tariff associated with
installation (about US$50, just for a software entry; all hardware was in
place).  There was also a cost of about US$25 for a service request for getting
an unpublished and unlisted number, along with a monthly tariff of about US$4
for the same.  These expenses were justified at the time by an NET service
representative as being necessary for "the high level of service traditionally
supplied by New England Telephone".

    The number was to be used mostly for automated computer
telecommunications, so I had no desire for unwanted incoming voice calls.
After noting some problems with the computer connection over the first three
months' usage, I installed a voice answering machine and recorder on the line.
I set the outgoing tape to answer with the complete telephone number dialed so
wrong number dialers would realize their mistake.  Much to my surprise, I would
come home after work and find a number of calls for people I did not know from
people I did not know.  Furthermore, a number of these calls surprisingly
contained rather intimate details of people's business and private lives.  The
callers obviously thought they were dealing the correct number because of the
outgoing message.

    I had been unable to track the origin of these calls until yesterday
evening, as most of the callers thought that the party they were trying to call
knew their return phone number.  Finally, one caller did leave her return
number (she was not at her regular number, I suppose).  I contacted her and was
able to get the correct spelling of the name of whom she thought she called.  I
was also told that she had gotten the number from NET directory assistance.

    A quick check of the new 1991-1992 Nynex White Pages phone book for my
area found my "unlisted" number listed on page 164 under another person's name!
Another entry with the same last name, but different first name, was located.
Furthermore, a call to directory assistance proved that their computer was
still supplying this false information.  It took a nearly thirty minute long
conversation with three different people at NET directory assistance to
convince them that they were giving out false information.  Because of my
knowledge of the first names referenced in messages left on my recorder (along
with other information inadvertently recorded), I correctly guessed that this
was a husband and wife living at different addresses and they had recently
moved into a single residence.  I called the other (correct) number and
confirmed that this was all a result of a big screw-up by NET.  I also took the
opportunity to relate several of the topics referenced in the supposed
confidential calls.  The intended recipients were quite surprised, to say the
least.  Fortunately for them, I am not a crook; however, if it had been a crook
that had their old phone number, the opportunities for fraud may have been too
tempting to resist.

    First moral of the story: if you ask for an unlisted number, don't
assume that you'll get one that was not very recently in use by another party.

    Second moral of the story: if you change residences, make sure that
your old listing is deleted by the directory provider and is correctly handled
by directory assistance.

    Third moral of the story: never leave personal or otherwise
confidential information on a recording answering machine unless you are
absolutely certain that only the intended receiver will replay such recordings.

Steven J. Edwards, Bull HN Information Systems Inc., 300 Concord Road
Billerica, MA 01821   (508) 294-3484


You can help build the National Public Network. Here's how.

Gerard Van der Leun <van@eff.org>
Tue, 12 Nov 1991 21:24:58 -0500
     THE NATIONAL PUBLIC NETWORK BEGINS NOW. YOU CAN HELP BUILD IT.

Telecommunications in the United States is at a crossroads.  With the Regional
Bell Operating Companies now free to provide content, the shape of the
information networking is about to be irrevocably altered.  But will that
network be the open, accessible, affordable network that the American public
needs?  You can help decide this question.

The Electronic Frontier Foundation recently presented a plan to Congress
calling for the immediate deployment of a national network based on existing
ISDN technology, accessible to anyone with a telephone connection, and priced
like local voice service.  We believe deployment of such a platform will spur
the development of innovative new information services, and maximize freedom,
competitiveness, and civil liberties throughout the nation.

The EFF is testifying before Congress and the FCC; making presentations to
public utility commissions from Massachusetts to California; and meeting with
representatives from telephone companies, publishers, consumer advocates, and
other stakeholders in the telecommunications policy debate.

The EFF believes that participants on the Internet, as pioneers on the
electronic frontier, need to have their voices heard at this critical moment.

To automatically receive a description of the platform and details, send mail
to archive-server@eff.org, with the following line:

send documents open-platform-overview

or send mail to eff@eff.org.


Call for Papers - Fifth Annual Computer Virus & Security Conference

Jack Holleran <Holleran@DOCKMASTER.NCSC.MIL>
Mon, 11 Nov 91 13:46 EST
  Dates:  March 11-13, 1992
  Place:  Marriott Marquis and Summit Hotel, New York City

TOPICS of Interest:
  * Prevention, Detection, and Recovery from Viruses and other
    Unauthorized Usage
  * Case studies of mainframe, PC and/or network security
  * Access control, accountability, audit, data recovery
  * Surveys or demonstrations of products & techniques
  * Particulars of LAN, UNIX, cryptology, military use
  * Computer crime, law, data liability, related contexts
  * US/International sharing of Research & Techniques

PAPER Submission requirements:
  A submission may take the format of *EITHER* a long abstract (3-5 double
spaced pages) *OR* a draft final paper.  Final papers will usually be 6-20
pages in length.  Four copies of the submission should be sent via regular
Government Postal Service to the follow address:
               Program Chairman
               Computer VIRUS & SECURITY Conference
               NYU, DPMA Fin. Ind. Ch.
               609 West 114th Street
               New York, New York 10025

  The submission should be received by December 16, 1991.

  Please include a small photo and introductory biography not exceeding 50
words.  Successful submitters or co-authors are expected to present in person.
Presenters receive the Proceedings.

PAPER FORMAT:
  Typed double spaced, with last name/page# below bottom line (may be
handwritten), brief (to 200 words) abstract following four centered heading
lines: TITLE (Caps); Name; Position Affiliation; Telephone,
City/State/Zip/Country, Electronic mail address (optional).

NOTIFICATION:
  Written (and where practicable) telephoned conformation will be initiated by
Monday, January 27, 1992, to facilitate low cost travel.  Those needing earlier
confirmation should submit papers sooner and attach a note to this effect.  You
may be asked to perform specific revisions to be accepted.  Nobody can
guarantee you a place without an acceptable paper.

CONFERENCE:  There are five tracks.  Don't hesitate to submit a
presentation given elsewhere to a more specialized audience.  Most of
our attendees will find it new, interesting, and necessary.

SPONSOR: DPMA Financial Industries Chapter in cooperation with
         ACM-SICSAC & IEEE-CS & ICCP

Please report problems with the web pages to the maintainer

x
Top