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 14 Issue 81

Wednesday 11 August 1993

Contents

o Colorado prison is escape-proof! (We'll see...)
Lance Gatrell
o Surprise! contained in tar file
Olaf Titz
o Exploiting Medco's database
David J. States
o SAAB JAS 39 "Gripen" crashed
Lars-Henrik Eriksson
o MD-11 slat extension
Robert Dorsett
Peter Ladkin
o Call forwarding with "remote code" feature
Reva Freedman
o Re: "Terminal Compromise" on the Net
Espen Andersen
o Re: Jurassic Park Networks (rebooting through power reset)
Lauren Weinstein
o Re: ATM modem insecure?
Lauren Weinstein
o CfP, IEEE Symposium on Research in Security and Privacy
John Rushby
o Info on RISKS (comp.risks)

Colorado prison is escape-proof! (We'll see...)

303) 977-2052 Wed, 11 Aug 93 18:27:33 MDT
CANON CITY--They said it about Alcatraz, and they're saying it about Colorado
State Penitentiary.  (Excerpted from The Denver Post, Saturday, July 31, 1993,
pp. 1A, 7A)

Nobody'll ever bust outta this place.

"Can't happen," said George Sullivan, deputy director for operations of the
Colorado Department of Corrections.  "If there is such a thing as an
escape-proof prison, this is as close as you'll get."

From the outside, the new $44.9 million maximum-security penitentiary--which
was dedicated on Thursday--actually appears less secure than some of the other
prisons in the state system, such as Limon Correctional Facility.  There's no
guard tower, for one thing.  And there's no perimeter fence yet.

But even when a 12-foot cyclone fence is completed in September, it will be
designed to keep outsiders away from the building, not insiders from running
away.  The building is so secure, Sullivan said, that type of precaution
isn't necessary.  [...]  Locks, lights and video cameras throughout the
prison can be turned on and off at the touch of a computer screen in a
bullet-proof central control room.  Two doors separate each of four living
units, or "security envelopes," one door controlled by a correctional officer
inside the unit and the other controlled by an officer in the control room.

Lance Gatrell  gatrell@den.mmc.com


Surprise! contained in tar file

Olaf Titz <olaf@bigred.ka.sub.org>
Wed, 11 Aug 1993 22:44:22 +0200
The RISK of trusting in software to save confidentiality has recently been
exposed in a German newsgroup. On a debate whether DES is illegal in Germany
(it is not, by the way) someone posted a tarred, compressed, uuencoded archive
of DES code via an anonymizing service.  (No discussion on the topic of
anonymization, please.) Not only that he forgot to delete the object code
before tarring (thus giving an indication which kind of hardware he uses). The
next day someone else posted an explanation why this action was stupid, giving
the anonymous poster's full real name and address. He found it out because the
tar he used leaves user names (not only UIDs, which would suffice to restore
file permission settings) in the tar file. Of course, this fact is not
mentioned explicitly in the man page rsp. info file (but the average user
wouldn't expect it in the first place...) where an explicit warning could be
considered appropriate.

Olaf Titz  -  olaf@bigred.ka.sub.org  -  s_titz@ira.uka.de


Exploiting Medco's database

David J. States <states@ibc.wustl.edu>
4 Aug 1993 22:19:17 GMT
>From today's (August 4, 1993) Wall Street Journal, pg. B1:
"Merck to Eploit Medco's Database"

The article goes on to explain that Merck, the world's largest pharmaceutical
manufacturer, recently purchased Medco, a chain of discount pharmacies to gain
access to the Medco database of pharmacy purchases.  Merck plans to use this
information in a variety of ways to promote Merck products.  Examples in the
article include:

- a patient is taking a more expensive drug from a competitor so Merck
  would suggest a competitive Merck product to the physician

- based on his other medications a patient is likely to have a condition that
  could be treated pharmacologically by a Merck product so suggest it to the
  physician

The use of pharmacy purchase records as a de facto window into a patient's
medical record, and the commercial exploitation of that information is a very
unfortunate development.  The examples noted above seem benign enough, and the
article states that Merck does not plan to actually identify patient names
when they contact physcians, but this opens the door to commercial
exploitation of medical records data.  Many other uses of this data are very
worrisome.

A tremendous amount of information can be inferred from pharmacy transactions.
Both dosage and duration of therapy can be determined from the purchase data,
and most people tend to stick with a small number of pharmacies.  There are
many thousands of drugs now on the market, and most of them carry very
specific indications for use.  For example, a young adult who purchases
certain antibiotics is likely to be treating a case of the clap; a previously
healthy parent who begins buying insulin is likely to have a child just
diagnosed with diabetes; a single male in his 30's who starts buying AZT
almost certainly has been diagnosed as HIV positive.

How would you feel about Merck selling information about your recent case of
VD to Trojan so they could start direct mail advertising to you?  There is
even some medical justification for doing so.  How about if they sold it to
Playboy/girl?  Or the local televangelist looking for sinners to convert?  Is
there anything to stop Merck from selling a list of patients at high risk for
expensive medical care to insurance companies (who probably have the
information anyway) or to prospective employers?

David States, M.D.


SAAB JAS 39 "Gripen" crashed (from soc.culture.nordic)

Lars-Henrik Eriksson <lhe@sics.se>
Wed, 11 Aug 93 22:30:28 +0200
The SAAB JAS 39 "Gripen" crashed on Sunday, August 8, during an air display
over central Stockholm. The following very preliminary account of the accident
is based on commentaries and video recordings of the accident that I've seen
on Swedish TV. Better information should be available in a few days.

The aircraft was flying straight and level at low altitude and moderate speed.
It began a gentle rocking motion in roll, then the nose pitched up rapidly,
passing the vertical in a manouver resembling Pugachev's cobra. When the nose
was well past the vertical - the pitch-up angle appeared to be about 120
degrees (!) - the pilot ejected and landed unhurt. After some further
manouvres, the aircraft settled in a vertical descent in about level attitude.
From what I could see, the aircraft did not break up in the air.

The aircraft struck a small hill on an island (Laangholmen), exploding on
impact.  The crash site was only tens of metres from a major bridge
(Vaesterbron) packed with spectators. Miraculously no one on the ground was
killed.  Three people got slight burns, one sprained his ankle while running
away. The only damage on the ground was that a tree was struck down.

JAS39 is a statically unstable aircraft controlled by computers (called
"fly-by-wire", or FBW). The FBW system was immediately suspected to be the
reason for the crash.  Indeed, the behaviour of the aircraft is about what you
would expect after a major failure of the FBW system. A person listening on
the radio frequency used by the aircraft during the display claims that the
immediately before he lost control, the pilot reported that a circuit breaker
had tripped.

This is in contrast with the previous JAS 39 crash where the FBW system was
functioning correctly according to the control laws in force, but where these
control laws were incorrect causing the aircraft to overreact to the pilot's
control inputs when the aircraft was hit by a wind gust during landing.

The aircraft that crashed was the first one to be delivered to the Swedish Air
Force. It was flown by the same SAAB display pilot that flew the first
accident aircraft!

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

             [Also noted by Martin Minow <minow@apple.com>
             and Jacob Palme DSV <jpalme@DSV.SU.se>.  PGN]


MD-11 slat extension

Robert Dorsett <rdd@cactus.org>
Fri, 6 Aug 93 03:48:09 CDT
The August 1993 Airline Pilot (p. 19) warns pilots to watch the flap/slat
handle on MD-11's.  This was in reference to the much-publicised incident
involving a China Eastern Airlines MD-11 on April 6, which experienced
uncommanded slat extension and a series of violent oscillations.  The plane
lost 5000', and spooked the crew enough that they made a diversion to an air
base in Alaska to inspect the airplane.

Subsequent commentary in RISKS and elsewhere speculated that the digital
cockpit in the airplane might have been responsible for the deployment.
Comments on sci.aeronautics.airliners tended to indicate that this aspect
of the flight control system was conventional in nature, however.

The article notes:

"NTSB cautioned, in its safety recommendation issued June 29, that 'The
cause of the slat deployment has not been determined  However, preliminary
evidence strongly suggests that the flap/slat handle became dislodged from the
slat-retract position... because of inadvertent contact with the handle
by a flightcrew member.'

"At least 10 other cases of inadvertent or uncommanded inflight slat
deployments have occurred on MD-11's since April 1991 (!!!).  NTSB said
Douglas Aircraft Company has advised operators of those incidents, "is
aware of the continuing nature of the problem, and is... working with FAA
and MD-11 operators to redesign the [MD-11] flap/slat actuating system."

[ Snide personal note: cargo doors, anyone? ]

The article notes that the NTSB urges:

1.  That the FAA establish an interim measure to prevent inadvertent slat
extension.

2.  MD-11 operators to inform crews of the danger.

3.  That the revamped system be installed ASAP.

"The Safety Board said the incidents continued to occur 'despite several
attempted fixes' by Douglas.  The China Eastern Airlines airplane had been
modified to meet all Douglas service bulletins and applicable slat system
[airworthiness directives].

"The day after the first incident, [Douglas told operators about the problem]

"[...] 'Sharply striking the aft side of the handle [it is normally at the
furthest-forward position when flaps are retracted] will allow the handle
to move upward if a very light vertical force is applied,' Douglas
said.  'Normal spring and cable tensions will move the handle aft once
disengaged from the FLAP UP/SLAT RET detent and allow the slats to extend.'

"In August 1992, Douglas designed a protective cover for the zero-degree
detent gate.  FAA later mandated that air carriers use the cover."

"[...] Douglas will replace the current flap/slat handle and its cable
system with an electrically operated system designed to eliminate the cable
tension forces that bias the slat system to the extend position. [...]
The electrically operated flap/slat handle system should be available in mid-
1994; the interim system, within several months.

"Meanwhile, don't bump that flap/slat handle."

[And stay away from DC-10's and MD-11's, as a guiding philosophy in life :-).
--rdd]

