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 53

Thursday 15 September 1988


o Hurricane Gilbert
Richard A. Schafer via Matthew P Wiener
o Phobos I details
Dave Fiske
Jack Goldberg
o Computers and Elections
Lance J. Hoffman
o The First "Virus" on Japanese PC
Yoshio Oyanagi
o Another one-key mishap
Larry Nathanson
o Re: "Single keystroke"
Warren R. Carithers
Paul Dubuc
o More computer follies -- how not to design a console
Seth Gordon
o GNU Emacs & Security
A.Gaynor via Eliot Lear and Geoff Goodfellow
o Complex phones
Dave Fetrow
o ISDN/ANI - What one switch vendor told me
Allen L. Chesley
o Info on RISKS (comp.risks)

Hurricane Gilbert

Matthew P Wiener <weemba@garnet.Berkeley.EDU>
Thu, 15 Sep 88 03:32:05 pdt
The following appeared in ucb.general:

 From: netinfo@GARNET.BERKELEY.EDU (Postmaster & BITINFO)

 Hurricane Gilbert may cause various national and international
 network links to fail or to be closed down.  The follow message
 pertains to BITNET links in the mid-US. Links to Mexico and South
 America may also be affected.

 Date:         Wed, 14 Sep 88 13:15:17 CDT
 From: "Richard A. Schafer" <>

 Hurricane Gilbert is approaching the Texas coast.  If it appears to
 be heading into the Houston area, or close enough to it to cause serious
 problems, Rice will close down for an indeterminate time period, until
 the danger of the storm is past.  If the hurricane does in fact come
 through the Houston area, storm damage may cause power outages; the
 last hurricane in 1983 caused power outages of various lengths from
 a few minutes to several days.  We will try to keep you informed.

 The storm should hit the coastline Friday or Saturday.


Phobos I details

Dave Fiske <>
Tue, 13 Sep 88 13:56:06 edt
from The Schenectady Gazette, Sept. 10, 1988.


"Houston (UPI) - One of two ambitious Soviet probes hurtling toward
Mars was mistakenly ordered to 'commit suicide' when ground control
beamed up a long series of radio commands that included a single
incorrect letter, a top Soviet space official says.

"The Houston Chronicle reported yesterday in a copyright dispatch from
Moscow that Roald [sic] Sagdeev of the Soviet Institute of Space Research in
Moscow said it would be 'a miracle' if the Phobos 1 probe could be

*   *    *
"Sagdeev told the Chronicle the trouble began when control of the
Phobos 1 spacecraft was transferred from a command center in the Crimea
to a new facility near Moscow.

"'The controllers did not estimate how difficult it would be to work in
a new environment [near Moscow]', he said.

"Sagdeev said the flight controllers had to prepare a long message to
the computer of 20 to 30 pages, and in that message, a controller left
out one letter.

"'The [changes] would not have been required if the controller had been
working the computer in Crimea', he said.  When the flight controller
sent the incorrect message to the computer, 'by an unbelievable small
chance' there was a failure in the computer that allowed the error to
go undetected.

"In the end, he said, the absence of one letter from the computer
programming and the absence of a computer backup program, resulted in
the transmission of 'a comment [sic] to commit suicide' to Phobos 1."

Phobos I details

Jack Goldberg <>
Thu, 15 Sep 88 09:47:24 -0700
Key phrases in the Phobos report:  

1. an unbelievably small chance, there was a failure in the
computer that allowed the error to go undetected.

2. ..and the absence of a computer backup program..

In (1), the issue seems to be error detection, such as is given by a check on
character type (probably not the case because of reference to a missing
character) or a longitudinal check on a character string or substring (parity,
sum, count, etc.)  Such checks may be performed in hardware or in software.  In
(2) the problem is characterized as the absence of a backup program, which is
not, strictly speaking, an error detection mechanism, but rather a remedy that
may invoked by detection of an error (an alternate remedy is to notify an
operator).  Error detection is arcane computer stuff, while "backup program" is
almost daily english.  My guess is that the problem was indeed a failure in
error detection, and that the reporter mischaracterized it as a failure in
backup.  In either case, it seems that the failure was caused by a combination
of human and computer system failures.

By the way, failure in error detection (and recovery, too), is a major type of
system error (e.g., reports by Siewiorek, CMU, and Iyer, U. Ill.)  The standard
explanation is that since errors are rare events, error detection mechanisms
are less frequently exercised and hence are more poorly debugged than the rest
of the system.

Computers and Elections

