The RISKS Digest
Volume 16 Issue 38

Friday, 2nd September 1994

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…


Football interference without penalty?
RFI and "winchcraft"
Mich Kabay
Drawbridge controls — fail-safe?
Steve Summit
Chile: "Multicarrier" telephone system collapses
Patricio Poblete
Anarchist files linked to child mutilation
Mich Kabay
Poulson Pal Pinched
Mich Kabay
Barclays Bank's new computer system
Risks of living abroad
Re: Changeable `constants'
George W Dinolt
Joseph H Presley
Mark Brader
Bob Frankston
Steve Kilbane
Lars-Henrik Eriksson
James Cottrell
James Carlson
Mark Nelson
Info on RISKS (comp.risks)

Football interference without penalty?

"Peter G. Neumann" <>
Fri, 2 Sep 94 8:47:48 PDT
National Football League coaches will have radio transmitters this year to
send plays in to their quarterbacks.  RISKS readers may suspect that unless
the communications are encrypted, the opposing coaches will be able to
listen in.  However, a different security problem must also be solved.  The
last time this was tried in the World Football League, quarterbacks
sporadically picked up signals from local radio stations and air traffic
controllers.  You can imagine a situation in which the flight instruction
just happened to coincide with the name of a play.  Well, apparently the
NFL techies believe they have solved the interference problem this time
around; perhaps they resorted to the Playfair Cipher.  [Thanks to Tom
FitzGerald in the San Francisco Chronicle, 2 Sep 1994, p. E6, for reminding
me of this risk.]

RFI and "winchcraft"

"Mich Kabay [NCSA Sys_Op]" <>
02 Sep 94 07:40:26 EDT
The _Globe and Mail_ newspaper in Canada for 94.09.02 (p. A8) reports on
radio-frequency interference with building-construction cranes and other

    Breaking the spell of `winchcraft'
    by Mary Gooderham, Applied Science Reporter

    ....Without warning--and with no obvious electrical or
    mechanical fault--the Kroll K-154 crane would shut itself
    off, sometimes while hoisting a bucket filled with a
    couple of thousand kilograms of concrete.  Two transmissions
    blew, their gears suffering when the machine's emergency
    braking system stopped the bucket in mid-air.  The crane
    sputtered, losing power last week to the point where it
    could lift loads only slowly, only a few metres off the
    top of the building.

The article explains that these problems caused major delays in the
construction site at Simcoe Place in Toronto.  Investigation revealed that the
equipment was being disrupted by radio-frequency interference (RFI), probably
from nearby microwave relay dishes and broadcasting stations.

Workers with experience at the Scotia Plaza site built during the late 1980s
recalled similar problems there; intermittent problems began once cranes were
raised above the 60th story and depended on the orientation of the
cranes--apparently because the cranes acted like antennas.  In that case,
engineers figured out that the RFI was disturbing "the wiring on the cranes'
direct-current motors."

Significantly, the Simcoe Place crane also has a new DC motor, whereas the
other, unaffected crane uses an AC motor.

The engineers installed some metal-coated foam usually applied to ductwork.
The problems stopped.  A lead shield is now being installed for more secure

According to the contractors erecting the outer walls of Simcoe Place, their
laser level "started acting funny when it was used above the 20th floor."

    The receiver that picks up the laser signal beeped when
    the laser was off-target or wasn't even turned on.  Wrapping
    all but its tiny electronic eye with the aluminum foild that
    usually keeps sandwiches fresh in the workers' lunch boxes
    seemed to solve the problem.

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)

Drawbridge controls — fail-safe?

Steve Summit <>
Fri, 2 Sep 1994 08:59:31 -0700
The Evergreen Point Floating Bridge across Lake Washington in Seattle (SR 520)
has been notorious for its control problems — either it gets stuck open or
stuck closed, or opens partially for no reason (which has led to one death and
one serious injury, on two separate occasions).  The draw span has been
rebuilt this summer, although the following account (from the Seattle Times of
September 1) of the new controls will perhaps not be as reassuring to RISKS

  To ensure that the center lift span never again pops up accidentally, the
  old mechanical system has been replaced and is now controlled by a
  computer with a series of safety features that must be overseen by the
  bridge operator.

  "You have to push buttons to make the gates go down, the lights come on
  and the [actuating hydraulic] pumps to start," [project engineer Jay]
  LaVassar said.  "Every step has to be completed before you can go to the
  next step."

