University of Bielefeld -  Faculty of technology
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D.
Back to Abstracts of References and Incidents Back to Root
This page was copied from: http://catless.ncl.ac.uk/Risks/16.13.html


Previous Issue Index Next Issue Info Searching Submit Article

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 16, Issue 13

Thursday 9 June 1994

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents

o RISKS summer slowdown
PGN
o False alarm in Channel Tunnel
John Colville
o Apathy toward computer errors
Chip Seymour
o Mailing-list software security problem
Jim Patterson
o GIF contains more than just a picture
Matthew David Aldous
o Re: "The Ghost in the Modem"
Scott Dickson
o Re: China Airlines A300 Crash
Mark Terribile
o Re: Flaw ? in Clipper
A. Padgett Peterson
Robert I. Eachus
o WWW Virtual Library page on safety-critical systems
Jonathan Bowen
o "Network Security Secrets" by Stang
Rob Slade
o Re: "The Hacker Crackdown" by Bruce Sterling, via WWW
John Oram
o Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
---------------------------------------------

RISKS summer slowdown

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 7 Jun 94 9:42:08 PDT
     
     RISKS is about to enter its customary summer slowdown period, including the
     next month or so during which I will have only sporadic net access.  Please
     do not expect to get rapid response to your requests or frequent issues.
     However, please keep the incisive contributions coming, and I will get to
     them whenever possible.
     
     I wish you all a peaceful and productive summer season.
     
     PGN
     
     
---------------------------------------------

False alarm in Channel Tunnel

John Colville <John.Colville@brunel.ac.uk>
Wed, 8 Jun 1994 11:06:17 +0100 (BST)
     
     As reported on BBC Radio, Wednesday 8 June 1994:
     
     A train travelling through the Channel Tunnel from England to France, was
     evacuated after an emergency light came on in the driver's cabin.  The
     drivers of the 10 lorries [Amer: trucks (JC)] who were being carried on the
     train were evacuated to the English end of the Tunnel, through the access
     tunnel. This was the first emergency on the Channel Tunnel which officially
     opened last month.
     
     It turned out that the emergency was a false alarm.
     
     John Colville, Visiting Brunel University  John.Colville@brunel.ac.uk
     +44 895 274000 ext 2561 until June 1994, from University of Technology, Sydney
     
     
---------------------------------------------

Apathy toward computer errors

Chip Seymour <CHIP@bdso.cv.com>
Tue, 31 May 1994 08:27:36 EST
     
     The Worcester (MA) Telegram of Saturday, May 28, carries a front-page article
     regarding "a mistake by the city Election Commission [which] nearly cost
     [name deleted] his wife."
     
     A week before, a city resident "opened his mail to find a computer-generated
     census form from the city." Apparently, he didn't look at the form closely,
     and when he handed it to his wife for her signature, she noticed the name of
     the person living with him at the same address was not hers.
     
     She had just returned from one of many extended visits with an out-of-town
     daughter.
     
     "'Who is this Beverly that's living with you?' his wife, Barbara demanded.
     'Come on, Barbara ... nobody is living with me,' he shot back. 'Well, they
     got it right here,' she countered, pointing to the name Beverly A. [different
     last name] on the form. 'If I find out, I'm going to get a divorce.'"
     
     After a call to the city Election Commission, he discovered that the presence
     of the Other Woman is an error that may be attributed to the fact that he lives
     in an apartment building for senior citizens, and the Other Woman lives in
     another apartment in the same building.
     
     A spokesman for the Election Commission said if the victim "crosses out the
     incorrect information and mails the form back to City Hall, it will be
     corrected in the computer."
     
     The victim "says he has no intention of signing and sending in the erroneous
     form - and if his name is removed from the voter registration list, which is
     the penalty for failing to respond to the census, 'somebody else is going to
     have a lot more trouble.'"
     
     "'I'm not going to send it in. They make too many mistakes, and I'm not going
     to rectify their mistakes,' he said. 'I can't see why people have to keep
     paying for their mistakes all the time.'" He says this is the "last straw."
     
     The RISKS? If the City Election commission relies solely on returned census
     forms, accidental and intentional inaccuracies will remain. Given the current
     economic climate in the NorthEast, it's not likely local government will verify
     the information on every returned census form containing corrections.
     
     Another risk is the perceived apathy on the part the public. If this fellow
     refuses to correct and return the form, how is the Election Commission going
     to correct the error? What if others follow his lead?
     
     A third risk was mentioned by the Other Woman, who had not received a census
     form this year: "The census form is supposed to be confidential, but went to
     the wrong place."
     
     
