From: risks@CSL.SRI.COM (RISKS Forum)
Newsgroups: comp.risks
Subject: RISKS DIGEST 13.77
Date: 2 Sep 92 22:23:41 GMT
Reply-To: risks@csl.sri.com
Distribution: world
Organization: The Internet

RISKS-LIST: RISKS-FORUM Digest  Weds 2 September 1992  Volume 13 : Issue 77

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

  Contents:
Malfunction in a collision-avoidance system (Steve Bellovin)
Software bug on TOPEX spacecraft (sci.space.news via John Rushby)
Software problems on Hubble too (Ron Baalke via John Rushby)
The endless bridge, NJ (George Sicherman)
Washington State felony charges for computer misuse (PGN)
Making a Statement (financial) (Don Grimes)
Feds seek customer records on "Grow-lamps" (Dan Veditz)
Spontaneous appliance operation (Phil Karn)

 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.  Others may be ignored!  Contributions will not be ACKed.  
 The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
 especially .UUCP folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.     

 Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits).  Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
 The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

 For information regarding delivery of RISKS by FAX, phone 310-455-9300
 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com).

 ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
 Relevant contributions may appear in the RISKS section of regular issues
 of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Tue, 01 Sep 92 15:15:11 EDT
From: smb@ulysses.att.com
Subject: Malfunction in a collision-avoidance system

According to the AP, a ``Traffic Alert and Collision Avoidance System'',
designed to prevent mid-air collisions, apparently malfunctioned and nearly
caused one.  Two planes, a 767 and a DC-9, were separated by 1,000 feet of
altitude, in accordance with FAA regulations.  But the TACAS system told the
pilot of the 767 to descend to the DC-9's altitude.  The horizontal separation
of the planes was only .5 miles, rather than the 5 miles required.

			--Steve Bellovin

------------------------------

Date: Sat 29 Aug 92 17:20:45-PDT
From: John Rushby <RUSHBY@csl.sri.com>
Subject: Software bug on TOPEX spacecraft (From sci.space.news)

                         TOPEX/POSEIDON STATUS REPORT
                               August 28, 1992

     The TOPEX spacecraft went into safemode at 18:13Z on August 27.  The
project reports that during a planned maneuver that they received a "roll
momentum wheel saturated" alarm causing the spacecraft to go into safemode and
causing the project to abort the maneuver after 98% completion.  The project
has elected to remain with TDRS support for the time being.  The project has
not declared a spacecraft emergency.  The cause of the safemode is currently
under investigation.

Forwarded from: PUBLIC INFORMATION OFFICE, JET PROPULSION LABORATORY,
CALIFORNIA INSTITUTE OF TECHNOLOGY, NATIONAL AERONAUTICS AND SPACE
ADMINISTRATION, PASADENA, CALIF. 91109. (818) 354-5011

                  TOPEX/POSEIDON STATUS REPORT
                         August 28, 1992

          The TOPEX/Poseidon satellite entered into safe hold
mode on Aug. 27, 1992 at approximately 11:13 a.m. PDT.  This
incident occurred during the inclination maneuver about 6 seconds
from the end of the propulsion burn.

          The inclination maneuver was successful and placed the
satellite in the proper 66 degree inclination toward the Earth.

          Project managers have determined that the safe hold
mode was the result of a "bug" in the software code which set the
failure detection correction limit for a roll angle of 3 degrees,
not 7 degrees as intended.  This was a result of residual LANDSAT
code which did not correlate to the program design language.

          All satellite hardware is functioning properly based on
detailed review of the maneuver playback data.  Reconfiguration
of the satellite back to the standard configuration prior to safe
hold mode is in process at this time and is expected to be
completed tonight.

          The solar array was offset to -55 degrees at 12:45 p.m.
PDT today prior to the start of occultation.  This was done so as
to not overcharge the batteries when the Sun hits the solar array
after coming from eclipse.

          Since the inclination maneuver goals were achieved, the
flight team is proceeding with the nominal maneuver campaign.
There are four more maneuvers to go.  In-Plane Maneuver One is
planned for Wednesday, Sept. 2, 1992.

          The NASA radar altimeter was turned off when the
satellite entered the safe hold mode.  It will be turned back on
about 6:30 p.m. PDT tonight.  Initial data from the NASA
altimeter prior to the incident looked very good.