Steve Summit

Chile: "Multicarrier" telephone system collapses

Patricio Poblete <>
Fri, 2 Sep 1994 18:15:07 GMT
A telecommunications system that allows callers to choose their own
long-distance telephone company, called the multicarrier, collapsed only 4
days after its inauguration. The system failed because callers were using
codes obsolete with the start-up of the multicarrier, confusing the
system. Talca and Curico, the first cities to have the multicarrier
installed, were the first to experience problems. The entire country will
be hooked up by late October. (La Epoca, p. B6)

Anarchist files linked to child mutilation

"Mich Kabay [NCSA Sys_Op]" <>
02 Sep 94 07:40:34 EDT
The Montreal _Gazette_ for 94.09.01 reports on page E1 about a pipe-bomb
explosion related to computer bulletin board anarchist files:

    Boy loses 3 fingers in pipe-bomb explosion:
    Kirkland youngster, 13 and 15-year-old friend
    were following instructions on a computer.

    by Ann Carroll, _The Gazette_

    A 13-year-old Kirkland boy lost three fingers on
    one hand and his 15-year-old friend was seriously
    injured last week when a pipe bomb they were making
    --following instructions on a home computer disk--
    accidentally exploded.

The article states that the boys had "decided to try an experiment they had
picked up from a computer information network."  The little idiots ignited the
"high-powered flare" and it exploded in the hands of the 13-year-old.  The other
boy is undergoing continuing treatment to remove shrapnel from his hand.

The mutilated victim's mother destroyed the diskette containing the instructions
but does not know the information's source.

{Comments by MK:

Discussion at HoHoCon 94 in Austin, Texas:

Q:  "What about the Alansky case in Hartford where the cops
    are attacking a BBS for having bomb-making info?"

A:  [Deth Vegetable answers] I wrote those files when I was
    15; and the files are in the news again in Montreal.
    Some kids used my files and blew up their fingers.
    I feel bad about that.  However, anyone stupid enough
    to use the files to make bombs deserves what they get.
    It's like Darwin, you know?  In Canada they don't have
    guaranteed free speech, so the cops are taking boards
    down for having this stuff on them.  Alansky got 28
    onths in jail.  His lawyer said he didn't want to get
    involved with the First Amendment.  So Alansky
    plea-bargained and then went to jail.  There were other
    irregularities; e.g., they didn't inform the lawyer of
    the location for the indictment.

Q:  [MK, loudly] "Why publish such files at all?"
    [Furious faces circle on me from all quarters;
    people recite, "Information Wants to be Free" and snarl,
    "There was nothing illegal about it" and "He had a
    right to post it."]

A:  [Someone hands me a note written by Voyageur]
    "We provide the files in order to protest our rights
    to the freedom of information.  If we voluntarily
    censor ourselves, we do as much as if the government
    were doing it itself.  We maintain our rights through
    the exercise and use of our rights.  In addition, many
    adults enjoy pyrotechnics as a recreational activity.
    Quality information provided at low or no cost greatly
    reduces the risk of pyrotechnic experimentation
    resulting in unfortunate accidents."


    Discussion about posting bomb files with Deth Vegetable
    and others:

    [Would you like to be called Mr Deth or Mr Vegetable?]

    Most people call me, "Veggie."

    [Why did you post the bomb-making files?]

    "The government has the power; so publishing the anarchy
    files is important.  It's as if one day the revolution
    will come and these files will arm the masses to rise up
    against the establishment.  Anyway, it was funny to me
    at the time [when he was 15, 4 years ago]".

    [What about now?]

    "I wouldn't do it now.  I can't say exactly why.  I'm a
    different person now....  Anyway, who's to say if it's
    right or wrong?"

    [MK, seizing D.V.'s shirtfront and slowly drawing him
    to an inter-nose distance of 1 inch:  "Who's to say if
    it's right or wrong?  _YOU_ are.  _I_ am.  [sweeping arm
    to indicate entire room] _We_ are.  We live in a society
    of human beings who have responsibilities to each other.
    We don't live in an anarchic paradise where you can
    ignore the consequences of your actions by appealing
    to a vapid ideology of non-involvement."]

\set disgust = on

I wonder if the fools who posted the pipe-bomb information have any shred of
self-respect.  "If it's legal it must be OK" is a prescription for amoral
anomie.  The National Computer Ethics and Responsibility Campaign sponsored by
the National Computer Security Association and the Computer Ethics Institute
includes a discussion of this attitude; we call it the "video-game syndrome."
The syndrome entails assuming that if something is feasible it must be
acceptable; "after all, if the game designers meant to forbid pressing
CTL-ALT-7 to shortcut to the winning frame, they should have programmed the
game to prevent it."  The next stage is, "If the system administrator wanted
to keep us out of the medical records, she should have put up better
security."  And then "If it were wrong to [name of reprehensible act], it
should be impossible to accomplish it.

set disgust = off\

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)

Poulson Pal Pinched

"Mich Kabay [NCSA Sys_Op]" <>
01 Sep 94 13:22:37 EDT
The Reuter newswire for 30 Aug 1994 issued a report on the capture of Justin
Petersen, a criminal hacker involved in Kevin Poulson's radio-station contest
fraud in Los Angeles:


    LOS ANGELES, Aug 30, (Reuter) - After nearly a year of
    searching, the FBI nabbed a computer hacker who pleaded
    guilty to tapping radio station phone lines to win
    contest prizes, a federal prosecutor said Tuesday.

    Justin Petersen, 34, was arrested after an agent spotted
    him getting out of a car in West Los Angeles on Monday,
    Assistant U.S. Attorney David Schindler said. Petersen
    tried to flee, but was apprehended after a brief foot pursuit.

The article explains that Petersen admitted June 1993 to having committed
"computer fraud, conspiracy and illegally accessing computer files of a credit
rating agency...."  in connection with his nefarious deeds as a close
collaborator of the notorious Kevin Poulson.

At his October 31 sentencing, he could receive 40 years of jail and be fined up
to $1.5 million.

Although he cooperated with law enforcement officials in tracking down other
criminal hackers, Petersen disappeared from view and an arrest warrant was
issued for him.

Petersen called himself "Agent Steal" and boasted about how much he was being
paid by the FBI to inform on his pals at hacker conferences.

M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle, PA)

