[comp.risks] RISKS DIGEST 5.64

RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (11/25/87)

RISKS-LIST: RISKS-FORUM Digest  Tuesday, 24 November 1987  Volume 5 : Issue 64

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

Contents:   [MOSTLY ODDS AND ENDS]
  More on NASA Hackers (Dave Curry)
  Re: Video signal piracy hits WGN/WTTW (Will Martin)
  Logic Bombs; Centralized Auto Locking (P. T. Withington)
  Re: Mariner 1 (Henry Spencer, Mary Shaw, Andrew Taylor, Martin Ewing)
  Bank Transaction Control (Scott Dorsey)
  Re: Sudden acceleration revisited (Donald A Gworek)
  Re: CB radio and power (Jeffrey R Kell)
  More on Garage Doors (Brint Cooper)
  Train crash in Sweden (Matt Fichtenbaum)
  Re: L.A. Earthquake & Telephone Service (Darin McGrew)

The RISKS Forum is moderated.  Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious.  Diversity is welcome. 
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j.
Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

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

Date: Tue, 24 Nov 87 10:36:28 EST
From: davy@intrepid.ecn.purdue.edu (Dave Curry)
To: risks@kl.sri.com
Subject: More on NASA Hackers

Some of this information has already been covered in RISKS and elsewhere,
but this article does a fairly good job of summing up both the original
problem and DEC's response to it.  (Dave)

Quoted without permission from "Digital Review", Novemeber 23, 1987, page 80.

  NASA Hackers: There's More to the Story
  Vin McLellan

    More details have come to light regarding the attack this summer on NASA's
  Space Physics Analysis Network (SPAN) by the young German hackers known in
  the European press as the "Chaos Computer Club".
    SPAN is a large, VAX-based network for scientists in the United States and
  other countries who wish to exchange unclassified information on post-flight
  space studies.  According to NASA officials, SPAN links about 800 computers
  in government, industry and academe.
    The SPAN network suddenly became well known after the Chaos hackers held
  a press conference in Hamburg, West Germany, earlier this fall to decry the
  lax VMS security that had allowed them to penetrate 20 different SPAN
  systems in Europe and the United States.
    NASA officials said the Chaos hackers had a considerably inflated idea of
  the value and confidentiality of the information stored on the SPAN systems.
  Although academic researchers may have labeled their files with eye-catching
  titles such as SDI_STUDIES, explained a NASA spokesman, there was no
  classified data stored on SPAN.
    The hackers were, however, able to exploit a flaw in the VMS access
  control system.  The problem was a bug in a VMS system software module
  called SECURESHR.EXE.  DEC first learned of it last year, in late December,
  according to Andy Goldstein, a senior engineer in DEC's VMS group.  The bug
  was subtle but serious, he said.  It allowed a sophisticated hacker to gain
  privileges from a normally unprivileged account.  DEC, said Goldstein, had a
  "fix" available by early February, "a little slower than usual because of
  the holidays."
    The Chaos hackers were able to exploit the delay between the early
  reports of the problem and the later distribution and implementation of
  DEC's corrective patch.  Although DEC's U.S. and European support centers
  had the patch available on request in February, Goldstein said, it wasn't
  until June or July that DEC issued a VMS "special release" to deal with the
  problem.  And even then, there were users who should have received the patch
  but didn't.
    The patch to SECURESHR.EXE "took a long time in coming to Europe,"
  complained Roy Omond, EDP manager at the European Microbiology Lab (EMBL) in
  Heidelberg, Germany.  At EMBL, the delay was costly.  "Before I had the
  chance to install the [SECURESHR] patch," Omond said, the Chaos Club had
  invaded his system.  When he realized what had happened, he broadcast an
  angry warning over SPAN and Arpanet.
    The Chaos hackers patched two VMS images, SHOW.EXE and LOGINOUT.EXE,
  explained Omond.  Those patches modified the system to install both a VMS
  "trap door," which let hackers access the system at any time using their own
  magic password, and a "password grabber" to collect and record the passwords
  of legitimate users.
    "Given that these were modifications to the trusted VMS software,"
  Goldstein noted ruefully, "there was nothing that you could do to defend
  against them."
    The LOGINOUT patch was "lethal," Omond said.  "Not only would it allow
  entry to any user name with the magic password, but it would also store
  valid passwords of all users logging in since the patch was installed."  The
  passwords were stored in the 12 bytes reserved for customer use in each User
  Authorization File (UAF) record.  The hackers have a small program that
  retrieves the user name/password pairs from the UAF, he said, neatly
  printing them out with an asterisk next to the name of each user with
  privileges.
    The Chaos code also corrupted the VMS accounting system, Omond said.
  Even when hackers were logged in, they would not appear on a job count or be
  listed with a SHOW USERS command.
    "They have cost us a lot of real money by using our X.25 connection to
  log in to several places all around the globe," Omond said.  "I have done my
  best to notify... the VAX sites that were accessed from our hacked system.
  I pray that no other damage has been done, and that I am not sitting on a
  time bomb."
    Omond hid neither his fear nor his anger.  He published the names of
  three people whom he accused of circulating the Chaos code - at least two of
  them were apparently employees at SPAN sites - in the hope, he said, that
  "someone somewhere will (a) be saved some hassle from them, and (b) might
  perform physical violence on them."

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