Robert Dorsett  rdd@cactus.org  ...cs.utexas.edu!cactus.org!rdd


MD-11 slat extension

Dr Peter B Ladkin <pbl@compsci.stirling.ac.uk>
6 Aug 93 19:44:23 BST (Fri)
>uncommanded [or, rather, inadvertent] slat extension [causes a] series of
>violent oscillations.  The [MD11] lost 5000', and spooked the crew enough that
>they made a diversion to an air base in Alaska to inspect the airplane.

It was not just crew spook.  Two passengers were killed, and all passengers
were injured, some severely.

>Subsequent commentary in RISKS and elsewhere speculated that the digital
>cockpit in the airplane might have been responsible for the deployment.

I sent a query to ata-watchers asking if anyone knew if digital systems were
involved. Mary Shaw responded that the report will eventually cross her desk.
I don't recall seeing anything in RISKS.

I found the MD-11 that I flew on (Swissair) a year ago very comfortable, but ..
> [And stay away from DC-10's and MD-11's, as a guiding philosophy in life :-)
why the smiley face? :-)

Peter.


Call forwarding with "remote code" feature

Reva Freedman <freedman@delta.eecs.nwu.edu>
Fri, 6 Aug 93 14:45:00 CDT
An article in the Chicago Tribune (8/2/93, sec. 2, p. 7, by Terry Wilson) will
make you want to check your next phone bill more carefully. A summary follows.

  A Chicago man named Jeff Baird was concerned because his phone had been
  acting funny for days, ringing once and then stopping. One day last month he
  was able to answer it in the middle of a ring, and he heard a recorded
  message saying that the call was collect from an inmate named Bill in the
  Illinois Department of Corrections [IDOC--the state prison system] and that
  the call was being recorded and monitored. The recorded voice told him he
  could say "yes" and accept the charges or hang up.

  Although Baird was curious about how Bill, whom he did not know, had gotten
  his phone number, he did not accept the charges. The odd rings continued.
  Eventually the Bairds discovered that an IDOC inmate had ordered call
  forwarding for their telephone along with a remote access code, a new
  feature offered by Illinois Bell. With the remote access feature, you don't
  have to be home to change the number your calls will be forwarded to. Just
  dial your home number and type in the code, followed by the number you want
  your calls to be forwarded to! The inmate had  apparently been given the
  three-digit code over the phone by an Illinois Bell employee.

  When the inmate wanted to make a call, he simply started forwarding the
  Bairds' calls to the number he wanted to call. Then he dialed the Bairds'
  number. The person to whom the call was forwarded would hear the recorded
  message and accept the call. The call was billed to the Bairds because it
  was their number which was originally dialed. More than $200 worth of
  collect calls were made in a week, by several inmates. In spite of the fact
  that all the calls were supposedly recorded, IDOC officials claim they
  cannot identify any of the inmates.

  Presumably the inmate un-forwarded the phone when he was through or the
  Bairds would not have received any calls at all. Once, however, Jane Baird
  called home and found herself talking to a complete stranger who declined to
  identify herself or explain why she was answering the Bairds' telephone.

  Illinois Bell eventually discovered that the Bairds had not ordered call
  forwarding. The Bairds will not have to pay for the calls. Illinois Bell has
  decided to mail out the code number to the address where the phone is
  located.

