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 10 Issue 01

Friday 1 June 1990


o RISKS, Volume 10, and FTPing back issues
o Word Perfect Software Upgrade Crashes Utah Phone System
Bill Kules
o Army finds new battlefield system vulnerable to software sabotage
Jon Jacky
o Caller*ID illegal in Penn
Keith Bradsher via Jerry Leichter
o Denial of service due to switch misconfiguration
Marc Horowitz
o Equipment failure or human failure?
Henry Spencer
o More on the Steve Jackson Games raid
Walter Milliken
Stephen J. Webb
o Mailing list risks
John Chew
o ATM range checking
o Info on RISKS (comp.risks)

RISKS, Volume 10, and FTPing back issues

Peter G. Neumann <>
Thu, 31 May 1990 13:18:38 PDT
Welcome to VOLUME 10.  RISKS will be beginning its SIXTH year on 1 August 90,
although it will soon go into a first-month-of-the-summer sporadic mode until

For FTPers who previously complained about the unfriendly sort order produced
by the directory commands, you probably noticed that we recently switched the
archive issue-number file name extensions to double digits (e.g., RISKS-9.01,
02, 03, etc.)  and the volume summaries to RISKS-i.00, for i=1 to 9.  Beginning
with this issue we now have double-digit volume numbers for volume 10 and
beyond, but the original single-digit volume numbers remain for the first 9
volumes.  Beginning with this issue, ALL issue numbers will appear as two-digit
numbers, even in the headers.  (No volume has exceeded or will exceed 99
issues, a decision that ensures that the volume summary issues will be not much
larger than RISKS-9.98 = RISKS-9.00, which was the largest yet.)

Astoundingly, there is always someone going back to get the early issues, which
affords an interesting chronological perspective of where we've been and how we
got to where we are now.  The historical archive also gives lots of clues as to
what we need to do better in the future...

Thanks for your patience through the multiple-copy ordeal.  The various
manifestations of it all seem to have been rectified on my end, although I
still hear reports of problems elsewhere.  PGN

Word Perfect Software Upgrade Crashes Utah Phone System

Thu, 31 May 90 10:16:32 +0100
>From an Infoworld article on Word Perfect ("Leader of the Pack,"
pp. 45-6, May 23, 1990):

"When [Word Perfect] 5.0 shipped in May 1988, the company underestimated
the demand for telephone support.  Although it bought additional phone
lines, traffic was so heavy that calls to the support department brought
down the toll-free systems for the state of Utah, including phone systems
for American Express, Delta Airlines, and the Latter Day Saints Church."

Bill Kules, Automation and Research Computing, Federal Reserve Board,
Washington, DC            wmk@fed.FRB.GOV      Phone: (202) 452-3933

Army finds new battlefield system vulnerable to software sabotage

Thu, 31 May 1990 21:54:24 PDT
                     [More details on this item, first noted in RISKS-9.90.]

Here are excerpts from a page 1 story in MILITARY AND AEROSPACE ELECTRONICS,
vol 1 no 5, May 1990:

VIRUSES COULD CRASH U.S. BATTLE SYSTEM by Lisa Burgess and Tobias Naegele

WASHINGTON - Computer viruses could crash critical battlefield command and
control computers,  according to a draft version of the Army's new Command
and Control Master Plan.  The report says the Army's Maneuver Control
System, touted by developer TRW Inc. as the "integrating node" of the Army's
command and control battle plan, is vulnerable to sabotaged software
designed to undermine and disrupt operations.