Date:     Tue, 24 Nov 87 14:55:14 CST
From: Will Martin -- AMXAL-RI <wmartin@ALMSA-1.ARPA>
To: rsk@S.CC.PURDUE.EDU
Cc: risks@csl.sri.com
Subject:  Re:  Video signal piracy hits WGN/WTTW

For what its worth, the explanation of this incident that I saw on the evening
newscasts cited the method as being an overriding of the studio-transmitter
microwave link by a higher-effective-power transmitter. They illustrated this
with a drawing showing a vehicle with a microwave dish on it pulled up close
to the building atop which the transmitters are located, and that dish aimed
at the microwave receiving antennae mounted on that building. That could be
expected to put higher effective power into that receiver, and some form of
"capture effect" would allow this interfering signal to override the normal
legitimate input signal coming from the studio.

Of course, there are problems with this -- how would it have affected the
satellite-relay of WGN, for example, unless that is taken from an off-the-air
signal at the uplink site (which seems an unlikely arrangement)? Same about
the microwave land-relays for the PBS station; one would have thought both
of those would travel from the studios to various other sites directly.
(Perhaps, though, the high-building transmitter site is also a point of
origination for microwave relays to other places, and the pirate
overriding the input fed his signals into both the broadcast transmitter
and the outgoing microwave relay chains?)

The other main problem that occured to me is that it would probably be
too obvious and visible to do this. However, now that I think about it, could
it have been done from behind a glass window in another tall building
around that site? That could be just about undetectable if it is possible.
I've been at the transmitter end of such microwave studio-transmitter
links where the dish antenna was inside the room, facing directly at an
ordinary studs-and-plywood wall. That wall was essentially invisible at
those frequencies. (Since this was on top of a mountain, it sure made
maintenance easier, keeping the gear out of the weather!) So if one could
do this from an office or apartment in a nearby high-rise, behind a
curtain and through a closed window or glass wall, the only way to
locate it would be to DF the signal while it was actually transmitting. If
the pirate kept to short unpredictable bursts, this wouldn't be feasible.

I suppose the studio-transmitter link could be encrypted, but it would
still be subject to disruption by this technique. Though this would
prevent a pirate from getting a recognizable signal out over the
transmitter, his override would keep the legitimate signal from getting
through. They would have to go back to landline to avoid that.

Regards, Will Martin

   [Rich Kulawiec (rsk@s.cc.purdue.edu) submitted an article by John
   Camper (and Steve Daley) from the front page of the Chicago Tribune,
   24 Nov 87.  The article adds details to what Rich contributed to
   yesterday's RISKS-5.63, but nothing of real relevance to RISKS.
   Most of you probably saw similar write-ups in your local rags.  PGN]

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

Date: Tue, 24 Nov 87 12:24 EST
From: P. T. Withington <PTW@DIAMOND.S4CC.Symbolics.COM>
Subject: Logic Bombs; Centralized Auto Locking (RISKS-5.63)
To: RISKS FORUM <RISKS@KL.SRI.COM>

