RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (09/16/88)
RISKS-LIST: RISKS-FORUM Digest Thursday 15 September 1988 Volume 7 : Issue 53
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Hurricane Gilbert (Richard A. Schafer via Matthew P Wiener)
Phobos I details (Dave Fiske, Jack Goldberg)
Computers and Elections (Lance J. Hoffman)
The First "Virus" on Japanese PC (Yoshio Oyanagi)
Another one-key mishap (Larry Nathanson)
Re: "Single keystroke" (Warren R. Carithers, Paul Dubuc)
More computer follies -- how not to design a console (Seth Gordon)
GNU Emacs & Security (A.Gaynor via Eliot Lear and Geoff Goodfellow)
Complex phones (Dave Fetrow)
ISDN/ANI - What one switch vendor told me (Allen L. Chesley)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) /
get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ...
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95).
----------------------------------------------------------------------
Date: Thu, 15 Sep 88 03:32:05 pdt
From: weemba@garnet.Berkeley.EDU (Matthew P Wiener)
Subject: Hurricane Gilbert
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" <SCHAFER%RICE.bitnet@jade.berkeley.edu>
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.
Richard
------------------------------
Date: Tue, 13 Sep 88 13:56:06 edt
From: davef@brspyr1.brs.com (Dave Fiske)
Subject: Phobos I details
Organization: BRS Information Technologies
from The Schenectady Gazette, Sept. 10, 1988.
SOVIET MISTAKE LED TO 'SUICIDE' FOR MARS PROBE
"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
saved.
* * *
"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."
------------------------------
Date: Thu, 15 Sep 88 09:47:24 -0700
From: Jack Goldberg <goldberg@csl.sri.com>
Subject: Phobos I details
Key phrases in the Phobos report:
1. ...by 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.
Jack
------------------------------
Date: Thu, 15 Sep 1988 14:51 EDT
From: Lance J. Hoffman <LANCE@GWUVM.BITNET>
Subject: Computers and Elections
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.
Lance
------------------------------
Date: Wed, 14 Sep 88 13:35:04+0900
From: Yoshio Oyanagi <oyanagi@is.tsukuba.junet>
Subject: The First "Virus" on Japanese PC
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.
------------------------------
Date: 15 Sep 88 20:47:52 GMT
From: lan%bucsb@purdue.edu (Larry Nathanson) [or lan@bucsb.UUCP]
Reply-To: lan@bucsf.bu.edu (Larry Nathanson, Boston Univ Comp. Sci.)
Subject: Another one-key mishap
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
system!
-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.]
------------------------------
Date: Thu, 15 Sep 88 08:47:07 EDT
From: wrc%vienna@CS.RIT.EDU
Subject: Re: "Single keystroke"
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@cs.rit.edu wrc%rit@csnet-relay
------------------------------
Date: 15 Sep 88 12:48:10 GMT
From: pmd@cbnews.ATT.COM (Paul Dubuc)
Subject: Re: "Single keystroke" (RISKS-7.52, Matthew P Wiener))
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
------------------------------
Date: Thu, 15 Sep 88 13:10:50 EDT
From: Seth Gordon <sethg@ATHENA.MIT.EDU>
Subject: More computer follies -- how not to design a console
<To test out new user interfaces, Xerox would videotape novice users
<working with the system.
A friend of mine worked at a computer company where they would take a
novice user, hand them the computer in its box, and videotape them as
they tried to open it, set it up, and start using it.
One poor soul had no problems until he had to put the disk in the disk
drive. He took out the disk, examined the computer, and with great
confidence put it into a "speed line" that was engraved in the case for
decoration.
: Seth Gordon / MIT Brnch., PO Box 53, Cambridge, MA 02139
: bloom-beacon!athena.mit.edu!sethg / standard disclaimer
------------------------------
Date: Thu, 15 Sep 88 08:32:45 PDT
From: the terminal of Geoff Goodfellow <Geoff@KL.sri.com>
Subject: GNU Emacs & Security (A.Gaynor via Eliot Lear)
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: [gaynor@aramis.rutgers.edu (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: gaynor@aramis.rutgers.edu (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
.emacs:
;; 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] gaynor@rutgers.edu
------------------------------
Date: Thu, 15 Sep 88 17:05:14 PDT
From: fetrow@bones.biostat.washington.edu (Dave Fetrow)
Subject: complex phones
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-
------------------------------
Date: Thu, 15 Sep 88 10:43:17 edt
From: achesley@hqafsc-lons.ARPA (achesley@sc) <Allen L. Chesley>
Subject: ISDN/ANI - What one switch vendor told me
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
all.
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
Nations.
------------------------------
End of RISKS-FORUM Digest 7.53
************************
-------