Well, folks, it looks like the phone company has come up with something more
aggravating than call waiting. Seriously, though, call forwarding was
originally designed *without* remote forwarding to avoid precisely
this problem.

Reva Freedman <freedman@eecs.nwu.edu>
Dept. of EECS, Northwestern University, Evanston, IL


"Terminal Compromise" on the Net

ESPEN ANDERSEN <EANDERSEN@HBS.HBS.HARVARD.EDU>
11 Aug 1993 11:15:20 -0400 (EDT)
This may be the first "Novel on the Net" (though the Gutenberg project
may have some comments on that), but it is not the first book
published as Shareware or commercially published through computer
networks.  "Computer Shock", an anthology of pieces about how
computers and technology affect our lives and work, was published in
1987.  Quite a few well-known writers were in it (Jacques Vallee,
Robert Johansen, Barbara Garson, about 10 others.)  The book was
edited by Roger Bullis, professor at University of Wisconsin.  The
thing came in a ZIP (or rather ARC) file with the text files in a COM
format (when you executed the program, the text was shown on the
screen).  A couple of the chapters were about privacy, by the way, as
well as the nature of computerized communication.

My involvement in this was when I worked for the computer center at a
business school in Norway, and we made a chapter of this book a part
of the curriculum in the introductory computer course.  Transferred
the thing to Mac under Hypercard and also to an IBM VM/CMS mainframe
with a small reading program in REXX.  We explained the concept of
ShareWare to the students, and suggested some amount of payment (I
don't remember how much, but we cleared with the editor up front).
Sad to say, not much money came out of it, but I still owe Roger a
beer if he ever makes it to Norway.....

Espen Andersen (hbs.harvard.edu)


Re: Jurassic Park Networks (rebooting through power reset)

Lauren Weinstein <lauren@vortex.com>
Tue, 10 Aug 93 19:34 PDT
A recent posting to RISKS points out the undesirability of rebooting all the
computers via cutting all power on the island in "Jurassic Park".  Such power
resets are a time-honored SF movie technique for trying to solve problems.
For example, in "Westworld" (1973), not only was cutting the power
unsuccessful in stopping rampaging robots ("They're running on stored charge
out there!"), it also, when power couldn't be restored, locked the control
staff in a hermetically sealed room with doors which could only be opened
electrically.  No overrides, so everyone suffocates.

Conceptually similar technical silliness can be observed in "The Andromeda
Strain (1971)", "The Terminal Man" (1974), and "Looker" (1981).  In all
these cases, elementary technical points, unlikely to be overlooked in the
real world, are used as major plot development elements.

By now, many of you have already discerned the pattern in the above.  All of
the films listed were written by Michael Crichton, and in somes cases directed
by him.  Michael is the king of what I call "pop-pseudo-technology"
writing--which generally revels in making as many technical folks as possible
look like complete idiots and incapable of even the most obvious observations.
Given his recent contractual expansions in the wake of "Jurassic Park", there
will be a lot more of the same attitudes coming down the line soon.

--Lauren--


Re: ATM modem insecure?

Lauren Weinstein <lauren@vortex.com>
Tue, 10 Aug 93 19:41 PDT
I wouldn't be too concerned about the *modem* being exposed--at least not from
a data integrity standpoint (whether or not the modem will last long before
being removed by sticky fingers is another matter).  Virtually all modern ATM
terminals use data encryption (typically DES-based) for end-to-end
communications.  The encryption is done within the terminal, so all of the
data that reaches the modem, from either side, should already be "secured."

--Lauren--


Call for Papers, IEEE Symposium on Research in Security and Privacy

John Rushby <RUSHBY@csl.sri.com>
Wed 11 Aug 93 18:05:09-PDT
1994 IEEE Symposium on                              May 16--18, 1994
Research in Security and Privacy                    Oakland, California

                             Sponsored by
  IEEE Computer Society Technical Committee on Security and Privacy
                         in cooperation with
    The International Association for Cryptologic Research (IACR)

The Symposium on Security and Privacy is the premier forum for the
presentation of developments in computer security, and for bringing together
researchers and practitioners in the field.  The focus of this, the 15th
symposium in the series, will include technical aspects of security and
privacy as they arise in commercial and industrial applications, as well in
government and military systems.  The symposium will address advances in the
theory, design, implementation, analysis, and application of secure computer
systems, and in the integration and reconciliation of security and privacy
with other critical system properties such as reliability and safety.  Topics
in which papers and panel session proposals are invited include, but are not
limited to, the following:

Secure systems    Privacy Issues  Access controls  Security verification
Network security  Policy modeling Information flow Authentication
Database security Data integrity  Protocols        Viruses and worms
Auditing and intrusion detection  Commercial and industrial security
Security and other critical system properties      Distributed systems

INSTRUCTIONS TO AUTHORS:

Send six copies of your paper and/or proposal for a panel session to John
Rushby, Program Co-Chair, at the address given below.  Papers and panel
proposals must be received by November 15, 1993.  Papers, which should include
an abstract, must not exceed 7500 words.  The names and affiliations of the
authors should appear on a separate cover page only, as a ``blind'' refereeing
process is used.  Authors must certify prior to December 31, 1993 that any and
all necessary clearances for publication have been obtained.

Papers must report original work that has not been published previously, and
is not under consideration for publication elsewhere.  Abstracts, overlength
papers, electronic submissions, late submissions, and papers that cannot be
published in the proceedings will be rejected without review.  Authors will be
notified of acceptance by February 1, 1994.  Camera-ready copies are due not
later than March 15, 1994.

Panel proposals should describe, in two pages or less, the objective of the
panel and the topic(s) to be addressed.  Names and addresses of potential
panelists (with position abstracts if possible) and of the moderator should
also be included.

The Symposium will also include informal poster sessions where preliminary or
speculative material, and descriptions or demonstrations of software, may be
presented.  Send one copy of your poster session paper to Cristi Garvey, at
the address given below, by January 31, 1994, together with certification that
any and all necessary clearances for presentation have been obtained.

PROGRAM COMMITTEE

  Ross Anderson, Cambridge University, UK
  Tom Berson, Anagram Laboratories, USA
  Leslie Chalmers, Bank of California, USA
  Oliver Costich, CSIS, George Mason University, USA
  Frederic Cuppens, ONERA/CERT, France
  James Gray, University of Science & Technology, Hong Kong
  Sushil Jajodia, George Mason University, USA
  Dale Johnson, MITRE Corporation, USA
  Steve Kent, BBN, USA
  Sue Landauer, Trusted Information Systems, USA
  Teresa Lunt, SRI International, USA
  John McHugh, Portland State University, USA
  Doug McIlroy, AT&T Bell Labs, USA
  John McLean, Naval Research Laboratory, USA
  Jon Millen, MITRE Corporation, USA
  Sylvan Pinsky, National Security Agency, USA
  Michael Reiter, AT&T Bell Labs, USA
  Karen Sollins, MIT Laboratory for Computer Science, USA
  Stuart Stubblebine, University of Southern California, USA
  Gene Tsudik, IBM Research Laboratory, Switzerland
  Yacov Yacobi, Bellcore, USA
  Raphael Yahalom, Hebrew University, Israel

For further information concerning the symposium, contact:

  Cristi Garvey, General Chair       John Rushby, Program Co-Chair
  TRW, MS R2-2044                     SRI International, EL254
  One Space Park                     333 Ravenswood Avenue
  Redondo Beach, CA 90278, USA       Menlo Park, CA 94025, USA
  Tel: +1 (310) 812-0566             Tel: +1 (415) 859-5456
  FAX: +1 (310) 812-4310             FAX: +1 (415) 859-2844
  Garvey@zoo.sdd.trw.com             rushby@csl.sri.com

  Carl Landwehr, Vice Chair          Catherine Meadows, Program Co-Chair
  Naval Research Lab., Code 5542     Naval Research Laboratory, Code 5543
  4555 Overlook Ave., SW             4555 Overlook Ave., SW
  Washington DC 20375, USA           Washington DC 20375, USA
  Tel: +1 (202) 404-8888             Tel: +1 (202) 767-3490
  FAX: +1 (202) 404-7942             FAX: +1 (202) 404-7942
  landwehr@itd.nrl.navy.mil          meadows@itd.nrl.navy.mil

  Frederic Cuppens, European Contact James Gray III, Asia/Pacific Contact
  ONERA/CERT                         Department of Computer Science
  2 Avenue E. Belin                 Hong Kong Univ. of Science & Technology
  31400 Toulouse, France             Clear Water Bay, Kowloon, Hong Kong
  Tel: +33 61 55 70 75               +852 358-7012
  FAX: +33 61 55 71 32               +852 358-1477
  cuppens@tls-cs.cert.fr             gray@cs.ust.hk

    ---snip here-----------------------------------------------------
        Obtaining the Call For Papers for the
         1994 IEEE Symposium on Security and Privacy
              by anonymous ftp

The CFP is available from ftp.csl.sri.com--note the ftp on the
front--(192.12.33.94) in directory /pub in the following forms

Plain Ascii text:   sec-priv94.txt

        Single-page for US-size (8.5x11) paper
LaTeX source:       sec-priv94.tex
LaTeX output:       sec-priv94.dvi (needs binary transfer)
Postscript:     sec-priv94.ps

            Single-page for A4-size paper
LaTeX source:       sec-priv94-a4.tex
LaTeX output:       sec-priv94-a4.dvi (needs binary transfer)
Postscript:     sec-priv94-a4.ps

           Two pages, big font, suitable for faxing
LaTeX source:       sec-priv94-big.tex
LaTeX output:       sec-priv94-big.dvi (needs binary transfer)
Postscript:     sec-priv94-big.ps

Send questions or problems to John Rushby (rushby@csl.sri.com).

Please report problems with the web pages to the maintainer

Top