------------------------------

Date: Tue 1 Sep 92 19:44:23-PDT
From: John Rushby <RUSHBY@csl.sri.com>
Subject: Software problems on Hubble too

                       HUBBLE STATUS REPORT
                         August 31, 1992

HUBBLE SPACE TELESCOPE (HST): HST operations have returned to normal following
the recent safehold entry and recovery. Starting on July 30, a chain of events
caused HST first to enter an inertial hold safemode followed by a hardware
sunpoint safemode.  The first was caused by an incorrect ephemeris table that
was loaded into the spacecraft computer, and the latter by a problem with an
onboard computer software macro. Science observations that were scheduled for
execution during the safemode events are being rescheduled. HST launched April
24, 1990 aboard the Space Shuttle Discovery.

Ron Baalke, Jet Propulsion Lab, M/S 525-3684 Telos, Pasadena, CA 91109 
                             baalke@kelvin.jpl.nasa.gov

------------------------------

Date: Sun, 30 Aug 92 11:32:25 edt
From: gls@windmill.att.com (George Sicherman)
Subject: the endless bridge

From the Asbury Park Press, August 30, 1992:

  A malfunction in the computer that opens and closes the Route 37 bridge
  rendered the span impassable for an hour yesterday afternoon, backing up
  traffic for miles in each direction.

  Dover police Sgt. Vincent Pedalino said officers were forced to reroute
  traffic north to the Mantoloking Bridge on Route 528 while state Department
  of Transportation workers found a way to repair the computer.

  The bridge was closed between 2:30 and 3:30 p.m., stranding many motorists on
  the bridge in the hot afternoon sun.

  Pedalino said the drawbridge structure itself -- which opens upward to allow
  water traffic through in Barnegat Bay -- was unimpaired, but the automobile
  barriers wouldn't reopen.  Normally there are manual controls that override
  the computer system, but they also were not working, he said.

The bridge is a long span from the Toms River area to the barrier resort
of Seaside Heights and the popular Island Beach.  The Mantoloking Bridge
is the nearest other exit from the barrier peninsula, about 10 kilometers
north.

The story does not tell what was wrong with the computer or the manual
controls.  I wonder whether those "manual" controls would work during a power
failure!
                  Col. G. L. Sicherman, gls@windmill.ATT.COM

------------------------------

Date: 21 Aug 1992 15:43:08 -0800
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Washington State felony charges for computer misuse

An article by O. Casey Corr, The Seattle Times Knight-Ridder/Tribune Business
News, 20 Aug 1992, describes the case of Mel Creamer, coordinator of a software
system for mainframe computers used in Olympia, Washington, by the Department
of Social and Health Services.  He was doing a routine check of the system's
performance when the following message showed up:

  "THAT DEVICE DOES NOT EXIST ON STATION DEFINED."

A keystroke-capture watch was set up.  It then was determined that this message
had been triggered by a temporary clerk-typist trying to print something
locally using the access code of another user normally in a different area, and
the system could not interpret the command.  He was trying to print the file of
personal sign-on codes, and had created new accounts and access codes, and had
erased audit trails to remove evidence of the activities.  He clearly had all
the necessary access codes.

The computers contained software for issuing checks and ordering state
services, personnel records for the department's 16,000 employees, arrest
warrants for parking tickets kept for the Department of Licensing, and private
information on individuals and countless companies that did business with the
state.  A computer linked to the one breached by the intruder maintains the
state's budget records.  Malicious misuse of those systems could be quite
damaging.

Timothy M. Lewis was charged by King County for computer trespass in the first
degree, a felony, along with three other people, for misuse dating back to
1987.  The victims, in addition to the state, included Aldus of Seattle,
Asymetrix of Bellevue, and Phonelink Inc. of Bellevue (now Fox Communications).
(This is reportedly something like the 14th such case involving adults since
1988.)

Eugene Raddatz, a data security analyst with DSHS, recalled two previous cases
in the 1980s when state employees got into the computer system and stole money
by having checks written to themselves.  Both people received prison terms, he
said.

------------------------------

Date: Tue, 25 Aug 92 10:04:04 PDT
From: deg@mri.com (Don Grimes via gafter@mri.com)
Subject: Making a Statement (financial)

