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 4 Issue 12

Sunday, 16 November 1986


o Air Traffic Control radar problems
o Stuck Microphone and Near-Collision of 727s
o Gwinnett County Voting
Scott Dorsey
o Micros in cars
Paul Kalapathy
o DMV computer networks
Bob Campbell
o Serious security bug in 3.4
Dave Martindale
o "Maj. Doug Hardie" and his story
Bruce Schuck
o Necessity of language skills
Daniel G. Rabe
o Call for Papers — Safety and Reliability Society Symposium
Nancy Leveson
o Info on RISKS (comp.risks)

Air Traffic Control radar problems

Peter G. Neumann <Neumann@CSL.SRI.COM>
Sun 16 Nov 86 20:33:49-PST
(Adapted from AP, 12 Nov 86) Radar controlling high-altitude air traffic
from the Texas Panhandle to southern California was knocked out for 40
minutes by a power failure at the Albuquerque NM ATC.  In addition a radar
station near Phoenix, Arizona, was down for more than 59 hours due to a
power failure.  Both power failures occurred on 6 Nov 1986.  The Albuquerque
failure was the first there in 18 years, according to the FAA sector
manager.  The backup procedures are very awkward, but they worked well to
avoid any accidents.

Stuck Microphone and Near-Collision of 727s

Peter G. Neumann <Neumann@CSL.SRI.COM>
Sun 16 Nov 86 20:40:24-PST
A stuck cockpit microphone jammed a controller-pilot frequency last week and
prevented an air traffic controller from warning two Boeing 727 jetliners
that they were on a collision course.  The Braniff and United planes carried
175 people, and passed perpendicularly within something like 500 feet of one
another.  (The Sunday NY Times News of the Week in Review, 16 Nov 86, noted
that there were 777 near collisions in 1985, about 30 percent of which
involved scheduled airliners.)

Gwinnett County Voting

Scott Dorsey <kludge%gitpyr%gatech.csnet@RELAY.CS.NET>
Thu, 13 Nov 86 18:36:13 est
   A recount of votes in Gwinnett county, Ga. has led to a few interesting
problems that might be of interest to readers of Risks.  Ballots from one
area were accidentally not counted in the first tally, because they had been
mislaid in a stockroom (and possibly tampered with).  There was apparently
no safeguard to prevent anyone from recognizing that a large population was
not represented.  Later, it was discovered that the tabulating machines used
for the counting gave different results between runs.  Although there is
some question about the reliability of the count, it seems to be accepted as

   Stan Kelly-Bootle speaks of "CREVM", the Conditioned Response Electric
Voting Machine, which trains voters to press the correct lever by a series
of electric shocks.

Scott Dorsey, ICS Programming Lab,  Rich 110,
    Georgia Institute of Technology, Box 36681, Atlanta, Georgia 30332

       [In nearby Alabama, the Shelby-Denton election was still unresolved
        according to the last report I saw (in the 12 Nov 86 Washington
        Post).  It seemed that each recount reversed the previous one, with 
        more new votes being discovered each time for the previous apparent
        loser, who became the new apparent winner.  PGN]

Micros in cars

Paul Kalapathy <convex!>
Fri, 14 Nov 86 19:41:12 cst
    Personal anecdote:  A close friend of mine bought a 1984 Firebird.  He
was somewhat dissatisfied with the performance given that it had a
moderately large engine.  He is a software weenie, and had a friend who went
to work for GM doing whatever it is they do with those micros they put in
cars to control the engine.  This friend of his provided him with the
commented source code for the ROMs that are in the micros for that
particular model.  The ROMs were of the variety that is compatible with
2716s or 2732s or one of the other common EPROMS.  So, my friend proceeded
to mangle the micro in his Firebird to include a socket for the EPROM.  He
programmed an EPROM to change the fuel mixture vs. engine speed, etc.  The
car had better performance, and a top speed about 30mph higher than before
his modification (the gas mileage was substantailly worse, as were the
noxious emissions, I suppose).  In a word, it became a race car.

    I don't know what risk this poses to society, but it is rather amusing.

        -Paul Kalapathy
    [There are some interesting warranty and liability questions as to
     what the manufacturer and dealer roles are once you have tinkered. 
     There are also questions about what happens if you market such an
     extension, if it fails and causes loss of life, etc.  PGN]

DMV computer networks

Bob Campbell <hpdsd!campbelr@hplabs.HP.COM>
Sat, 15 Nov 86 01:03:39 pst
My license also fell prey to the magic of computers.  Two miles across
the Ohio border, I was stopped going down a rather large hill and ticketed
for speeding.  Being a college student that would shortly be hundreds of 
miles away, I spent the money for the ticket in my local pub.

I was ticketed on my Illinois license which had the address of my father's
old house.  After graduation, I packed my bags and set out for California.
After living here for six months, I received notice from my insurance agent
that my policy was about to be cancelled.  It seems that they had finally
checked and found that my Illinois license had been cancelled by the state
of Ohio.  

The California DMV didn't care about my past record or that the license was
expired.  They stapled my old license to a form and in a quick (for CA) two
months I had a valid license.  

After paying bozo rates for 6 months with an insurance agent who worked
out of his car, I decided to check around.  Worried about losing coverage
again, I told the whole sad story to the agent.  Bad record, dropped policy
and all.  She called the California DMV to run a check.  Three days later
I was not only insured, but I now get the good driver rate.