Barclays Bank's new computer system

Steve_Kilbane <>
Wed, 31 Aug 1994 14:51:00 +0000
Barclays Bank in the UK have a new computer system, and are currently inviting
customers to check their records, in groups. This week, customers with
surnames beginning with J-M are asked to check their records. So I did.

I gave my surname and postcode to the assistant, who promptly brought up my
records on a pretty Motif interface (used to be Windows, as I recall).
Numerous records needed updating. Some were rather dubious. The first recorded
how long I had held an account with them. This hadn't been altered since the
last time I gave them this information, two years ago. It's bad enough telling
them how long they'd had a record of me when they first got the earlier system
going, but they don't seem to update this information at all, and it doesn't
seem to be a time reference. sigh.

The other dubious field was my salary, which occurred in two places (general
form, and employment form), and needed updating in both places. Why is there
this duplication?

A couple of other things bothered me about all this. The first was that I
wasn't asked for any more proof of identity other than my surname and
postcode, and I got to play with all the fun figures that affect my life. I
know this information about at least one friend who banks with Barclays, and
their surname's further down the alphabet. :-> More seriously, this
information is pretty easy to obtain. I raised it with the assistant, and she
informed me that these two pieces of information were considered more secure
than an account number. Sigh. I wasn't even asked to produce an physical ID.

