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 13 Issue 57

Wednesday 10 June 1992

Contents

o Perot computers cracked
Larry Hunter
o $150 printer hangs $0.5M VAXcluster
Marc Shannon
o Reviewing Communications in the Gulf War
James Paul
o Endeavor bug -- more details
Nancy Leveson
o Where on earth are you?
Richard Murnane
o Risk of Computer Generated Fund-Raising Letters
Lee Hasiuk
o Car computer downloading
Bob Sidebotham
o Telecom Australia allows easy denial of service attack
anonymous
o Follow-up to Dead Driver story -- PennDOT replies
Mike Berman
o Re: BBS Fraud
Fred Gilham
o Info on RISKS (comp.risks)

Perot computers cracked

Larry Hunter <hunter@work.nlm.nih.gov>
10 Jun 92 11:32:10
Richmond, June 9 (AP) -- An intruder erased information on about 17,000
supporters of Ross Perot from a computer file at the undeclared Presidential
Candidate's Virgina headquarters, campaign officials said.  They added,
however, that they have copies of the files destroyed in the weekend incident.

The data included the names, addresses, telephone numbers and notes on about
17,000 Perot supporters in Virginia.  "It's not a political act as far as I'm
concerned," said Mark Adams, the state petition coordinator for Virginians for
Perot.  "I don't feel threatened by anything of that nature."  [From the NY
Times, 10Jun 1992, p. A20]

  I understand that the spokesperson for the campaign would want to downplay
  the importance of the incident, and say that he didn't feel threatened, but
  it is hard to avoid the conclusion that this is a politically motivated dirty
  trick.  The Virginia election petition filing deadline is less than 3 weeks
  away.

  With a hotly contested and unusually complicated Presidential election upon
  us, I would hope that electoral computer risks will be receiving heightened
  attention from the community of computer professionals.

Lawrence Hunter, PhD., National Library of Medicine, Bldg. 38A, MS-54,
Bethesda. MD 20894    (301) 496-9300   hunter@nlm.nih.gov (internet)


$150 printer hangs $0.5M VAXcluster

Marc Shannon <R602MS5U@VB.CC.CMU.EDU>
Tue, 9 Jun 92 14:36:21
Most people tend to enjoy their days off, Memorial Day included.
Unfortunately, I received a call from our Operations staff at 4:30 in the
morning on Memorial Day.

It seems that during their normal nightly backups, one of the systems seemed to
have a problem.  During processing of one of the disks, nothing happened -- the
tape drive wasn't spinning and any attempt to exit out of the command (using
^Y) was ignored except for a useless "*INTERRUPT*" message on the console.

In frustration, they accidentally hit ^P which halted the system and then
attempted to reboot.  The system just would not come back up.