Logic bombs et al.: The version I read [of the $70,000 salami attack] was
that, when discovered, the employee threatened to expose that the bank had
previously been funneling the same "roundoff" into its own profits and that
he went unpunished on his promise to keep quiet.  (On the other hand, the
"banks get rich on roundoff" tale is an old computer-fraud chestnut, ranking
right up there with the alligators in the NYC sewers.)

Centralized Auto Locking:  I know a friend whose battery went dead and hence
he couldn't unlock his car to open his hood!  (Of course the tow-truck
operator easily "jimmied" the door lock.)

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

Date: Mon, 23 Nov 87 16:03:01 EST
From: utzoo!henry@uunet.UU.NET
Subject: Re: Mariner 1

Oran W. Nicks, in "Far Travellers" (NASA SP-480) states that Mariner 1
failed because of a combination of two problems. ... And there was a hyphen
missing from the internal guidance software. ... Nicks was Director of Lunar
and Planetary Programs for NASA at the time, and I think we can assume that
he knows what he's talking about.

By the way, Mariner 1 was bound for Venus, not Mars.

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

Date: Tuesday, 24 November 1987 15:31:50 EST
From: Mary.Shaw@sei.cmu.edu
To: risks@csl.sri.com
Cc: Richard.S.D'Ippolito@sei.cmu.edu
Subject: Mariner 1

In SEN 5,2 (April 1980), a letter from the editor on p. 5 said that it was
Mariner 18 that was blown up because of a missing NOT in a program.  I
didn't note any further attribution.

    [You can't always trust those editors.  Besides, I'm not even
    sure there ever was a Mariner 18.  PGN]

In RISKS-3.41 (August 1986), Alan Wexelblat reported that a Mariner probe to
Venus was lost because a period replaced a comma in a FORTRAN DO statement
(that is, something of the form DO 3 I=1,5 became DO3I = 1.5).  Wexelblat
attributed this report to an article in the Annals of the History of
Computing, 1984 (6) 1, page 6; I haven't followed the pointer back.
                                        Mary

   [Andrew Taylor <ATAYLOR@ibm.com> reminds us of the reference (in
   RISKS-4.1) to Software Engineering Notes v8,5 and v11,5.  The earlier
   one refers to the Annals of the History of Computing.  I was 
   hoping someone would turn up an independent source.  PGN]

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

Date: Tue, 24 Nov 87 18:36:50 EST
From: kludge@pyr.gatech.edu (Scott Dorsey)
To: RISKS@kl.sri.com
Subject: Mariner 1 or Apollo 11? (RISKS-5.63)

    I heard that the famous "./," disaster caused the problem with the
onboard IBM 1800 on Apollo 11.  I heard this from a professor who teaches
Fortran, so I'm not so sure about the reliability of the source.  Anyone
else have information on either the Apollo or the Mariner problems?

Scott Dorsey   Kaptain_Kludge
SnailMail: ICS Programming Lab, Georgia Tech, Box 36681, Atlanta, Georgia 30332
Internet:  kludge@pyr.gatech.edu
uucp:	...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gitpyr!kludge

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

Date:     Mon, 23 Nov 87 23:36:23 PST
From: mse%Phobos.Caltech.Edu@DEImos.Caltech.Edu (Martin Ewing)
Subject:  Bank Transaction Control
To: risks%Phobos.Caltech.Edu@DEImos.Caltech.Edu

  "Our money is managed by people who care nothing for the details of
  an single transaction." [sic] (Grubbs, 4.61)

I had a friend who was employed as an old-fashioned bank teller a few
years ago.  From her report, it was an extraordinarily grinding, low-
paying job.  Error control consisted of making her personally
responsible for any cash shortages at the end of the day.  More than
one or two discrepant days and she would be out on the street.

Was this strict supervision to protect the customers, or to prevent
employee pilferage?  You decide. 

There seems to be no control in ATM systems that's quite comparable. Should
programmers, maintenance people or DP execs be forced to make good any system
losses? 

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

