The RISKS Digest
Volume 14 Issue 47

Wednesday, 7th April 1993

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…


Another Mystery for the San Francisco Muni Metro
Columbia and Discovery shuttle problems
Jim DePorter
Ken Hollis via Paul Robichaux
``Organized Crime Gets into Phone Fraud''
An interesting bug for users of "at"
Dave Parnas
RISKS of Complacency (DOS 6.0)
A. Padgett Peterson
Using your company's E-mail for private purposes
Omer Zak
Re: Personal letters
Paul Robinson
Re: Hayes Sequence Triggered
Ron Dippold
Groupware (non)security query
Rob Slade
Legal Net Monthly Newsletter
Paul Ferguson
Injured Using a Computer Pointing Device?: Read This
Pete W. Johnson
Mohamed Kaaniche
Info on RISKS (comp.risks)

Another Mystery for the San Francisco Muni Metro

"Peter G. Neumann" <>
Wed, 6 Apr 93 08:46:58 PDT
Just after 1 p.m. on Sunday afternoon, April 6, a San Francisco Municipal
Railway car (1228) was headed for the car barns when it crashed into the rear
of another car (1304) that had stalled in the Twin Peaks Tunnel.  15 people
wound up in the hospital.  It took all night to clear the wreckage, and full
service began again only on Monday morning.  The causes of the stall and of
the crash were still unknown.

The signal system and the safety controls are as follows:

 * An `automatic' speed-control system has three speeds, 10, 27, and 50 mph.
   [Apparently ZERO is not considered a speed.]

 * A cab-signalling system informs the operator of the maximum permissible
   speed, red for 10, yellow for 27, green for 50.

The controls were thought to be `foolproof', because the car automatically
slows or stops if the operator exceeds the maximum indicated speed.  There are
also impedance bonds in the tracks that are supposed to determine whether the
track ahead is clear.

The operator of car 1228 is named Johnny Wong.  Three possible scenarios were

 1. Wong or someone else had disconnected the cab-signalling system,
    which would bypass the speed controls.  [This is allegedly not easy
    to do, and has various voice protocols associated with it.]

 2. There might have been a failure of the track-signal system, which
    would have made car 1304 invisible to the control systems.

 3. Human failure was also mentioned, although in the absence of the
    first two scenarios, that does not seem to make much sense.