... The four-page subsection, titled "Subversive Software" and buried 10
items deep in a section on camouflage, warns that "contractor-developed
non-developmental item (NDI) and `homegrown' software each present unique
[software surity] problems that must be addressed."

Generated by the Army's Combined Arms Combat Developments Activity at Fort
Leavenworth, Kan., the report raises three questions about the potential for
software sabotage to damage the $1.3 billion MCS battle management network:

- Could virus software implanted in the system during the design phase attack
  MCS at a later date?

- Could an agent introduce a virus during combat by surreptitious access to a

- Could an enemy use a captured workstation to introduce a virus over the radio

"Under its present configuration," the report states, "the answer is yes with
regards to MCS."

... Defense contractors say any system using the sort of off-the-shelf hardware
and software utilized in MCS and ATCCS --- the Army Tactical Command and
Control System --- is potentially vulnerable to virus attacks. ...

- Jon Jacky, University of Washington,

Caller*ID illegal in Penn

Thu, 31 May 90 10:44:27 PDT
>From the Los Angeles Times, May 31, 1990, p. D2:

Court Rules Against Caller I.D.: Bell of Pennsylvania's caller-identification
service is an invasion of privacy and violates the state's wiretap law, a state
court ruled.  The decision reverses an order by the state Public Utility
Commission allowing Bell to offer the service.  The service would let people
know who is calling before they pick up the phone, even if the caller's number
is unlisted.  Several other regional phone companies already offer the service.

   [Also noted by (Scott E. Schwartz).]

Court Declares Caller*ID Illegal

Thu, 31 May 90 11:29:18 EDT
[From the New York Times, Thursday 31-May-90, Page D1]

Services Identifying Caller Held Illegal In Pennsylvania,   By Keith Bradsher

A Pennsylvania court ruled yesterday that services that identify the telephone
numbers of callers represent an illegal invasion of privacy.

The verdict was the first in the nation on the legality of such services.  The
five judges of the Commonwealth Court, a mid-level state appellate court, ruled
unanimously that caller identification services ... violate Pennsylvania's
wiretap law.

All five judges found that the services violate the law even when telephone
companies allow some customers to block the release of their telephone numbers.
And the court ruled by a 3-2 vote that the services violate privacy protections
offered by the Pennsylvania Constitution.

"In the framework of a democratic society, the privacy rights concept is much
too fundamental to be compromised or abridged by permitting Caller*ID," Judge
Doris A. Smith wrote in the majority opinion....

But Bell of Pennsylvania criticized the ruling.  "Because of this decision,
Pennsylvanians are being deined a service they eagerly want and badly need -
a weapon against harassing, threatening or obscene calls," [a spokesman said].

    Three Options for Panel

The Commonwealth Court hears appeals of decisions by state and local
administrative bodies in Pennsylvania, and its decisions may be appealed to the
Pennsylvania Supreme Court.  John F. Povilaitis, the chief counsel of the
Pennsylvania Public Utility Commission, said his office would review
yesterday's decision and make a recommendation to the commissioners within a
few days.

[He] said the commission had three options:  to ask [for a rehearing], to file
an appeal before the Pennsylvania Supreme Court, or to allow the decision to

Bell of Pennsylvania was not named as a defendent in the case.  But [it] said
it qualified as a party [and could appeal if the PUC chose not to].

Bell ... filed with the commission on June 18, 1989 for permission to offer
caller identification.  The commission approved the filing on Nov. 9 and the
company scheduled service to begin Jan. 9.  But a Commonwealth Court judge
blocked the service pending judicial review.

The suit was filed against the P.U.C. by the state's Office of the Consumer
Advocate, the [ACLU], the Pennsylvania Coalition Against Domestic Violence
and the Consumer Education and Protective Association.

[Caller id is now] widely available in [five states] and on a limited basis in
[three others] ... according to ... a spokesman for Bell Atlantic Corporation,
the parent of Bell of Pennsylvania.  Phone companies in nine other states and
Washington are seeking to introduce caller identification.

Long-distance companies, including [AT&T], also offer caller identification to
some businesses with 800 and 900 numbers.  Yesterday's decision ...  did not
address whether long-distance companies should stop providing information for
Pennsylvania callers.

"We have to see how, if at all, this ruling affects AT&T," said ... a spokesman
for the company.

    Privacy Issue Cited

Bell Atlantic and other defenders of caller identification have argued that
the services discourage obscene callers and protect the privacy of people
receiving calls by allowing them the choice of not answering.  But the court
ruled explicitly that the privacy of people making calls is more important.

The court found that caller identification services function as call-tracing
devices, which under the Pennsylvania wiretap statute may be used only under
certain circumstances.  The court noted that Pennsylvania requires the consent
of all parties before a telephone conversation may be recorded.

As of December, there were 15 other states with similar requirements.  The
remaining states and Federal law allow taping with the consent of one party.
But [FCC] rules require that all parties to an interstate or international call
be aware they are being taped.

The Pennsylvania wiretap statute contains wording similar to the Federal
wiretap statute.  Bills are pending in the House and Senate that would amend
the Electronic Communications Privacy Act of 1986 to make caller identification
explicitly legal while requiring that telephone companies give customers the
option of blocking release of their telephone numbers.  A subcommittee of the
Senate Judiciary Committee has scheduled a hearing for June 7 on caller

                 [Because of the remarkably complex tradeoffs between
                 defensive functionality and offensive violations of rights,
                 this item seems worth including in its entirety for its
                 intense educational value.  PGN]

Denial of service due to switch misconfiguration

Thu, 31 May 90 03:15:15 EDT
The Massachusetts Institute of Technology runs its own 5ESS switch to provide
telephone service on campus.  This has significant benefits, including many
different telephone classifications (office, dormitory, etc), a modem pool, and
ISDN phones in the offices which pay for them (most do).

This week, I discovered what I consider a serious problem, however.  A friend
was at the Massachusetts General Hospital (MGH) for surgery.  (I'll save you
the suspense: the surgery went well.)  I wanted to call and check on him to see
how the surgery went.  I called the hospital's main number, and was transferred
to his room, except the phone was busy, so the operator gave me his phone

The next day, I attempted to call his room, only to be greeted with "I'm sorry,
but your call cannot be completed as dialed...."  I thought about the
situation, and after placing a call to the MGH operator, discovered that my
friend was in a brand new building with a brand new exchange all its own.  I
called the MIT operator, who told me that the number I was trying to reach was
in Petersburg, over a half hour away (I can see MGH from my room).  I finally
convinced her that this was a number at MGH, but she told me that she couldn't
connect me.  My phone is only able to make local calls, so I called a friend
who works in the same office as the people who run the switch.  They couldn't
make the call.  In other words, neither the operator nor the top class of phone
could make the call.

Today, I called MIT's help line, and described my problem.  Within several
hours, my theory was confirmed.  The switch simply didn't know the new exchange
existed.  It turns out, that as a "client," MIT doesn't get automatic updates
when new exchanges are created.  Without this information, the switch has no
clue how to bill the caller, or even if it should let the caller make the call.
So it assumes the worst case, and disallows anyone from making the call.  The
switch had to be manually programmed with the necessary information about the
new exchange.

This worries me, as someone who isn't as familiar with telephone switching
equipment might not have known what caused it, assumed it was his/her fault,
and been denied service because of it.  It is surprising, to me that our switch
is not configured to take updates of this kind of information automatically
from the New England Telephone switches it talks to.  I was trying to call a
hospital; fortunately it was not an emergency.  My workstation has dynamic
nameservice; my doesn't my telephone switch?
                                                Marc Horowitz

Equipment failure or human failure?

Wed, 30 May 90 23:19:46 EDT
Some little while ago, Risks published the report of a flight crew landing an
airliner in Britain after a very difficult time with wind readings of 100+
knots and repeated equipment failures (in a "glass" [computerized] cockpit).
There is an interesting sidelight on this in the May 2 issue of Flight

    CAA appeals for CHIRP pilot to step forward

    The UK Civil Aviation Authority is publicly appealing to
    an unknown pilot to file a Mandatory Occurrence Report
    about a serious digital cockpit systems failure which it
    is unable to investigate, because the airline pilot
    involved reported it through a confidential reporting system.

    Investigators and airline maintenance staff have no access
    to details of the apparently first-time incident.  The MOR
    would allow the aircraft to be identified and its cockpit
    systems failures identified...

    [Recap of incident, as reported by pilot.]

    The confidential human factors incident reporting program
    (CHIRP) was designed to encourage pilots who have experienced
    a potentially dangerous incident because of human error to
    report it without fear of any disciplinary repercussions.

    It is unclear why this pilot used CHIRP, because there is no
    indication of human error — only bad weather and systems failure...

    [More recap.]

One really has to wonder just what really went on on that flight.  Use of CHIRP
might seem appropriate to a pilot fearful of management reaction to criticism
of electronic aircraft, but as a result the people who want to investigate the
problem are hamstrung, doubts are cast on the accuracy of the report, and if it
*is* factual, that aircraft is still in service and potentially a lethal hazard
to crews and passengers.

Henry Spencer at U of Toronto Zoology                   uunet!attcan!utzoo!henry

More on the Steve Jackson Games raid

Thu, 31 May 90 17:03:04 EDT
I have a friend who's involved with Steve Jackson games and here is his
response to the articles that have appeared recently in RISKS.    -Mark
                      [I had to edit a bit to make it self contained,
                      rather than including all of the previous items.  PGN]

Date: Thu, 31 May 90 14:03 EDT
From milliken@BBN.COM Thu May 31 14:04:19 1990
Subject: Re: Debate on SJG raid in comp.risks

Re: Sherwood, RISKS-9.96:

To the best of my understanding, this account is correct except for trivial
details (not a footlocker, but some filing cabinets were broken open in the
account SJ himself wrote).

Re: Von Rospach, RISKS-9.97

> the person working on for Jackson Games was a former Legion of Doom member...

This first part of this also appears to be true — Loyd was apparently
associated with some bunch of crackers sometime in the past, and apparently
discussed some of the stuff he was doing with Cyberpunk with them, in the way
of reality-checking.  However, Cyberpunk was certainly *not* a "manual on
hacking" — I haven't read my copy yet, but I'm quite certain the game rules
don't go into details of breaking computer security — it just has abstract
security programs and "cracking" programs as things that exist in the game
world.  These things also exist in cyberpunk novels, which is why they're in
the book.

>If you're running a BBS that's supporting a group of system crackers, you are,
>at least, contributory to felony crimes...

The problem was that SJG *was* clean, as far as I know — the Secret
Service just went overboard in their search for "contamination".  I
believe guilt-by-association is not a tenable legal theory in the US.
Grounds for some amount of suspicion, yes.  But search and seizure?

<>Or does it indicate that games which involve "hacking" are subject to ...
>Not if the Legion of Doom angle is true....

The Legion of Doom connection appears to have been there, but very tenuous.
The Feds seem to have been unable to draw the line between fantasy and reality,
and appear to have been operating under a "guilty until proven innocent"
premise as far as the seizure of equipment went.  As far as I know, the Secret
Service had no direct evidence that SJG or the BBS had *anything* to do with
their case — mere proximity to the principals seems to have triggered the
raid.  I would expect that they would have done more research before swooping
down and carting off someone's business equipment.

I can understand how the raid happened, and even sympathize somewhat with the
motivations of the Secret Service, but I think that they definitely stepped
over the line here.  One of the principles of the law in this country is that
the innocent shouldn't be harmed in the pursuit of the guilty.

RE:Steve Jackson Games

Fri, 1 Jun 90 09:15 EST
The chance of GURPS Cyperpunk being used as a manual for computer crime is very
slight indeed.  In Cyperpunk fiction, a hacker's interface with the computer
network he or she is trying to operate in is an actual physical connection with
the computer.  This connection is usually in the form of a direct link to a
person's brain through jacks surgically implanted in their skull.  It is my
understanding that Steve Jackson Games used the same method of interfacing with
computers in GURPS Cyperpunk.  This would make it a little difficult for a
person to use the game rules a handbook for crime.  Unless they had a friend
real handy with tools...:-).
                                             Stephen J. Webb

Mailing list risks

John Chew <john@trigraph.uucp>
Thu, 31 May 90 12:43:56 EDT
I received two copies of a well-known Macintosh software company's "Technical
Solutions" newsletter today, identically addressed.  It happens fairly often
and I wouldn't have given it a second thought, except for the lead article:
"Eliminate Duplicate Records: Omitting and Deleting Duplicate Records in
<database program>".  It starts off "Eliminating duplicate records is part of
the ongoing maintenance of any mailing list...."
                                                            John Chew

ATM range checking

Fri, 01 Jun 90 07:07 PDT
 In RISKS 9.96, Richard Muirden writes of his experience with $89m showing up
in his bank account; his bank blamed him for keying in the amount at the ATM.
He went on to wonder about the range checking that might or might not be
employed at the ATM to catch "such obvious erroneous data".  It is my
experience that there is, indeed, NO such checking performed--at least at one
institution, at one time.
 A few years back, my credit union installed an ATM machine; as part of the
hoopla surrounding the event, they had a demonstration where members could
"practice" on the machine, using a card provided by the demonstator.  I, being
the obnoxious sort, made use of the opportunity to determine an empirical
answer to the question of range checks.  I cheerfully deposited the amount of
$99,999,999 in the account.  The demonstrator was rather worried when I showed
him the receipt (oops--I meant "transaction record"); it seems that they were
using a live account for the demo, which meant that all these phoney
transactions would show up on the balance sheets at the end of the day!  I did
hear later that the trouble caused was minimal, but they did have to jump
through some hoops to make sure there were no ripple effects caused by that
 P.S.--My personal feeling is that any non-zero deposit is an "obviously
erroneous value"; I don't like giving my money to a machine in exchange
for a worthless transaction record.                                    Andy

Please report problems with the web pages to the maintainer