Something I should note about this system is that it (probably incorrectly) has
the key "votes" for the VAXcluster to continue operating normally.  Since it
was down, all the other systems were waiting for it to come back up ("quorum
lost, blocking activity").

After spending an hour fruitlessly searching for the problem, it turned out
that the disk that the system had tried to backup had gone south.  This disk
was (incorrectly) single-ported to a single HSC (Hierarchical Storage
Controller).  The HSC's action to disk problems it to spit out the errors onto
its console.  The console had a locally attached printer which had run out of
paper.

So, since there was no paper in the printer, the console hung waiting for it.
Since the console was hung, the HSC waited for it.  Since the HSC was hung, the
VAX couldn't come up.  Since the VAX couldn't come up, the VAXcluster wedged.

This is how a $150 printer could hang a half-a-million dollar VAXcluster.

Sigh..    --Marc


Reviewing Communications in the Gulf War

James Paul <jpaul@nsf.gov>
Tue, 09 Jun 92 14:01:44 EDT
The following are excerpts from the article "The Data Weapon"
[Peter Grier, in _Government Executive_, June 1992, p. 21],
discussing U.S. communications support during the Iraqi conflict:

"...Throughout the Gulf theater of operations, satellite communications uplinks
seemed as common as the crushed water bottles that littered allies' camps....
The ubiquitous dishes were visible evidence of the vast command,
communications, control and intelligence (C3I) network the United States
laid....
    Getting it all working wasn't always easy.  The communications network
often needed workarounds and quick fixes to patch together equipment of
different technical generations, with different software interfaces and
protocols.
    One big glitch occurred early on.  In September 1990, it became apparent
that the new Defense Switched Network was experiencing a horrible
call-completion rate back to the United States, with only 20 to 30 percent of
attempts going through.  It took a troubleshooting effort of almost three
months, involving AT&T and GTE technicians as well as military communicators,
before the trouble was found: a signaling incompatibility between tactical and
fixed systems.  Over a three-day weekend, Bell Labs finally produced a new
software patch to connect the systems, raising the call-completion rate to
about 90 percent.
    Another problem arose because the Army's new Mobile Subscriber Equipment
communications switches had not yet been tested for operability with the older
switches of the other services.  The Joint Tactical Command, Control and
Communications Agency back in the States had to whip up software fixes enabling
the Army's switches to work the Marine/Air Force Unit Level Circuit Switch, as
well as the French RITA communication system.  This took 17 days, according to
a DISA [Defense Information Systems Agency] report.
    Meanwhile, the demand for connectivity was so great that DoD communicators
were involved in an almost continuous search for all possible means of carrying
messages [earlier in the report Grier mentioned that the daily message load was
700,000 telephone calls and 152,000 messages].  Among other things, the amount
of electronic data being sent back and forth for tactical reasons was larger
than anyone had ever envisioned....  Every time a new [satellite] came on line,
it was used up."

_Government Executive_ is published by the same folks who put out the political
magazine _National Journal_, and it's aimed at the inside-the-Beltway
managerial crowd.  One wonders what might have occurred had the Iraqis pursued
a more rigorous electronic warfare strategy.  "Interoperability" is still the
big problem -- the Navy's inability to read the Air Force's computer-generated
Air Tasking Order [the daily air war plan] is becoming almost as famous as the
82nd Airborne trooper who used his AT&T Calling Card to call Fort Bragg from
Grenada, asking them to call the Navy because he couldn't get through on the
radio to ask the ships offshore for fire support (I'm going to be _really_
disappointed if that story turns out to be apocryphal).  It also seems Patriot
batteries could receive data from the Airborne Warning and Control System
(AWACS) only with difficulty due to incompatible data links.

Typing errors are the fault of the contributor, not the magazine.


Endeavor bug -- more details

Nancy Leveson <nancy@murphy.ICS.UCI.EDU>
Tue, 09 Jun 92 22:53:24 -0700
>From Aviation Week as quoted by James Paul:

     Engineers have traced the problem to the sensitivity of NASA-developed
     equations to a particular set of numeric values that arose when Endeavour
     was making one of the final computer-targeted rendezvous maneuvers.  Test
     show the software had been properly coded by IBM and therefore passed all
     preflight tests, according to Ted Keller, senior technical staff member
     at the IBM Shuttle Project Coordination Office, Houston.

Here is some additional information about this event.  You can evaluate it
yourselves with respect to the statements in AW.

The STS-49 failure of the flight software to converge during targeting has been
traced to the Lambert targeting routine.  The associated algorithms used by the
routine converge on an independent variable called "U" which is a double
precision scalar.  U is iterated (up to 10 times) via this algorithm.  The
algorithm is designed to converge on a value of U between two dynamically
updated limits called U_MIN and U_MAX, which are single precision scalars.  On
each iteration, either U_MIN or U_MAX is updated to decrease the interval
within which the algorithm will search for the desired value of U.

To determine which limit to update, the algorithm calculates a variable U_STEP,
the amount by which U will be updated on this iteration.  If its value is
positive, U_MIN is set to U.  If its value is negative, U_MAX is set to U.
Then U_STEP is added to U, and the resulting value of U is compared to the
limits U_MIN and U_MAX.  If U is now outside the limits, U is recalculated as
the average of U_MIN and U_MAX, thereby keeping U within the search interval.

                   U
          |--------|-----------------------|
         U_MIN                           U_MAX

U continues to be updated in this manner on each iteration until convergence is
attained or maximum iterations are executed.  Convergence occurs if the
normalized transfer time that corresponds to the current value of U is close
enough to the desired transfer time.  "Close enough" is a function of a
mission-specific data value.

For the third rendezvous of STS-49, the value of U after the first iteration
was very close to the desired value, and U_MIN was set equal to U because
U_STEP was positive.  On the second iteration cycle, U_STEP was smaller thana
one least significant bit (LSB) for U_MIN.  Since U_STEP was positive, U_MIN
was set to U, and U_STEP was added to U.  Algebraically, U should have been
greater than U_MIN.  However, due to precision differences, U_MIN was greater
than U.  (Loss of precision occurred when the double precision value of U was
stored into the single precision variable U_MIN.) Therefore, U was recalculated
to be the average of U_MIN and U_MAX, and the search interval no longer
contained the desired value of U.

         |<---1 single precision LSB-->|
         |                             |
         |                             |
         |     U          U            |
         |   after      after          |
         |    1st        2nd           |
         |    pass      pass*          |
         |------|---------|------------|
                |         |            |
                |<------->|            |
                  U_STEP               |
                                      U_MIN
        *Prior to recalculations      after
                                     2nd pass

     Note:  both U and U-MIN had negative values

On subsequent iterations, U was updated in the direction of the desired value,
but never reached it before maximum iterations occurred because it was outside
the search interval.

To fix the problem and allow the mission to resume, they had to uplink a new
state vector from the ground, by-passing the onboard routine.  The permanent
fix involves changing U_MIN and U_MAX to double precision.


Where on earth are you?

Richard Murnane <richardm@runx.oz.au>
Tue, 9 Jun 92 15:07:38 AEST
On Monday 8th June, I was tuning my amateur radio set across the 20-metre band,
when I came across an emergency traffic net on 14.245 MHz.  Several radio
amateurs, in Hawaii, California, Florida, and Mexico City, were assisting an
American marine vessel in the Carribean, the "Sea Harvest", whose navigation
systems had been disabled, apparently by a lightning strike.

Miami Coast Guard was alerted and the Coast Guard cutter "Courageous" was
dispatched from Jamaica to locate and assist the vessel.

One problem that arose was getting accurate coordinates for the vessel: all
they had to go on was the last known LORAN readout from the previous day, and
the direction and speed she had been sailing.  Later, Sea Harvest contacted
another ship on the marine distress frequency, VHF channel 16. Because Sea
Harvest had a hand-held VHF tranceiver, the other ship would have been fairly
close, and that ship's position reading would have been a reasonable
approximation.

However, when it came to relaying that information to the Coast Guard, things
became confused: the position was read out as "22 degrees, 34 minutes north,
*08 42 92* West" (I don't recall all the digits correctly, but the longitude
was read out as three pairs of digits).