---------------------------------------------

Mailing-list software security problem

Jim Patterson <jhp@photon.com >
Tue, 7 Jun 1994 21:24:49 -0700 (PDT)
     
     Several perfect examples of software risks here.  First is running a security
     mailing list with software that has security problems.  Then the ever popular
     quick change to complicated software that generates unexpected (and annoying)
     results.  Finally, there were the users sending messages complaining about
     the duplicate messages to the list which were promptly forwarded to the list,
     in triplicate.
     
     from the keyboard of bugtraq-owner@cscns.com ->
     > Sorry.  I made some changes to the list code because of a serious
     > security hole found within the list software (a popular one).
     > This apparently caused things to go bonkers.  Please stay patient.
     > The author of the mailing list software will release information
     > regarding the security vulnerability within the next few days.
     > --Scott
     
     Hope you found this as amusing as I did.
     
     Jim Patterson   Photon Research Assoc.   jhp@photon.com
     
     
---------------------------------------------

GIF contains more than just a picture

Matthew David ALDOUS <aldous@mundil.cs.mu.OZ.AU >
Thu, 9 Jun 94 17:34:40 EST
     
     I'm currently involved in a software development project, writing software
     to assist medical diagnosis of brain scans. Although I've ploughed through
     abound 50 pages of documentation now, without actually coding a single line,
     I decided it was time to whip up some "vapourware" snap shots of the screen
     I was intending to use.
     
     These I created in a paint program, and whisked off to the supervisor
     for a critical review, etc.. Paper can only say so much..
     
     The response I got was going as would be expected. Some suggestions for
     layout, color schemes, font sizes, etc.. Until I got to section 6..
     
         ----
         5  yellow cross-hairs stand out better - is the red arrow for some
            reason?  Not apparent what (or if)
     
         6  not knowing what all the options were, I tried playing with a few.
            I certainly ended up with some images I did not expect.  I figured
            I should be able to get back to where I started by a judicious choice
            of operations.  Alas - not so judicious.  I certainly did not expect to
            get the text in mirror-image form, even if the picture was.
            I also thought 'normal' would redraw the original image, but this was
            not so.  Is there some easy option to get back to where you started?
         ----
     
     I was quite taken back. I had only submitted a gif, but my supervisor was
     suddenly telling me about all the "options" etc. Gollies, a GIF with a built
     in OS independent GUI...
     
     Turns out, the supervisor had been using "xv" to view the GIF, and had
     accidentally clicked the right mouse button on the picture at some stage,
     opening the "xv edit screen", and assumed that the new window was part of the
     submission ,etc. (Gosh, that _IS_ overwork.)
     
     The RISK ? Having a totally foreign program pretending to be mine, without
     any intent. Was "xv" too user-friendly? Gollies, I was subsequently told that
     if I hadn't questioned the response that it would have been assumed I was
     working extra hard.. :)
     
     We all had a good chuckle over it, and went back to work :)
     
        [Hmm, I suppose that someone is going to come along and refer to "xv"
        as the FIFTEEN program, which is NINE more than "vi", which is sometimes 
        mistakenly referred to as the SIX EDITOR (according to a sighting 
        reported to me by Caveh Jalali)!  PGN]
     
     
---------------------------------------------

Re: "The Ghost in the Modem" (RISKS-16.11)