I ran through computers that talked too much, that ignored each other and
that had the right information but didn't bother to tell.  Also involved
were the "computers must be right" people who wouldn't let me pay the higher
rates. (Not that they had to work to talk me out of it :-)

If nothing else, I think I figured out why so many bad drivers seem to be
on California highways . . .

Bob Campbell   Hewlett Packard Information Technology Group

Serious security bug in 3.4

Dave Martindale <>
Mon, 10 Nov 86 15:10:17 est
In the 3.4 release, the cp/mv/ln command is setuid root in order to be
able to rename directories.  (Cp, mv, and ln are three links to the
same file).  Unfortunately, it isn't careful enough about where it
makes use of its root privileges.  Making use of this bug, anyone can
become the super-user by typing just a few commands.

I do not intend to describe this method of breaking security here.
However, to avoid becoming victim to it, you should remove setuid from
cp/mv/ln.  Although this means that only root will be able to rename
directories, I can see no other way of protecting yourself from the bug
until SGI fixes the program.

This bug existed in a previous release and I reported the problem to
SGI.  Whoever "fixed" the bug simply masked some of the symptoms
without fixing the problem.  I've reported it once again; let's hope
they fix it correctly this time.

    Dave Martindale, watmath!onfcanim!dave

"Maj. Doug Hardie" and his story

Sat, 15 Nov 86 08:58:40 PST
I certainly hope the Major left that filter in place.

Maybe programs like the one he describes should have the occasional
student who doesn't fit the profile just to see what the result is.

In this case it seems to have worked out.

Necessity of language skills

Sat, 15 Nov 86 14:58 CST
I do hope we're not beating this topic into the ground, but I am
compelled to respond to Col. G. L. Sicherman's response to my
orignal message on the dangers of letting computers do our thinking.

I agree with his point that

> Standard spelling is invaluable for the efficiency of reading print.

Then he says:

> The flip side is that standard spelling is _not_ invaluable for electronic
> communication, because efficiency no longer matters--it's a measure left
> over from the machine age.  Efficient absorption is important only in one-
> way, bulk media like print.  Electronic communication is interactive.

I cannot agree that "efficiency no longer matters".  Electronic communication
puts unprecedented amounts of information at our fingertips.  Now that
we have so much more to read, efficient absorption is even more important.

Even if the interactive nature of electronic communication makes it easier
to ask for clarification or to ask questions, we must still communicate
with some people non-electronically.  Non-computer people often judge
communication skills by one's ability to follow the standard rules of
spelling, grammar, and punctuation.  If we ignore these rules, we will
probably just alienate ourselves from those who follow and respect them.

This introduces another potential risk: that the inability to communicate
effectively with non-computer professionals will adversely affect the
usability of the systems we develop for them.  An even more immediate
risk is a loss of confidence: "He can't even follow the rules of English;
how can I be sure he's a good programmer?"  From our perspective, this
is an obvious _non sequitur_; from another perspective, it might make
a lot of sense.

(To make myself clear, I don't consider "following the rules" to be any
indication of intelligence or ability.  The point is that a lot of people
consider language skills to be a prerequisite for effective communication.)

     [Since Daniel started this one, I thought I'd let him have another shot.
      But I am still rejecting most commentaries on this subject.  PGN]

Call for Papers — Safety and Reliability Society Symposium

Nancy Leveson <nancy@ICSD.UCI.EDU>
14 Nov 86 20:52:37 PST (Fri)
        "Achieving Safety and Reliability with Computer Systems"
            Manchester, United Kingdom, 11-12 November, 1987

Papers relating to the following system aspects of real-time computers
are invited:

       Integrity throughout the lifecycle
       Safety Assessment
       Reliability Assessment
       Reliability Criteria
       Safety Criteria
       Specification for safety and reliability
       Design for safety and reliability
       Architecture for safety and reliability
       Development for safety and reliability
       Operation for safety and reliability

Papers are also invited that report on experience of the implementation
and use of computers in safety and reliability critical applications.

   Synopses giving the title, authors, affiliations, and up to 500 words
should be returned to the organiser by 7 January 1987.  The initial
selection of papers by the International Programme Committee will be
based on the synopses.  Authors will be notified of acceptance at synopsis
stage by 28 February 1987.  Full text papers of not more than 4000 words
required before 15 May 1987.  Papers will then be reviewed, and formal
acceptance notified to authors in July 1987 following satisfactory revision
of the paper by the author.

ORGANISER:  SARSS '87, The Safety and Reliability Society Ltd., Clayton House,
            59 Piccadilly, Manchester M1 2AQ, United Kingdom

N. Leveson, USA; E. de Agostino, Italy; R. Bell, UK; P. Bishop, UK; R.
Bloomfield, UK; S. Bologna, Italy; J. Cullyer, UK; G. Dahll, Norway; W.
Ehrenberger, Germany; R. Genser, Austria; J. Gorski, Poland; G.B. Guy, UK;
E. Johnson, UK; S. Lindskov Hansen, Denmark; S.R. Nunns, UK; I. Pyle, UK;
W.J. Quirk, UK; J.M.A. Rata, France; F. Redmill, UK; C. Roberts, Belgium; B.
Runge, Denmark; L. Sintonen, Finland; I.C. Smith, UK; U. Voges, Germany; T.
Williams, USA; R. Yunker, USA

Please report problems with the web pages to the maintainer