Thu, 15 Sep 1988 14:51 EDT
RISKS readers in the DC area may be interested in knowing that CPSR/DC chapter
is sponsoring a panel discussion on "Accuracy in Computer-Tabulated Elections"
Tues Oct 4, 7:15-9:30 pm at Room B120, Academic Center, 22 and I St. NW, George
Washington Univ., Washington, DC (Foggy Bottom metro).  Participants are Roy
Saltman, NBS; me; Carol Garner, Director of the Election Center (a nonprofit
organization for election officials; the closest thing they have to the ACM,
and moving slowly in that direction); and Eva Waskell, an activist whose name
stirs fear into the hearts of election officials across the country.  If you're
in town, stop in; it should be a good show.

The First "Virus" on Japanese PC

Yoshio Oyanagi <oyanagi@is.tsukuba.junet>
Wed, 14 Sep 88 13:35:04+0900
     PC-VAN, the biggest Japanese personal computer network operated by NEC,
was found to be contaminated by a kind of virus, several newspapers reported
today (September 14).  This is, as far as I know, the first virus reported on a
Japanese PC.  The viruses so far reported in Japan were all on American PC or
WS.  PC-VAN is a telephone based network between NEC PC9800 personal computers,
the best sold PC (> one million) in Japan.

     This virus does not destroy programs or data unlike those in US, but it
automatically posts the user's password on the BBS in crypto- graphic form.
The offender will later read the BBS and obtain the password.

     Several members of PC-VAN claim that they are charged for the access to
PC-VAN which they do not know.  This virus seems not to be contagious by its
own power.  The PC9800's OS was contaminated when the user carelessly run a
anonymously distributed program on the PC.

Another one-key mishap

Larry Nathanson <>
15 Sep 88 20:47:52 GMT
On the 'one key bringing the house down' front:  On the machine here,
(and I suppose, on many multi-user machines under UNIX) if a user wishes
to kill the first job, waiting in his/her job queue, s/he types:

kill -9 %1 

I've heard that upon occaision the system operator will type: 

kill -9 1

Since the operator can kill ANY job, it works.  Job number 1 is a critical
process that maintains the multi-user status of the machine.  Once the above 
command is entered, the operator is the only user on the machine.  (Though
he may not realize it for a while!)

I'd hate to think what the analogue to this would be in the star wars

-Larry Nathanson

    [(By the way) RISKS is performing a very important service: It is written
    by, and read by those who really should be informed by it- the computer
    professionals of today and tomorrow.  If they (we) do not appreciate and
    understand the risks of computers, then noone will.]

Re: "Single keystroke"

Thu, 15 Sep 88 08:47:07 EDT
Matthew P Wiener writes:
>On Unix, even experienced users can do a lot of damage with "rm"...

A similar situation occurred here a few months ago.  A student went to his
instructor for help in removing a file named "-f" from his account.  The
instructor first attempted "rm -f", which didn't complain but also didn't
remove the file.  After a few similar attempts, the instructor fell back on
the tried-and-true method of "rm -i *".  Some time passed during which no
messages appeared on the terminal; as the instructor began to grow uneasy,
the next shell prompt appeared.  An "ls" showed one file in the directory,
named "-f".  At this point, the student (who had been watching the proceedings
over the instructor's shoulder) commented, "If you weren't my teacher, I'd
think you just deleted all my files."

Fortunately, the student hadn't done any work on the files that day, so all
were recovered from the daily backup tapes.  The problem in this situation
was the interpretation by "rm" of the first file name, "-f", as an argument.
The result was that the "-i" option actually given by the instructor was
overridden by the name of the first file to be removed.

The blame for this event could be put in several different places:
UN*X command syntax (unlike VMS) doesn't sufficiently distinguish between
runtime options and other arguments (e.g., filenames); the UN*X filesystem
allows filenames which may look like valid options to commands; the "rm"
command doesn't recognize potential incompatibilities between its options
(i.e., "rm" shouldn't accept both the "-i" ("ask me before you delete
anything") and "-f" ("don't complain, just remove these files") options in
the same command line).  It is hard to fault the instructor for not knowing
that "rm" would override "-i" in this case, when (in his mind) he wasn't even
specifying "-f".

  Warren R. Carithers, Rochester Institute of Technology, Rochester NY 14623
  rochester!ritcv!wrc   wrc%rit@csnet-relay

Re: "Single keystroke" (RISKS-7.52, Matthew P Wiener))