Scott Dickson <scott@ontek.com >
Wed, 8 Jun 94 11:11:41 PDT
     
     Regarding a recent RISKS posting of the article "THE GHOST IN THE MODEM" by
     Richard Sclove and Jeffrey Scheuer of The Loka Institute, I fail to see how
     the rather insightful analysis of the impacts of government meddling in favor
     of highway-based transportation supports the conclusions:
      
     >      Three lessons for the construction of the information superhighway
     > suggest themselves:
     > 
     >      o _No Innovation Without Evaluation_: ... federal government should
     > mandate evaluated social trials ...
     > 
     >      o _No Innovation Without Regulation_: We should conserve cultural
     > space ...
     > ... modest tax on electronic home shopping and consumer services ...
     > 
     >      o _No Innovation Without Participation_: ... the Danish government
     > appoints panels of everyday citizens ...
     
     These conclusions would lead us down the same road of the government using
     regulatory and taxing powers to distort the application and development of
     technology.  A common mistake is for people to observe or foresee a danger and
     demand that government do something about it.  They fail to take into account
     the risks involved in getting government involved, with its tax and regulation
     sledgehammers.  This is appropriate when the dangers to be mitigated are great
     enough, but is not something to be suggested lightly.  In many cases, people
     may be better off accepting the risk of the danger than putting up with the
     effects of government involvement.
     
     The kind of preemptive government involvement advocated in this case is
     particularly questionable, since the dangers aren't really known and premature
     government meddling may actually make things worse (as the authors argue may
     have happened in the case of transportation).
     
     Scott Dickson  scott@ontek.com
     
     
---------------------------------------------

Re: China Airlines A300 Crash (Yesberg, RISKS-16.09)