For more than a decade I've been a customer of a money-market fund that shall
remain nameless here.  For all that time, they've sent me a statement monthly.
Early on, they returned canceled checks with each statement; some years back
they started batching the checks, returning them only twice a year, to save on
postage.

In recent months, they've started sending me a statement every time there's
activity in my account: every time a check clears, or I make a deposit.  In my
case, that means a minimum of three statements per month, at 27 cents postage
each.  So I called up, endured their voicemail system and a five-minute hold,
and asked the customer-service person what's going on.

It seems they've just "enhanced" (her term) their computer system, and one of
its "features" now is that it kicks out a statement every time there's
activity, whether you want one or not.  I pointed out that this is costing ten
times what they're saving by batching canceled checks, but there's nothing to
be done: that's how the computer works, and it can't be changed ...

------------------------------

Date: Fri, 21 Aug 92 11:53:07 PDT
From: daniel@borland.com (Dan Veditz)
Subject: Feds seek customer records on "Grow-lamps"

An AP story in today's paper (21 Aug 1992) date-lined San Francisco states that
Federal prosecutors sought court orders yesterday to force three local
businesses to turn over their customer lists, sales receipts and shipping
records for indoor "Growing lights" since the start of 1990.  They also want
copies of any correspondence mentioning marijuana.

The three companies--Diamond Lights, General Hydroponics, and Berkeley Indoor
Garden Center--refused to turn over the documents without a court order and are
now fighting the court order on the grounds that the request was too broad and
would violate customer privacy.

>From their names I'd guess these businesses sell lots of "grow-lamps"; the
RISK is that with the increasing use of sales-registers that record customer
identification along with each sale how long until the government starts
investigating people who innocently buy a few of these lamps from the local
K-mart, or any other item that might just possibly be used in some sort of
illegal activity?
                                         -Dan Veditz

------------------------------

Date: Fri, 21 Aug 92 23:55:04 -0700
From: karn@servo.Qualcomm.COM (Phil Karn)
Subject: Spontaneous appliance operation

There's a known problem with the BSR X-10 home automation system whereby the
"appliance modules" can spontaneously turn themselves on.  This happens with
certain types of loads, particularly electronic loads such as computers and
compact fluorescent lights, and it is due to a misfeature called "local on".
(The X-10 is a carrier current appliance control system widely marketed under
other names, including Radio Shack, Heath and Stanley. The "appliance modules"
are relay boxes that plug into the wall between the AC line and a load to be
controlled.)

The "local-on" feature is intended to allow a user to turn on an appliance
locally, without having to go to the control box. If the appliance is a lamp,
you just flick its regular switch on and off several times, and the appliance
module turns on.

This feature apparently works by trickling a small amount of current through
the load whenever the appliance module relay is 'off' and watching for sudden
voltage swings across the load that would indicate that the user is cycling the
power switch. It works great for simple resistive loads like incandescent
lamps, but nonlinear electronic loads (especially those that directly rectify
and filter the AC power line) will often draw almost no current until some
voltage is reached across the load's internal filter capacitor. Then the load
conducts, discharging the capacitor and causing the input voltage to drop
suddenly. A few cycles of this "relaxation oscillator" simulates a user
flicking a switch well enough to trigger the appliance module's "local on"
feature.

The problem usually occurs right after you switch the load off -- several
seconds later, it comes back on again. But it's possible that the spurious
turn-on could occur much later. This problem drove me crazy until I realized
from the description of "local on" in the manual what was going on. There was
no specific warning about this possibility. Indeed, the manuals take great
pains to point out that "lamp modules" (which contain dimmers) are not to be
used with flourescent lamps and electronic loads; appliance modules should be
used instead. The instructions do warn about controlling appliances that could
cause damage if they were turned on inadvertently (e.g., an empty coffee pot)
but this doesn't really address the issue.

It turns out that cutting an undocumented jumper inside the appliance module
defeats the "local on" misfeature. It's obvious that someone anticipated this
problem since the jumper wasn't essential in the PC board layout, so it's
doubly annoying that there is no mention of this problem or its solution in the
manual.
                                      Phil

------------------------------

End of RISKS-FORUM Digest 13.77
************************