The "08 42 92" was interpreted by all on frequency as being
degrees/minutes/seconds, as most of us have been brought up to read
geographical positions. The "08" was immediately rejected as a mistake,
possibly in translation from Spanish to English, as 8 degrees west is in the
Western Sahara desert, and it was judges that it was in fact *80* degrees West,
which is in the Carribean. The ship which provided the coordinates however
insisted that "08" was correct.

Several hours later, when authorisation was given to activate Sea Harvests's
EPIRB (Emergency Positioning Information Radio Beacon), the longitude figure
again came up as "084.."; it was only then that everyone realised that the
first THREE digits represented degrees, and the remaining three the minutes in
decimal format, eg 84 degrees 34.6 minutes.

The misinterpretation of the data format, when relayed over a voice radio link,
led to a lot of confusion: one of the degree/minute/seconds coordinate groups
placing the Sea Harvest five miles inland! This confusion lasted several hours
until the EPIRB was activated.

I'm very suprised that the Coast Guard could have been caught out by this: It
suggests that the "decimal minutes" representation is non-intuitive, or at
least counter to the way most "non-mariner" people (e.g. the radio amateurs
providing voice relays) have been educated to read geographical coordinates.
(Or, perhaps, there are two different readout systems currently in use?)

Of course, when passing messages through one or more relay operators, one must
be very careful not to try to "interpret" the message being passed, rather to
send it *exactly* as received.

It also illustrates that even the most sophisticated, systems can fail, and
that it's always best to have a safety backup.  Presumably, Sea Harvest's HF
radio antenna was on a different mast, and thus not destroyed by the lightning
strike!
                                   73 de Richard VK2SKY


Risk of Computer Generated Fund-Raising Letters

Lee Hasiuk <0003582947@mcimail.com>
Tue, 9 Jun 92 17:49 GMT
>From a recently received Caltech Office of Annual Giving letter:

    ... Last year you gave $0.00 to the Annual Fund.  I would like to see you
    increase your contribution this year by 25% or more if possible. ...

I can imagine the letter I'll get after I send them $100:

    ... Thank you for being so generous by increasing your contribution from
    last year by Divide by 0
    Core dumped

Lee Hasiuk, lee_hasiuk@mcimail.com


Car computer downloading

