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…
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
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."
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
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
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.
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.]
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
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
<To test out new user interfaces, Xerox would videotape novice users
GNU Emacs & Security (A.Gaynor via Eliot Lear)
the terminal of Geoff Goodfellow <Geoff@KL.sri.com> Thu, 15 Sep 88 08:32:45 PDTReturn-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
complex phones
Dave Fetrow <fetrow@bones.biostat.washington.edu> Thu, 15 Sep 88 17:05:14 PDTIn 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 edtYesterday 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.Please report problems with the web pages to the maintainer
xTop