The other problem didn't occur to me until I started writing this. The
assistant turned the screen towards me, and away from all the other people in
the bank. Unfortunately, this also means that she turned it towards the large
wall-like window, and all the people in the street. :-(

Risks of living abroad

DelleraK <>
Fri, 02 Sep 1994 18:08:48 +0100
I have discovered that living outside the US puts you in the
database-never-never-land of People with Foreign Addresses.

I now expect to have to follow up several times after giving my address to
just about any US business: the first time to be told "we can't mail out of
the country" (read: "we can't make the computer mail out of the country"); the
second time to talk to a supervisor, who checks the procedure and tries to
enter the address; the third time to call back and discover it was somehow
mixed up (frequently as an American address with the German postal code as the
ZIP); the fourth time to request a resend with the correct additional postage,
which often must be hand-carried to the mail room... you get the picture.
With luck, I eventually receive a tattered envelope bearing several layers of
metered postage stickers, US postal reject stamps and some handwriting from
the Bundespost employee who managed to successfully interpret the address once
the letter finally crossed the ocean.

Then there are the firms like the credit reporting agency that told me the
only way to fix my garbled address was to contact each of the companies listed
on my credit report...which of course couldn't be mailed out of the country.

The risks?  As usual, computerization can greatly streamline handling of the
routine, but can also eliminate the flexibility to handle exceptions.  And, in
an increasingly international world, not everybody has a ZIP code.

Re: Changeable `constants' (RISKS-16.37)

George W Dinolt <>
Thu, 1 Sep 1994 19:10:07 +0800
Re James Ashton's comments in RISKS-16.37 on changing the value of constants
in Fortran compilers, it was indeed possible to do so on some Fortran and
other compilers. I demonstrated this to my students in the fall of 1972 using
one of the Fortran (I think it was either G or H) compilers on MTS (the
Michigan Terminal System, a time sharing system using IBM 360 tools).

The compiler would not let you assign a new value to a constant directly. One
had to pass the constant as an argument to a subroutine. Inside the
subroutine, one referenced the argument as a variable and hence one could
assign new values to it. Since subroutine arguments were passed by reference,
the value was changed by the assignment and subsequent references to the
constant at any later time and in any procedure reflected the new value.

My guess is that this trick would have worked on any IBM 360 system using the
same compiler. Other compilers would flag the assignment line in the called
subroutine, complaining that one was changing the value of an argument of the

The issues arising from overwriting supposedly constant memory with new and
``useful'' information have been discussed many times in Risks.  This example
is more insidious than some because both the calling and called procedure
appear to be ``correct'' as stand-alone modules. It is the glue (calling
mechanism) which causes the problem. My application of this particular
compiler ``feature'' is just another example of what happens when the
``equivalence'' between algorithms and implementations fails in obscure and
hidden ways.

George Dinolt, Loral WDL

   [The rest of this issue continues this thread.  My inconstant
   moderation allowed me to let the following items through the filter.  PGN]

Re: Changeable `constants' (Ashton, Risks-16.37)

Joseph H Presley <>
Thu, 1 Sep 94 15:24:08 EDT
On the IBM 1130 system (circa 1970 for me), constants were kept in
memory.  The following would output 1 + 1 = 4 as the answer:

       CALL X(1)
       I = 1 + 1
       WRITE (6, 10) I
    10 FORMAT (1H1, 7H1 + 1 =, I2)
       I = 2

Additionally, floating point operations were done via subroutines.  One night
during "student time", I exchanged the + and - subroutines (actually entry
points in one routine) on the system disk for about an hour.

Joe Presley

Re: Changeable `constants' (Ashton, Risks-16.37)

Thu, 1 Sep 1994 16:30:49 -0400
Some years ago when I was at university I heard about a student who had
tried a similar statement in whatever language they were working in at
the time (I think it was a COBOL dialect) and it had worked.  The student
showed the program to a more knowledgeable person with great concern --
in case the program had "broken the 3 in the computer."

Mark Brader,  SoftQuad Inc., Toronto

Re: Changeable `constants'

Thu, 1 Sep 1994 21:24 -0400
Fortran wasn't so bad as to allow "4=3". The problem is that parameters were
always passed by reference, including constants. so that if you had a
subroutine that incremented its parameter, calling it would increment the
constant. This was worse than "4=3" since you couldn't tell by inspection that
would change the constant. There would normally be a single copy of the
constant in memory since machines like the IBM 7094 didn't have inline

Re: Changeable `constants'

Steve_Kilbane <>
Thu, 1 Sep 1994 08:18:41 +0000
Believe it or not, there *is* a useful application for this sort of thing.
The IEC1131-3 compiler generates object code where all data objects are stored
in a lookup table, with constants and variables being virtually
indistinguishable. One reason for this is that while commissioning control
systems at site, field engineers often have to tune "constant" values to get
maximum results from the system. The object file format allows the engineer to
change what the programmer originally considered as a constant.

Ok, so I'm talking about changing the constants after compilation is complete
- the compiler won't allow the programmer to write to a constant - but it's
near enough.

steve  <>

Changeable `constants' (Ashton, RISKS-16.36)

Thu, 1 Sep 1994
  ... Statements like `3=4' could then cause the chaos that you might expect.

This is syntactically incorrect and should not work. However, the
following fragment could have the effect of changing 3 to 4.

    CALL ASSIGN(3,4)

Lars-Henrik Eriksson, Swedish Institute of Computer Science
Box 1263 S-164 28  KISTA, SWEDEN   +46 8 752 15 09

Changeable `constants'

"James Cottrell" <>
1 Sep 1994 09:03:51 -0500
While at RCA in the early 80's I was developing Fortran code for PDP/11-70's
and showed a colleague an example of what you described.  I believe the
example you cite is incorrect since the compiler could determine that the
left hand side of the equation contained a constant making the statement
illegal.  The procedure that would work, turning the constant '3' into any
other value is as follows.

Subroutine Foo

call change (3)

printf (I5)3

Subroutine Change (I)
Integer I
c change the value of 3 for routine Foo

In subroutine Foo after the call to change, the compile time constant '3'
would  be equal to the value assigned in subroutine change.  This change
occurs because PDP Fortran parameter passing was call by address.  I believe,
and with age my memory is getting dimmer on the technical details, the PDP
Fortran compiler would gather all constant declarations in a subroutine and
allocate memory for the constants and load the constants in the memory.  I
don't remember if this memory was in the code space of the routine or in the
data space.  If the memory was allocated in the code space, the modification
of '3' would remain until the subroutine was overlayed.  If the memory was
allocated in the data space, the modification of '3' would remain until the
program stopped.

This problem would not modify the value of the constant '3' in other
subroutines, since the compiler would generate a new (local) copy of all
constants for each subroutine.

!The opinions expressed here are mine and may conflict with my employer,
!wife or any other person.

Changeable "constants" in Fortran

James Carlson <>
Thu, 1 Sep 94 10:55:54 EDT
Close — the actual problem was a bit more obscure.  I know; I've been bitten
by it.

Years ago (about 1983), I worked on Finite Element Analysis software at a
small company in Pittsburgh.  Of course, all of this stuff is done in Fortran
since the original public-domain SAP-IV and PLOT-10 packages were in highly
condensed and uncommented Fortran.

We ran into a problem with the "constant" zero occasionally assuming other
values in one particular module on a Prime 750 running PRIMOS.  The problem
was caused by a sequence of statements of the form:

    call somefunction(iargument,0)
    call anotherfunction(0)

The first callee looked something like this:

    subroutine somefunction(iarg,icount)
    integer*4 iarg,icount
    icount = icount + 1

Of course, Fortran uses call-by-reference rather than call-by-value, so it has
to push an address on a stack instead of a literal value.  To do this with a
constant, like 0, it has to dump the constant into a literal pool and pass the
address of the literal pool entry to the subroutine.  The compiler "optimized"
the other zero-value references in the same module to refer to this
"convenient" constant.  Then, when the subroutine modified the value of zero
in the literal pool, the optimized references were then subtly wrong.  The
following call passed a value of 1 instead of 0 to the next function,
resulting in a skipped element in an array.

Fortunately for my sanity, PRIMOS had a superb debugger, and I knew enough
assembly to figure out what had happened.  (Playing with memory- to-memory
only architectures like the Westinghouse W2500 — a machine with core memory
and a RAM scratchpad — in my misspent youth also helped.  ;-})

James Carlson <> Annex Software Support / Xylogics, Inc.
53 Third Avenue / Burlington MA 01803-4491 +1 617 272 8140

Re: Changeable `constants'

Mark Nelson <>
Thu, 1 Sep 94 18:20:57 EDT
I've never seen a Fortran compiler that allowed assignments of this form, as
this should be easily detected by the parser.  However, code similar to the
following has worked on every Fortran I've ever tested it on (various DEC,
CDC, Cray, and Sun compilers, at least);

      program modify

c     attempt to modify the value of a constant
c     output will probably be 987.654, not the expected 123.456

      call modif(123.456)

      print *,123.456


      subroutine modif(x)
      real x

      x = 987.654


Tricks like this generally don't work with small (absolute value) integer
constants, as most machines provide instructions to load such values into
registers without accessing memory.  But as Mr. Ashton noted, other constants
are often stored as literals in memory, with the compiler efficiently reusing
the same location for each use of a particular value.

Mark Nelson, Department of Computer and Information Sciences,
University of Delaware

Please report problems with the web pages to the maintainer