<Bob_Sidebotham@transarc.com>
Tue, 9 Jun 1992 15:41:30 -0400 (EDT)
I have a new '92 Saturn SL with a computer controlled ignition system.  I've
been having some minor problems with cold start--sometimes after starting the
car, the car seems to "hunt" for a good fast idle speed. It slow's the engine
down until the RPM's reach zero and the car is about to stall, then suddenly
boosts the engine speed to about 2000 RPM. Then it repeats.

The Saturn service manager mentioned that there is a software change due out at
the end of the month. Saturn HQ will download this change to each dealership
(by satellite link, I believe), and then each car will receive the software the
next time it checks in for servicing. This is likely related to my problem.

There's all sorts of potential risks here, and no doubt many of them have been
raised in this forum before. The important point is that the car I drive in to
the service center is not the same car that I drive out! Prototypes of the car
may have been driven for N million miles at proving grounds, but it didn't have
the same software. How extensively has the software been tested? What are the
security measures, if any, to ensure that the software I get is the software
distributed by the factory? Do I have the option of not accepting the new
software? I wonder if it's crossed anyone's mind that only downloading to
selected cars would be a way of performing economical field tests on large
numbers of cars (at some risk to those owners)? Even if this isn't explicitly
intended, it works out that way since not all the cars are downloaded
simultaneously--not yet, anyway.

As a sidenote, when you check in for Saturn service, your car's history is also
uploaded to Saturn HQ. Every engine stall, my salesman told me, is recorded, as
is the entire service history for each vehicle.

Bob Sidebotham, Transarc Corporation


Telecom Australia allows easy denial of service attack

<[anonymous]>
Wed, 10 Jun 92 12:22:14 xxT
I was dismayed to find out today that Telecom Australia (which holds
a virtual monopoly on telecommunications in this country) will
disconnect a line given only two pieces of information:
    * telephone number
    * subscribers name

Anyone listed in the phone book, therefore, is an easy target for "prank"
denial of service.

More seriously, however, are some of the technology related considerations.
The building in which I work has a number of outside lines on a rotary.  The
alarm system when triggered, however, notifies a security firm on a fixed line.
A high-tech criminal could simply have that line disconnected and we would
never know (since the other lines on the exchange would still work).

There are two morals to the story. Firstly, the old problem of bureaucracies
not validating requests is still alive and well. Secondly, the shortcoming of
yet another automated system (our alarm) is highlighted when examining the
TOTAL environment.

How many mission critical telecommunications users verify the internal
checks and policies of their service provider?


Follow-up to Dead Driver story -- PennDOT replies

Mike Berman <berman@gboro.glassboro.edu>
Wed, 10 Jun 92 09:30:30 -0400
The following appeared on the letters page, Philadelphia Inquirer, Wednesday,
June 10, 1992:

The rest of the story

Your story relating Eugene F. Smith's troubles with the Pennsylvania Department
of Transportation (June 2) was not a complete representation of Mr. Smith's
dealings with us.  I'd like to offer your readers the rest of the story.

When we received a police report that Mr. Smith had been killed in a car
accident, we edited his driving record accordingly.  When Mr. Smith learned of
the mistake to his record -- after the police stopped him for a driving
violation -- he wrote to us, and we corrected his record and issued him a photo
identification card since he was not eligible for a driver's license.

State law prevents me from disclosing any violations on an individual's
personal driving record, so I cannot explain to you why a driver may be
suspended or for how long.  I can tell you that an indication on our record
that a driver is deceased would in no way lead to a suspension.  [comment ---
special zombie permit?] I can also tell you that the rest of Mr. Smith's
problems with Penn-DOT are because of his own disregard for state traffic
safety laws.

I have asked the Pennsylvania State Police to investigate Mr. Smith's case so
that it can be settled correctly as the law provides.  Within those legal
parameters, we will work carefully with Mr. Smith to ensure that he understands
his responsibilities to drive legally in Pennsylvania.

        Howard Yerusalim, Secretary of Transportation, Harrisburg


Re: BBS Fraud (Lawson, RISKS-13.56)

Fred Gilham <gilham@csl.sri.com>
Tue, 9 Jun 92 11:36:12 -0700
Another moral:

        [...]
        6) `For Sale' notices for PC's etc. at low prices are posted
           from the stolen accounts.
        7) Victims replying to the postings are requested to transfer
           money into the bogus bank account.
        8) The money is withdrawn and the victims are out of luck.
        [...]

Morals of this story:

        A) Use different passwords for different accounts.
        B) Log on regularly to check for irregularities.
        C) When buying things advertised by computer, use COD.

-Fred Gilham   gilham@csl.sri.com

Please report problems with the web pages to the maintainer

Top