Paul Dubuc <pmd@cbnews.ATT.COM>
15 Sep 88 12:48:10 GMT
Does C Shell have a way to display the command before executing it?  In the
Korn Shell you can type [ESC]/<pattern> to display the last command in your
history that matches <pattern> ([ESC]/r in Matt's example).  If it's the
command you want, you just need to hit [RETURN] to execute it.  If not, you can
type another `/` to keep serching or just edit the command and execute it.  I
have gotten into the habit of not using the blind repeat feature in the shell
unless I'm certain that what will be executed is what I want.

Paul Dubuc, AT&T Bell Laboratories, Columbus

More computer follies -- how not to design a console

Seth Gordon <sethg@ATHENA.MIT.EDU>
Thu, 15 Sep 88 13:10:50 EDT
<To test out new user interfaces, Xerox would videotape novice users

GNU Emacs & Security (A.Gaynor via Eliot Lear)

the terminal of Geoff Goodfellow <>
Thu, 15 Sep 88 08:32:45 PDT
Return-Path: <lear@NET.BIO.NET>
Date: Wed, 14 Sep 1988 11:48:10 PDT
From: Eliot Lear <lear@NET.BIO.NET>
To: hackers_guild@ucbvax.Berkeley.EDU
Usmail: 700 East El Camino Real, Mtn View, California 94040 
Phone: (415) 962-7323 
Subject: [ (Silver) : GNU Emacs & Security ] 

[The following was discovered by one of the Rutgers systems programmers.  It
is similar to the old "vi:" bug in that visiting a file may cause execution
of an arbitrary set of commands including shell escapes...  I am told that
this has not been brought up on hg before.-eliot]

From: (Silver)
Subject: GNU Emacs & Security

This message is being sent to everyone in group slide.  I've wandered across an
application of a feature of GNU Emacs that may allow sliders to fall victim to
trojan horses arbitrarily stuck in files.  The feature in question is the `file
variables' section of a file.  Upon reading the file, portions of text may be
evaluated, with perhaps profound results.  For example, using this feature I
was able to create a file that copied /bin/sh to my home directory, and chmod
it to run setuid root.  It wasn't hard at all.  With a little effort, I'm sure
I could have made its effects totally transparant.

So, protect yourself by inserting the following at the root level of your

  ;; Protect thine arse from the Trojan file-variables section.
  (setq inhibit-local-variables t)

The pertinent portion of this variable's documentation reads, "Non-nil means
query before obeying a file's local-variables list.".  So, from now on, it's
going to ask you if you want to process the variables if they are present.
Only answer `y' if you trust this file not to put you through a blender.  If
you answer `n', you can always look at the variables somewhere within the last
3000 characters of the end of the file, and, if they appear reasonable, say
`M-x normal-mode' to process them.

Regards, [Ag]

complex phones

Dave Fetrow <>
Thu, 15 Sep 88 17:05:14 PDT
 In RISKS-7.52, Mike Linnig lists a thought-out critera for dealing with ANI
(ability to identify a callers' phone number). That's fine but it was (by
necessity) lengthy.

 It is getting bothersome that a phone (which was and should be 
simple to use) is getting a bit complex. An awful lot of functions
are being built into a box with audio-only feedback and 12 keys!
(a trend is to let conventional touch-tone phones do more rather
than adding specialized phones with labelled buttons)

 Any one (or 2 or 3) extra functions seem easy to absorb but it's looking
like we'll be faced with dozens. Worse still: the options are different from
phone to phone.

 The risk is the classic "one more feature" risk but applied to a device
we all use, many times a day.
                                          -dave fetrow-

ISDN/ANI - What one switch vendor told me

achesley@hqafsc-lons.ARPA (achesley@sc) <Allen L. Chesley>
Thu, 15 Sep 88 10:43:17 edt
     Yesterday I happened to attend a full-day seminar given by one of the
major switch manufacturers.  As I had been reading about the ANI question in
RISKS, I took the occasion to ask some questions.  Although many of the answers
depend on how the local telephone company (telco) implements it, this is what
they told me about ISDN (when it eventually arrives. 

1.  Whether or not a calling phone number is available to the receiver is an
option implemented at the switch.  Except for calls to emergency services,
un-listed phone numbers will, in general, not be forwarded.

2.  As part of the features available, the local telco may offer a "blocking"
command (pre-fix/post-fix/command button) depending on demand and/or the FCC
requirements.  This and many other possible features would probably be at added
cost, but the telcos have not yet figured out how they are going to tariff them

3.  There is an entirely new value-added industry possible under ISDN - remote
directory services.  A call ariving at Company A could have the information in
the "D" channel (which carries the calling phone number) routed to Company B,
which could then provide a "customer profile" back to Company A before they
answer the phone.

     Don't start making plans on cutting out your mother-in law's calls just
yet (or of autoforwarding them to the local massage parlor).  The ISDN folks
did not take extension phones into account when they designed the standards,
and until they do you are not likely to see full ISDN capability in your homes.
In your businesses yes, in your homes no.

     Another point we had questions about, and they could not answer, is what
happens to all of those companies (like banks) who now do some business using
the touch-tone key pad.  Under ISDN, signalling uses the "D" channel, not one
of the voice carrying "B" channels.  Therefore you cannot listen and capture
touch-tones off of the conversation. 
                                                Allen L. Chesley

     NOTE:  This message does not express the offical or unofficial
     opinions of the United States Air Force, the Department of Defense,
     the United States Government, nor probably most of the United

Please report problems with the web pages to the maintainer