[Source: An article by Carl Nolte in the San Francisco Chronicle, 6 Apr 1993,
pA1, following up on the previous day's reportage.]

Well, the next day's report begins with this paragraph:  The crash

  ``... was the result  of the operator deliberately disabling the
  safety system so that he could speed up his train, sources close to the
  investigation said''.

The investigation continues.  Stay tuned for any further revelations.

[Source: article by Phillip Matier and Andrew Ross, SanFranChron, 7 Apr 1993,
p. A1]

       [By the way, the "Another" in the subject line is because I was
       reminded of the Ghost trains that plagued the Muni Metro repeatedly
       beginning about ten years ago.  PGN]

Columbia and Discovery shuttle problems

"Peter G. Neumann" <>
Wed, 7 Apr 93 08:57:49 PDT
On 22 March, Columbia's main engines were shut down three seconds before
lift-off, because of a leaky valve.

On 5 April, Discovery's launch (STS-56) was aborted eleven seconds before
lift-off.  Early indications pointed to a valve in the main propulsion system.
In this case, the engines had not yet been ignited.  (There had been an
earlier one-hour delay at nine minutes before launch, due to high winds and a
temperature sensor problem.)

[Source: San Francisco Chronicle, 6 Apr 1993, p.A2]

A computer glitch is now being blamed for the 5 April delay.  Computer data
had indicated that the valve had not closed.  ``However, engineers believe
that the valve closed properly and a bad circuit might be to blame.``  That
is, the computer was in error in reporting the valve status.

[Source: AP item in the San Francisco Chronicle, 7 Apr 1993, p.A3]

Shuttle launch aborted by computer error...

Jim DePorter <>
Wed, 7 Apr 1993 01:38:34 GMT
  The real reason for sending this is that the reporter said "since it is a
bug in the computer software it will be easy to fix and the shuttle will be
able to launch in the next 24 hours". Seems the expectations of fixing
something as 'simple' as software are set way to high. I understand the idea
behind the statement: If the problem was in the valve the shuttle could be
delayed for more then 24 hours, while all you need to do to fix software is
fix the code and reload the 'application' (possibly by floppy disk (-8 ).

The risk has to do with people having a little knowledge. Not to long ago
software was a big and nebulous idea to most reporters.  Now everyone has
certain ideas about how software actually works, which in most cases is
actually wrong (heck I know people who still have trouble understanding the
difference between ram space and disk space).

STS-56 abort

Paul Robichaux, NTI Mission SW Dev Div <>
Wed, 7 Apr 93 08:43:58 CDT
<< this was originally posted on by Ken Hollis of
the Kennedy Space Center <>  [...]

STS-56 abort at T-20 seconds (or thereabouts, maybe 16 seconds per my GLS DD?)
was called today because of the GLS (Ground Launch Sequencer).  It detected
that the MPS (Main Propulsion System) High Point Bleed valve (PV22)  closed
indicator did not come on as expected.

PV22 is a monostable, normally closed, helium pneumatically actuated valve on a
line attached to the LH2 17" manifold.  This 17" manifold is the line that goes
between the ET (External Tank) and the main engines to supply LH2 to the
engines.  The high point bleed line is situated in the Orbiter at the "high
Point" of that manifold.  The LH2 manifold between the ET and the Orbiter looks
like an inverted "U".  One end of this manifold goes down to the bottom of the
LH2 section of the ET (as opposed to the LO2 section at the top of the tank),
the other end goes down towards the engines.  Since LH2 is very cold, just
about any temperature rise will tend to let it gas off.  The high point bleed
allows any gasses / bi-phase liquid that may accumulate at the top of this U to
be siphoned off overboard, where it is sent to the flare stack & burned.  It
only takes a couple of seconds for this valve to be closed before a gas pocket
forms in this section of line, so the valve must be open as close to lighting
the engines as possible so that the engines don't ingest a hydrogen bubble.
Believe it or not, this still simplifies the operation of the LH2 system with
the engines & loading the tank.  The lines in the aft for the MPS / SSME system
are commonly referred to as "a plumbers nightmare".

During the "terminal count" at about T-20 seconds, the open command is removed.
 Since this is a "monostable" valve, if there is no helium supply or no power
to the solenoid that lets helium to the valve, the valve will close.  GLS then
verified at about 16 seconds (per my last DD) it is closed and everything is
fine.  Today the Open indicator went from ON to OFF (indicating it cycled) but
the Closed indicator never went from OFF to ON (indicating it did indeed close)
thus causing the abort.  A downstream temperature transducer went from cold to
very warm also indicating that the valve closed, but GLS does not check that
temp ducer.  A 48 hour scrub-turnaround has been called contingent on relying
on the temp ducer rather than the Close indicator.  Last I saw the indicator
was not still working.  It would be easy to say the it is a microswitch failure
on the valve, but it could be quite a few things wrong (as always on the
Orbiter) and further troubleshooting will have to be performed in the aft to
figure out exactly what the problem is.

Any problems after T-31 seconds is an abort for the day.  No more holds are


``Organized Crime Gets into Phone Fraud''

"Peter G. Neumann" <>
Wed, 7 Apr 93 8:59:44 PDT
A new survey by John Haugh's Telecommunications Advisors, Inc., claims that
technically sophisticated organized-crime rings are annually defrauding U.S.
businesses and telephone companies of $4 billion in long-distance calls.  70.3
percent of the almost 700 companies surveyed reported they had been hit by
toll fraud at least once in the past five years, with an average loss of
$125,000 [inferentially, I conclude, per company rather than per hit].  Haugh
predicted that 35,000 companies will be victimized this year.  [That
multiplies out to $4.375 billion for the year if the past average holds true.]
[Source: An article by John Eckhouse, San Francisco Chronicle, 7 Apr 1993, p.

An interesting bug for users of "at"

Dave Parnas <parnas@triose.eng.McMaster.CA>
03 Apr 1993 19:13:18 -0500 (EST)
If you look in the manual for "at" you will see that one of the
recommended ways of using it is to have each at job schedule a new
one a day or a week or a month later.  Some find this easier than
editing the /cron file or they may not have authority to do that.

I regularly use this trick to schedule a daily backup of my files onto a tape
that I always leave in my tape unit.  Last year in April it stopped working.
I thought perhaps there had been some kind of outage or bug and simply
restarted it.

This year I noticed that when it ran (early this morning) and try to schedule
tomorrow morning's backup, at gave the message "too late".  I thought it might
have been some problem caused by a series of power outages we had yesterday
but then I noticed it was also happening on two other machines.

I did some experimenting and found that at would not schedule any jobs from
0200 to 0259.  A few hours later I understood.

Tomorrow morning there is no 0202 (the time that schedule my backup)
because of the switch to EDT.  We will go directly from 0159 to 0300.

I read the manual and there is no indication in the manual that any
such check is made.  It says you can use any time between 0000 and 2359.
This is clearly a case of incomplete documentation.

Is it a case of the author of at being too clever, or me being too stupid?

I think it a nice example of how subtle can be the error that leads to a
failure.  It never occurred to me that they would be checking for that missing
hour.  They probably never thought of someone having a regularly scheduled
call for 0202.

However, there is something even nicer.  If it skips the run in the spring,
shouldn't it run it twice in the Fall?  I checked my records and it doesn't do
that.  Even though the clock is going to drop back it schedules the run for
the next day.  Now, is that a bug?  If so whose?

A question of documentation!


RISKS of Complacency (DOS 6.0)

A. Padgett Peterson <>
Thu, 1 Apr 93 21:09:21 -0500
Yesterday I went down to the local Babbages for a copy of DOS 6.0 with
expectation of a similar experience as when 5.0 was purchased. Well the
box was the same size but that was about it. (What do you expect for
US50.00 anyway).

It seems that MS-DOS now comes much like an automobile or cable television:
the base price doesn't include the options.

Inside the two-inch-thick box was a slim volume (321 pages vs 668 pages
in the DOS 5.0 manual) mostly on the new "features" (as in "that's not
a bug, its a feature" 8*) and three high density disks (and a coupon for
low density - one of many coupons).

Well, I can say this much, its not really for monochrome laptops, its not
really for XTs, the commands are not consistent, and it has its share of bugs,
but seems ok otherwise.

Towards the end of the book you find a set of coupons: the first asks you
to send in US24.95 + US5.00 for shipping + tax. This gets you the "Microsoft
MS-DOS 6.0 Resource Kit" which includes the "MS-DOS 6.0 Technical Reference",
and a set of "supplemental disks" which include things like COMP, EDLIN,
EXE2BIN, and LCD.CPI which were left out of 6.0 (everyone in Redmond must
like to wait on EDIT and has an active matrix laptop in their Porche).

If you are using STACKER, for US5.00 you can get a conversion utility for
DBLSPACE & possibly repeat my experience (on my venerable but 100% compatible
XT clone, WD controller, & ST-225, attempting to use DBLSPACE resulted in a
"Divide Overflow" half-way through the conversion & left the machine
unbootable even from floppy - had to reboot with a lesser DOS version and
clean off all of the DBLSPACE files to recover - happened more than once so no

Speaking of DBLSPACE, when formatting a 360k floppy with /S, you now get three
hidden files and have only 180k free: seems DOS 6.0 grew a bit and now puts
50+k of hidden DBLSPACE.BIN on the floppies too.

There is an anti-virus tool from Central Point but by now every virus-writer
in the world knows how to turn it off with a high function of Int 10, 16,
or 21h (haven't tried it but was told by a reputable source). Even so there
is yet another coupon at the end of the book requesting another US19.90 for
two updates, one "now" (they knew it was obsolete already ?) and one in
3-4 months. Actually cheap compared to the (pounds)29.90 they expect from
UK residents (includes VAT).

What really got me is the lack of a simple environmental variable to turn
of the color in the utilities for a monochrome display. I told SETUP to
use monochrome but this ended when SETUP (which also informed me that
an "incompatible disk compression" was present - nope) was done. For EDIT,
/B is the switch and /NOHI helps. DEFRAG wants /BW, MSAV allows /BW but
/MONO works better (you can go out for lunch while the memory scan runs
on an XT).

Now there are alternatives to cubic money. You can download the supplemental
file (DOS6SUPP.EXE) from the MS BBS in Washington (206.936.6735), all 480+k
of it & the BBS does support 9600 baud but do not confuse it with v42,
v42bis, or MNP. 33 bad blocks (a record) during the download but my
trusty Supra, 16550 chips, and Procomm+/Zmodem (plugs) handled it ok.

The Anti-Virus update can be downloaded from 503.531.8100 - not on the
coupon but on page 277 - probably Central Point.

In short, the product has the feel of "not ready for prime time" but it
did appear in the first quarter '93 (last day actually - well Egghead
had it the day before).

A final note: I did try to call Microsoft tech support about things
encountered (90 days "free" support is available starting with the first
call). I got through to the lady who took serial numbers (and started the 90
day timer) quickly enough only to be informed after that I was 86th in line &
could expect a 90+ minute wait. Not an 800 call. From Florida to Washington.
No thank you. (At least they told me 8*).

Using your company's E-mail for private purposes

Omer Zak <>
Wed, 07 Apr 93 01:40:22 +0300
At present, companies have the right to require their employees to use
company computers, including E-mail access, only for company business.
Employees who participate in the Internet discussion groups may violate
this restriction.  Then they incur the risk of harassment if they ever
fall out of favor and/or hold unconventional political beliefs.

The remedy?
Next time you accept a job, negotiate (along with your salary and fringe
benefits) the right to use your company's E-mail also for private purposes,
subject to reasonable limits (which are based ONLY upon quantity of mail
send and received) and the understanding that the time you spend on
private E-mail is your time, not company time.

Companies have the right to control the use of computers which belong to
them.  On the other hand, they are required to compensate you for your
work in their behalf (in the form of salary etc.).  So considering E-mail
access to be another fringe benefit will solve the problem.
                                                         --- Omer

Re: Personal letters

Paul Robinson <>
Wed, 7 Apr 1993 03:03:09 -0400 (EDT)
On < Mon, 29 Mar 1993 13:24:37 (PST) > In Comp Privacy 2-11,
Steven Hodas <>

> If I send a personal letter to someone do they have the right to
> disclose it to others without my consent?

No.  The Copyright act of 1978 and later amendments gave statutory
protection at the federal level for the first time to unpublished works.

> Does this vary state by state?

No.  Prior to the 1978 law, an unpublished work was subject to the
protection of the common law of the state in question.  The new law
expressly excludes states from having any jurisdiction over unpublished
works and voids any "common law copyright" which might have existed.
All works are automatically protected under federal law.

> If it's prohibited, is it a civil or a criminal issue?


> If it is permitted doesn't that suggest that we have greater privacy
> protection for electronic communciation because the ECPA would prohibit
> that kind of disclosure?

I think you are confusing things.  The ECPA gives to Electronic mail the
same protections which are available for telephone conversations - the
protection against interception by third parties or the use of intercepted
E-Mail by law enforcement personnel without a warrant, i.e. what the laws
against wiretapping and recording of telephone calls, the ECPA provides to
the same extent to E-Mail.

The ECPA does not apply to the sender or  recipient of the message.  It only
applies to anyone who may see a message prior to its delivery to the
designated mailbox or delivery point.  It applies to the E-Mail providers
who carry the message and to anyone who delivers it.

I am also posting this to the Risks Digest for a reason which has to do
with another issue which almost no one has noticed.  As of April 1, 1988,
the United States became a member of the Berne Union for the Protection of
Literary Works.  This treaty is most famous as the reason companies would
simultaneously publish a book in Canada in order to obtain protection
under the Berne Convention.

As of four years ago, that process was no longer necessary because the
U.S. is now a member of the Berne Union.  The most significant issue under
Berne (I refer to this as "It Berne's me up") is that there are no
formalities or requirements of notification in order for a work to
obtain copyright protection.

What this means is that copyright notices became totally optional after
April 1, 1988 for all works first published on or after that date.  In
theory, if you obtained a computer program from someone which simply had
his name and address on it, and wanted to use it, you would have to find
out if the person who wrote it wanted anything to license it.   You can be
sued, and lose, and the other party can collect damages, even though the
work has no indication of copyright notice.

I live just outside of Washington, DC and the Copyright office is just a
20 minute train ride away.   A frightening fact is that despite the treaty
having been around for more than four years, the Copyright office still
does not have copies of the text of the treaty.  They have copies of the
Phonolog Convention (for protection of sound recordings) and they have
copies of the Universal Copyright Convention (which instituted the C in
a circle copyright notice.)  But Berne is conspicuously absent.  It makes
me wonder what things are stated in this treaty that are so bad that
nobody wants people to know what it says.  (The last time I tried to get
a copy was about a year ago, but that still was 3 years after
implementation and the Copyright Office STILL did not have copies of the
text of the treaty.  It makes me wonder why.

Just remember this little piece of information.  A treaty, once ratified
by the Senate, has the force and effect of an amendment to the
Constitution of the United States and can override its provisions.  Think
about that some time.


Re: Hayes Sequence Triggered (Peterson, RISKS-14.46)

Ron "Asbestos" Dippold <>
Tue, 6 Apr 1993 20:43:37 GMT writes:
>ps Turning off the "in band" sequence & using DTR I can understand, but
>   128 (80h) is just as likely as "+" (2Bh) in a binary file unless the
>   Motorola firmware interprets it as "none".

In general, most modems treat anything above 127 as ignore.  Having
been bitten by the triple plus sequence even with the Hayes guard time
(back when I used rn, for instance, and was '+'ing through
articles...) I learned to turn this off very early.

Groupware (non)security query

"Rob Slade, DECrypt Editor, 604-984-4067" <>
6 Apr 93 18:41 -0600
I am looking for experiences, anecdotes and comments relating to security,
or the lack thereof, in "groupware" applications and systems.  This material
will become part of an article to be published later this spring.  Any replies
that I wish to quote I will contact the author first.

For those replying from the newsgroups, I would appreciate copies to and for backup.

Vancouver Institute for Research into User Security   Canada V7K 2G6

Legal Net Monthly Newsletter

Paul Ferguson <>
Wed, 31 Mar 93 16:31:09 EST
Opinion, editorial and news worthy submissions are currently being
(sought and) accepted for a new start-up electronic news journal.
This monthly compilation will be called 'The Legal Net Monthly
Newsletter' and will focus on the legal and ethical aspects of
computer networking. Legal Net Monthly will be a non-biased, open
forum electronic newsletter keeping in step with the networking
environment of the '90's and will be availble by E-Mail subscription.

Legal Net Monthly is aiming to release it's first issue on May 1st,
1993. Articles on the following topics are especially welcome:

        o   Defining "Criminal Mischief" on the Nets
        o   Authoring/Distributing Computer Viruses: Legal Implications
        o   Legislative news around the world

Send all submissions, subscription requests and correspondence to:

Paul Ferguson, Network Integration Consultant, Centreville, Virginia USA!fergp     1:109/229 (FidoNet)

*** Injured Using a Computer Pointing Device?: Read This ***

Pete W. Johnson <>
5 Apr 1993 06:45:52 GMT
This is a pointer to a basenote and discussion pertaining to computer
pointing device injuries (mouse, trackballs, puck, stylus, etc.) in  For convenence I have included a copy of the
basenote below.  To follow net etiquette, please direct all responses to
the basenote below in notesgroup ONLY.

                      (Copy of Basenote)

This note (which is being posted monthly) is for anyone that has been injured
using a computer pointing device (mouse, trackball, puck, tablet, etc.).  I
have been assisting computer operators who have been injured using pointing
devices for the past 4 years.  I am now presently doing research at the
University of California's (San Francisco and Berkeley's) Ergonomics Lab on
the design of computer pointing devices with the goal of reducing injuries
associated with their use.  In order to do this, I need to collect information
on pointing device design characteristics (button design, button force, device
size, device shape, etc.) that are important in minimizing and/or reducing the
physical stresses operators are subjected to.  Some of this information will
be collected through my laboratory research, but a major and important source
of information has to come from operators like yourself.  I need to collect
all the information I can from computer operators that have been injured as a
result of pointing device use.

In order to do this, I need your help.  If you have been injured using a
pointing device, I would appreciate it if you would send me a note with
information pertaining to your injury.  I would like the information e-mailed
directly to me (  The format I would like the
information sent to me is as follows, fill in as much as you can:

 1) NAME: (optional)
 2) COMPANY: (optional)
 3) PHONE #: (optional)
    WERE MADE (This is probably the most beneficial information)

My intent is to enter this information into a database in order to gather
information and look for trends.  Each month I will share relevant information
by posting a monthly summary in similar to what has been
done with keyboard information.  If you are presently experiencing problems,
feel free to call me (510/231-9405) and I will share with you what I know.  I
am also open for suggestions, please post responses to this basenote or e-mail
me if you have any further suggestions or input.

If your company has internal bulletin boards, please post this note or provide
a pointer telling your co-workers about this basenote in the newsgroup.  I will be also be posting a pointer to this
basenote in comp.risks, comp.human-factors, and as well.

Finally, if you have any opinions or inputs on a particular pointing device or
pointing device design in general, send me a note or call me.  Our lab is
assisting some of the major pointing device manufacturers with the design of
their pointing devices. If you have some inputs for a particular company, I
will be happy to direct them to the appropriate person.

Thanks for your help.
Peter W. Johnson
                          (End of Basenote)


Wed, 31 Mar 93 19:53:31 +0200
FTCS-23:The 23rd Annual International Symposium on Fault-Tolerant Computing
Diagora, Centre de Congres de Labege, Toulouse, France, June, 22-24, 1993

 To receive a hardcopy of FTCS-23 Advance program [or a complete version of
  the on-line announcement, which was much too large for RISKS], please contact
  Mohamed Kaaniche: LAAS-CNRS,7 avenue Colonel Roche, 31077 Toulouse, France
  Tel: +(33) 61 33 64 05, Fax: +(33) 61 33 64 11

     [The full announcement is also in the CRVAX.SRI.COM RISKS archives
     CD RISKS: with the file name RISKS-14.FTC .  PGN]

FTCS is the world's most important forum for the presentation and discussion
of state of the art developments in dependable computing systems. This year's
program features 60 regular papers, 5 practical experience reports, 6 software
demonstrations and one panel. This program is the result of a very stringent
selection process carried out by the international Program Committee on more
than 300 submissions. The regular paper sessions cover a breadth of topics
from concurrent error detection to software-implemented and application-based
fault-tolerance, from theoretical issues in modeling to field measurement of
fault- tolerant system dependability, from testing to fault injection. The
opening plenary session will be devoted to practical experience reports on two
safety-critical, software intensive systems currently in operation: the
digital fly-by-wire systems of the Airbus family of airliners, and the speed
control system of the Paris subway. The panel will discuss the limits in
dependability, and the software demonstrations will encompass tools for
hardware and software dependability evaluation.

Exhibitors from both industrial and academic communities will present
commercially available products, advanced prototypes and tools relating to the
conference theme. An exhitors' forum will offer technical presentations
relating to the exhibited products, prototypes and tools.

The symposium participants will be given the opportunity to attend a
pre-symposium review of the research conducted at LAAS-CNRS, as well as
joining post-symposium technical visits of Aerospatiale, CNES and Matra
Marconi Space.

On Monday June 21, a welcome reception will be organized at Hotel Capoul.  On
Tuesday June 22, the Mayor of Toulouse will give a reception in the famous
"Salle des Illustres", followed by a concert at the Jacobins Cloister.  On
Wednesday June 23, the traditional excursion will be to Albi, home town of the
famous painter Toulouse-Lautrec, followed by a banquet.

Please report problems with the web pages to the maintainer