<mole-end!mat@uunet.uu.net>
Fri, 3 Jun 1994 18:48:11 -0400
     
     The proper solution is not to increase the number of modes, but to decrease
     the number of modes--to ONE.
     
     `Less advanced' aircraft, which I believe include Boeing aircraft, use their
     sophisticated flight control systems to make the plane behave like a simple
     plane with simple controls.  `Fly by wire', to their designers, means `make
     the best, and best-behaved, simulation of a plane with direct linkage from
     controls to control surfaces.'  `More advanced,' in Airbus case, means
     `having a greater chance for error.'
     
     This has been debated in the aircraft industry, but the FAA has not seen
     fit to refuse certification to Airbus.  My own belief, unsupported by
     professional qualification of any kind, is that this is a serious mistake,
     perhaps unavoidable due to the political nature of the Airbus Consortium.
     
     If I understand correctly, Airbus was forced to use these multimode control
     systems because some of its aircraft use sidestick controllers.  Sidestick
     controllers provide very little range of motion compared to the traditional
     yoke (wheel on a moving stick/post), and the pilot effectively flies using
     pressure rather than position of the sidestick.  This is fine during normal
     flight, but during takeoff and landing the control surfaces must be moved
     through large excursions, and the additional control modes are needed to
     allow this.
     
     There is another serious problem with the control mechanism described: the
     autopilot used one set of control surfaces (stabilizer trim) while the
     pilot continued to operate another (elevators).  In effect, the aircraft
     and its inherent flight laws provide the summing of the control inputs.  For
     such an arrangement to work at all, the summing process must remain linear,
     must not interfere with the flight of the aircraft in other ways, etc.
     Clearly, this did _not_ happen.  An unqualified person such as myself has to
     wonder what happens when the stabilizer is canted one way and the elevator
     is canted the other.  The result, it seems to me, should be excess drag and
     a disrupted airflow, leading to reduction or loss of control response to
     both inputs.
     
     There is a third problem: the pilot has no indication through his controls
     that the autopilot--in effect, the aircraft's control laws--are actively
     working against him.  In an emergency, there are only two things he is
     likely to pay attention to--the primary instruments and the controls
     under his hands and feet.  If he were to put the plane to the edge of a
     stall, either the natural buffet of the stall or an artificial stick-shaker
     designed to simulate the buffet would alert him.  _That_ is probably the
     proper place to inform the pilot that he is working the aircraft against
     the edge.
     
     I don't fly much, but if I find myself booked on an Airbus plane I will
     look for an alternate booking.
     
     Mark Terribile   mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
     
     
---------------------------------------------

Re: Flaw ? in Clipper

A. Padgett Peterson <padgett@tccslr.dnet.mmc.com >
Thu, 9 Jun 94 13:43:58 -0400
     
     Earlier I wrote re Clipper LEAF spoofing:
     
     >> IMHO this is almost meaningless since *both* ends will need to do this
     >> (AFAIR each side sends a LEAF. If only one LEAF is spoofed, it will
     >> just be necessary for a legal tapper to use the other one).
     
     and received the following correction:
     
     >According to a talk here at MIT given by two NSA mathematicians the
     >day the NYT broke the story (a happy coincidence :-), this is not
     >true.  Using Capstone/Tessera, only one LEAF is sent, by the
     >originating party.
     
     I wrote:
     
     >> Dr. Blase also mentioned that it would take about 20 minutes to come
     >> up with a valid checksum. Much easier would simply be to record a
     >> valid LEAF from another chip and use that.
     
     and was again corrected:
     >Can't do that, as Perry said.  The LEAF is a function of the session
     >key, so it needs to be spoofed for each session.
     
     What happens appears to be (after reading the draft of Dr. Blase's paper
     but with some inference - any mistakes are mine) that the receiving 
     Baltimore Clipper decodes the LEAF sent by the originator using the
     family key, replaces the sender's unit-key-encrypted session key with its 
     own clear session key, mixes in the originator's unit id (also in the LEAF), 
     calculates a new checksum, and compares this with the one received.
     
     The obvious implication is that what Dr. Blase was altering may not have 
     necessarily been the checksum (IMHO it was the unit ID) but probably was 
     the last sixteen bits of the LEAF. I leave the implications to those who have 
     the good fortune to have received samples.
     
     But then and again it is all moot since IMHO the gov (or at least the
     Clips, Billary may not have been completely filled in) do not intend 
     to use the LEAF anyway.
     
     Padgett
               [Various similar comments are not included here.]
     
     

Flaw ? in Clipper [Some duplication w. the previous item]

"Robert I. Eachus" <eachus@spectre.mitre.org>
Thu, 9 Jun 1994 10:28:23 -0400
     
        A. Padgett Peterson (padgett@tccslr.dnet.mmc.com) wrote:
     
       > IMHO this is almost meaningless since *both* ends will need to do
       > this (AFAIR each side sends a LEAF. If only one LEAF is spoofed,
       > it will just be necessary for a legal tapper to use the other
       > one).
     
        As far as I am concerned, this is why the flaw Dr. Blase discovered is so
     damning.  If the effect of an authorized wiretap on an EES phone is that the
     correspondents [?] key is removed from escrow, this destroys the entire
     purpose of the system.
     
        For example, a call in a mobile system would involve a chip in the phone,
     and a chip in the base station.  If the result of a legal wiretap on a
     LEAF-blower equipped mobile phone is that the keys of all the base stations
     in the vicinity are turned over to the tappers, the escrow system protects no
     one.
     
       > Dr. Blase also mentioned that it would take about 20 minutes to
       > come up with a valid checksum. Much easier would simply be to
       > record a valid LEAF from another chip and use that.
     
         This is a double misapprehension.  First, the twenty minutes (divided by
     the number of chips used) delay is only associated with some modes of use.
     Second, the problem is not in collecting LEAFs, but in finding one that will
     be accepted by your correspondent for THIS call.  In some cases that will be
     doable in advance, in others it will be easy, and in a few cases it may have
     to be done "the hard way" after the call has been initiated.
     
       > The most important element is that the SKIPJACK algorithm is in no
       > way affected by this and is as strong as ever, only the
       > government's ability to use the LEAF may be compromised.
     
          Not quite true.  Being able to "peer through" the crypto protection is
     usually the first step in a complete crack.  In this case it opens up
     (actually makes more effective) avenues of attack, which while they seem
     computationally infeasible today, may shorten the effective lifetime of the
     EES system.
     					Robert I. Eachus
     
     
---------------------------------------------

WWW Virtual Library page on safety-critical systems

<Jonathan.Bowen@comlab.oxford.ac.uk>
Thu, 9 Jun 94 14:57:32 BST
     
     I have created a WWW Virtual Library page on safety-critical systems,
     including links to on-line RISKS information, under:
     
       http://www.comlab.ox.ac.uk/archive/safety.html
     
     Relevant information with URL links for possible inclusion, preferably
     in HTML format, is welcome.
     
     Jonathan Bowen  Oxford University Computing Laboratory
     http://www.comlab.ox.ac.uk/oucl/people/jonathan.bowen.html
     
     
---------------------------------------------

<"Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067">
Thu, 09 Jun 1994 10:24:59 -0600 (MDT)
     Subject: "Network Security Secrets" by Stang
     
     BKNTSCSE.RVW  940324
      
     International Data Group
     155 Bovet Road, Suite 310
     San Mateo, CA   94402 USA
     tel 415-312-0650  fax: 415-286-2740
     "Network Security Secrets", Stang, 1993, 1-56884-021-7, U$49.95/C$64.95
     norman@digex.com
      
     It's hard to have confidence in a book on data security that starts off with
     two examples of "back doors" -- neither of which have the slightest connection
     to back doors.  Then, there is the example of radiation risks which cites a
     study probably more related to chemical exposure.  Do not lose heart, however. 
     These are apparently aberrations in what is otherwise a very practical and
     down-to-earth security manual.
      
     That opening chapter on specific examples starts a section on risk analysis. 
     Security mavens may find it lacking in rigour and overlong in verbiage, but
     most micro/LAN/office managers have little formal training in the formal
     aspects of data security and need the example after example approach.  The
     questionnaires and quizzes probably drive the point home as well as, or better
     than, Stang's love of charts.
      
     Part two is a bit weaker.  It opens with a questionable chapter on the
     "players" in the game:  data security versus the hackers.  There is a chapter
     on the security aspects of network design.  Given Stang and Moon's background
     in the NCSA the two virus chapters are no surprise, and generally good.
      
     Part three gives more detail (*lots* of detail in the tabular reviews of
     chapter 12) on security solutions, policies and products.  Not exhaustive:  the
     password chapter, in looking at security *breaking* programs, makes no mention
     of the HACK program for obtaining any passwords used over Ethernet or the KNOCK
     program which exploits a bug in versions of NetWare which allows anyone to gain
     SUPERVISOR access without passwords.  Still, there is much practical help for
     the LAN manager here.
      
     Part four looks at specific network operating systems and the security features
     and functions thereof.  As well as comparisons of the different systems, there
     are chapters collecting the security commands and concepts of each.  These are
     handy, but not necessarily more so than the original documentation.  NetWare
     "effective rights", for example, continue to bedevil LAN managers using
     Novell's software.  All the parts are included here, but the calculation of
     effective rights is not deal with.  (There is also one "oops".  The chapter on
     UNIX security contains a description of the VMS "WANK" worm.)
      
     Part five looks at ways to implement security.  An unusual, but very valuable,
     section in the chapter on training is an extensive list of training available
     in a variety of security related areas.  (Most of the virus courses seem to be
     given by an outfit called Norman Data Defense Systems.  Oh well.)
      
     Part six briefly describes the shareware files on the included disks.  A series
     of appendices primarily give contact information.
      
     It'll be difficult to get a busy LAN manager to sit still long enough to read
     this.  But it'll be worth it.
      
     copyright Robert M. Slade, 1994   BKNTSCSE.RVW  940324
     
     DECUS Canada Communications, Desktop, Education and Security group newsletters
     Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
     BCVAXLUG ConVAXtion, Vancouver, BC, Oct. 13 & 14, 1994 contact vernc@decus.ca
     
     
---------------------------------------------

Re: "The Hacker Crackdown" by Bruce Sterling, via WWW

John Oram <oramy92@halcyon.com >
Thu, 9 Jun 1994 00:39:34 -0800
     
     Bruce Sterling has released 'The Hacker Crackdown' electronically.  It
     is available via WWW at
     
     http://www.eecs.nwu.edu/hacker_crackdown/index.html
     
     (This is a mirror of http://www.scrg.cs.tcd.ie/scrg/u/bos/hacker/hacker.html)
     
     [But be sure to read the preface about the copyright and why and how Bruce is
     also making the book available on-line.  I have excerpted the beginning of
     the preface here, because it is too long to include here.  PGN]
     
       The Hacker Crackdown
       Preface to the Electronic Release of The Hacker Crackdown
     
       Out in the traditional world of print, The Hacker Crackdown  is ISBN
       0-553-08058-X, and is formally catalogued by the Library of Congress as "1.
       Computer crimes -- United States. 2. Telephone -- United States -- Corrupt
       practices. 3. Programming (Electronic computers) -- United States --
       Corrupt practices." `Corrupt practices,' I always get a kick out of that
       description. Librarians are very ingenious people.
     
       The paperback is ISBN 0-553-56370-X. If you go and buy a print version of
       The Hacker Crackdown, an action I encourage heartily, you may notice that
       in the front of the book, beneath the copyright notice -- "Copyright (C)
       1992 by Bruce Sterling" -- it has this little block of printed legal
       boilerplate from the publisher. It says, and I quote:
     
        "No part of this book may be reproduced or transmitted in any form or by
        any means, electronic or mechanical, including photocopying, recording, or
        by any information storage and retrieval system, without permission in
        writing from the publisher.  For information address: Bantam Books."
     
       This is a pretty good disclaimer, as such disclaimers go. I collect
       intellectual-property disclaimers, and I've seen dozens of them, and this
       one is at least pretty straightforward. In this narrow and particular case,
       however, it isn't quite accurate. Bantam Books puts that disclaimer on
       every book they publish, but Bantam Books does not, in fact, own the
       electronic rights to this book. I do, because of certain extensive contract
       maneuverings my agent and I went through before this book was written. I
       want to give those electronic publishing rights away through certain not-
       for-profit channels, and I've convinced Bantam that this is a good idea.
     
       Since Bantam has seen fit to peaceably agree to this scheme of mine, Bantam
       Books is not going to fuss about this. Provided you don't try to sell the
       book, they are not going to bother you for what you do with the electronic
       copy of this book. If you want to check this out personally, you can ask
       them; they're at 1540 Broadway NY NY 10036. However, if you were so foolish
       as to print this book and start retailing it for money in violation of my
       copyright and the commercial interests of Bantam Books, then Bantam, a part
       of the gigantic Bertelsmann multinational publishing combine, would roust
       some of their heavy-duty attorneys out of hibernation and crush you like a
       bug. This is only to be expected. I didn't write this book so that you could
       make money out of it. If anybody is gonna make money out of this book, it's
       gonna be me and my publisher.
     
       My publisher deserves to make money out of this book. Not only did the
       folks at Bantam Books commission me to write the book, and pay me a hefty
       sum to do so, but they bravely printed, in text, an electronic document the
       reproduction of which was once alleged to be a federal felony. Bantam Books
       and their numerous attorneys were very brave and forthright about this
       book. Furthermore, my former editor at Bantam Books, Betsy Mitchell,
       genuinely cared about this project, and worked hard on it, and had a lot of
       wise things to say about the manuscript. Betsy deserves genuine credit for
       this book, credit that editors too rarely get.  [...]
     
     
---------------------------------------------

Previous Issue Index Next Issue Info Searching Submit Article


Report problems with the web pages to Lindsay.Marshall@newcastle.ac.uk.
This page was copied from: http://catless.ncl.ac.uk/Risks/16.13.html
COPY!
COPY!
Last modification on 1999-06-15
by Michael Blume