Date: 24 Nov 87 13:32:45 GMT
To: comp-risks@RUTGERS.EDU
From: gworek@codas.att.com (Donald A Gworek)
Subject: Re: Sudden acceleration revisited
Organization: AT&T, Altamonte Springs, FL

Word of advice.  If you find yourself in sudden acceleration and the brakes
can't stop the car, try knocking the gearshift into neutral to disable the car.

Gearshifts are usually built with a feature where you can slip into neutral
just by pushing the shifter.

I learned this technique in driver's ed several years ago to avoid getting
into an accident if the gas pedal sticks to the floor.  The engine will
roar, but at least you'll be stationary or in control of the vehicle.

Don Gworek   { gatech, ihnp4, mtune }!codas!gworek

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

Date:         Mon, 23 Nov 87 14:29:52 EDT
From: Jeffrey R Kell <JEFF%UTCVM.BITNET@CUNYVM.CUNY.EDU>
Subject:      Re: CB radio and power
To: RISKS@csl.sri.com

One addendum to the CB interference postings... CB is 11-meter, or more
accurately beginning at the high end of 26Mhz and through 27Mhz.  The big
hazard of illegal use of 10-meter amateur amplifiers on 11-meter signals
is you don't get the RFI reductions from the RF chokes and filters in the
amplifier that are tuned to 10-meter.  To defend the real amateur stations,
they probably aren't generating a 'ludicrous' amount of RFI; but using the
same rig at 11-meters loses the inherent filtering and you get lots of
noise.

You have probably noticed car radio interference quite often on the freeways
when the big trucks with 'alligator' radios pass by (depending on what
station you are tuned to).  The second harmonic of 26-27 Mhz signals rounds
out to 104-108 Mhz, or the upper half of commercial FM radio.

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

Date:     Tue, 24 Nov 87 9:28:11 EST
From: Brint Cooper <abc@BRL.ARPA>
To: risks@csl.sri.com
Subject:  More on Garage Doors

This morning's Baltimore Sun reports that when certain transmitters at Fort
Detrich were turned off, the garage door openers in residential Frederick,
Maryland, began opening again.  It continues that the Army remains
non-commital regarding its responsibility in the matter but notes that
Detrich is a major communications node for domestic and international traffic.

We should not miss the implied risk to computer systems (and, therefore, the
risk to those depending upon computer systems) if such phenomena continue.
Today, your garage door won't open; tomorrow, perhaps your PC won't boot.
                                             _Brint

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

From: genrad!mlf.UUCP@seismo.css.gov (Matt Fichtenbaum)
Subject: Train crash in Sweden [RISKS-5.60]
Date: 24 Nov 87 14:27:55 GMT
Organization: GenRad, Inc., Concord, Mass.

[More on the head-on train crash on 16 Nov 87 in Sweden -- in which nine
were killed and 120 injured.]  Neither train was to stop in the station; one
train, approaching the station at high (traveling) speed, suddenly found
itself shunted over to the opposing track.

According to Swedish shortwave news, construction machinery had
inadvertently cut a cable.  When the cable was repaired two conductors were
interchanged, causing the accident.  The news report didn't clarify whether
the cable error resulted in a switch being in the wrong position or a
signal's incorrectly indicating "ok to proceed."

    [I first read that as "two (train) conductors" were interchanged.  PGN]

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

Date: Tue, 24 Nov 87 11:41:04 PST
From: ibmpa!mcgrew@ucbvax.Berkeley.EDU (Darin McGrew)
To: ibmpa!CSL.SRI!RISKS@csl.sri.com
Subject: Re: L.A. Earthquake & Telephone Service
Organization: IBM ACIS, PALO ALTO

>... I thought "Lots of people calling relatives tied it
>up", which was a factor, but The Institute reports that most of the
>delays resulted because the quake knocked phone receivers off the hook.

It seems to me that a telephone handset resting in the cradle of a heavy
base with rubber feet stands less chance of ending up off the hook after an
earthquake than the new telephones that simply rest on a flat surface.

Could this be a risk of the simple lightweight telephones?
                                                                Darin

                      [Comment on the whole issue: Some of the contributions 
                      have been somewhat picky lately, and quite redundant.
                      Please observe the masthead guidelines.  PGN]
    
------------------------------

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