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:

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 18, Issue 59

Thursday 7 November 1996


o Intel product reaches directly into networked workstations
Jeff Mantei
o Big Internet is Watching You
Martin Minow
o Careful AeroPerusal
Peter Ladkin
o Risks of using keyless coinlockers in Vienna
Stefan Sachs
o Re: Fault-induced crypto attacks ...
Brian Randell
o Why cryptography is harder than it looks
Bruce Schneier
o Info on RISKS (comp.risks)

Intel product reaches directly into networked workstations

EDS OO/AI Svcs, Troy MI) < (Jeff Mantei>
Thu, 7 Nov 1996 13:35:48 -0800
     I don't think this product or class of products has been mentioned in RISKS
     before, but I think their potential for abuse is self-evident and should be
     more widely known.  I quote the following from:
     "Intel is working to make the network's help desk more than just an
      answering service. With LANDesk Manager's remote access facility,
      network managers can take over a node and perform most of the tasks
      that typically would require a visit to the problem workstation.
     "Under Novell's NMS, a network manager clicks on the node's network
      map object and launches LANDesk Manager's remote access tool. The
      manager can take over the user's PC and directly control the user's PC
      keyboard and mouse. The network manager can also access utilities
      and applications remotely, permitting checks of CONFIG.SYS,
      AUTOEXEC.BAT and WIN.INI files or anything else on the machine.
      This eliminates the laborious process of asking an end user to describe
      cryptic error messages and codes."

Big Internet is Watching You

Martin Minow <>
Thu, 7 Nov 1996 07:29:32 -0800
     Over the past month or so, a mailing list I subscribe to has endured a flame
     war with a disgruntled (ex-)subscriber. A few days ago, an anonymous
     participant provided what I'll call an Internet Biography of the subscriber.
     The anonymous message began with "I had some free time this morning, and
     just for fun, thought I'd  create a brief Net profile of our friend ..."
     Among the discoveries are the following:
     -- Home address and phone number from
        (Four11 people search)
     -- Birthday from[Month]/[Day]
     -- Company name and internet domain ownership from InterNIC.
     -- An uncomplimentary "who is ..." from a private academic site.
     -- A Usenet author profile showing over 500 messages posted to about 50
        newsgroups over the last 18 months from profile.
     -- An uncomplimentary note from an academic, private "legends" homepage.
     -- Several professional contributions to FAQ's.
     Over ten years ago, when computer bulletin boards appeared at my former
     employer, I formulated "Minow's law:" "never write anything you don't want
     to see on your resume." I seem to have been more prophetic than I expected.
     Martin Minow,

Careful AeroPerusal (Ladkin RISKS-18.51, PGN RISKS-18.57)

Peter Ladkin <ladkin@TechFak.Uni-Bielefeld.DE>
Fri, 8 Nov 1996 01:52:12 +0100
     There are a lot of rumors about the latest AeroPeru news.  CNN's reports on
     the latest AeroPeru findings have been inaccurate and incomplete. PGN may
     have helped to spread another one in RISKS-18.57.
     The facts are, from a source at the NTSB as well as information about the
     B757 static system (obtainable from my Compendium, see below):
     a) *Masking tape*, not duct tape or `Remove Before Flight' Covers,
        was covering the *left-side static ports* on the aircraft [NTSB];
        (there's no way to attach covers: the ports are flush with the
         fuselage [B757 P/S system diagram]);
     b) Static ports to all three independent pitot-static systems are on both
       the left side and the right side of the fuselage, including those for the
       electro-mechanical backup: both static ports and pitot in each system are
       interconnected by an open tube [B757 pitot-static system diagram];
     c) the right-side static ports have not been recovered; it is therefore
        not known whether masking tape was also covering these [NTSB];
     d) blockage of all the left static ports would cause some degradation
        of *all* the air data in both EFIS-displayed P/S systems plus the backup;
        blockage of the right-side static ports as well would cause worse
        degradation [general aero and system knowledge]; this is thus a *common
        failure mode* of all three independent P/S systems: both primaries
        and backup.
     e) the Peruvian Transport Ministry said that this obstruction of the
        sensors "could explain the erroneous and confusing altitude and
        speed information received by the pilots after takeoff" [NTSB source,
        quoting an official statement]. This contrasts with the Minister's
        reported statement on October 2 which seemed to the press to ascribe
        computer problems as the cause.
     f) Putting masking tape on the ports when cleaning the aircraft is
        a normal maintenance procedure [NTSB]; however, leaving it on is
        certainly not! I don't know whether after such a procedure the
        aircraft has explicitly to be `signed off' after inspection by a
        qualified inspector, who would then make a `returned to service'
        entry in the maintenance logs. This is so for most procedures which
        render an aircraft temporarily unairworthy (as putting tape on the
        static ports does). This is a question still to be answered here,
        and I'm sure there are many readers who could do so;
     g) A further question, posed by Jim Wolper, is why the air crew
        did not notice the tape on static ports on the pre-flight inspection.
        It was dark, but nonetheless on most airplanes visually checking the
        static ports is an explicit item on the pre-flight inspection check list.
        The B757 body is relatively high off the ground, but nevertheless I
        should have thought that tape on the ports would be clearly visible.
     h) The CVR and DFDR have been recovered, examined in the NTSB Laboratories,
        and the data returned to Peruvian colleagues [NTSB];
     In RISKS-18.51, I expressed extreme scepticism that computer failure could
     be the sole cause of any B757 accident (except for one possibility which has
     never happened to any aircraft). It should now be clear that the
     recently-discovered failure mode under discussion is (a) not
     computer-related, and (b) deemed sufficient by itself to cause the known
     effects and history of the flight. This does not of course rule out other
     simultaneous failure modes that are computer-related. We still await the CVR
     and DFDR data.
     More information about the B757 systems and about how a static-system
     blockage would affect the air data, as well as a history of the rather
     misleading statements and press reports about the Aeroperu accident, may be
     found (from Friday 8 November, 1996, and so dated) under the section on the
     AeroPeru accident in `Computer-Related Incidents and Accidents to Commercial
     Airplanes', under Until 8
     November, information on the B757 pitot-static system may be found under the
     BirgenAir section.
     Peter Ladkin

Risks of using keyless coinlockers in Vienna

Stefan Sachs <>
Thu, 31 Oct 1996 22:32:22 +-100
     On my last trip to Vienna, I placed my baggage in a very advanced coinlocker
     in an urban train station. The coinlocker uses a magnetic card instead of a
     conventional key. The user is guided by an LCD Screen on an operating panel
     serving six compartments (equipped with a numeric keypad, which is not used
     for normal operation).  I received my card and since such cards are quite
     common in car parking facilities, left with confidence. On my way back, with
     only twenty minutes left for the train to the airport, following the
     instructions on the screen, I fed the card correctly positioned into the
     slot. Nothing happened and the screen continued to show the instruction, to
     feed the card into the slot to release the lock. When I asked at the ticket
     counter for help, the attendant was in no way astonished and explained that
     this happened because of children playing around with the keypad. A service
     technician was called and used the keypad to release the compartment lock,
     and then started a debugging session collecting several cards from the
     machine.  Complaining that I needed my luggage, I was told that he already
     had made an `exception' by handing me my suitcase without checking my
     identity and that it was my problem losing my card. Considering the need to
     reach my plane and the fact that I couldn't prove that I correctly inserted
     my card, I took my baggage and left.
     The risks I see are these: If such a mechanism fails, it should in any case
     return the keycard it didn't accept. Since the keycard is not further
     protected by a PIN, it makes no sense to keep it to prevent abuse. Since the
     card is the only receipt, it is in the best interest of both, the user and
     the owner of the coinlocker, that it is always available.  Having a keypad,
     which is obviously required only for servicing purposes open for the public
     is a completely unnecessary risk; sooner or later someone will be successful
     in opening the locker using the keypad.  It is absolutely irresponsible, to
     continue to operate a system in which malfunction is so common (during the
     short time, I had to wait for the technician to open the locker, two people
     passing by told me, that they had experienced the same problems before).
     I can only recommend avoiding a coinlocker with such a setup, under any
     Dr. Stefan Sachs, Ringreiterweg 20, 23558 Luebeck, Germany  +49-451-8714936     Dalbacka 30, 66600 Bengtsfors Sweden  +46-531-26069

Re: Fault-induced crypto attacks ... (Kocher, RISKS-18.57)

Brian Randell <>
Wed, 6 Nov 1996 18:00:28 +0000
     A different sort of fault, perhaps, but Tony Sale's lecture here a few weeks
     ago revealed that Bletchley Park's initial breaking of the Lorenz
     teleprinter (a.k.a. "Fish") ciphers in the early years of WW2, which led
     subsequently to the building of the Colossus computers, was entirely due to
     *one* fault on the part of one German teleprinter operator. They found that
     he had resent one lengthy message, but by re-keying it (somewhat
     inaccurately) rather than using the punched teleprinter tape. From this one
     pair of messages they managed to discover the full detailed logical
     operation of the cipher machine unseen, and create a means of breaking the
     messages that were being sent using it to and from the German High Command.
     As Tony said, for the rest of the war, the cryptanalysts prayed that no
     over-eager Allied soldier captured a Fish machine!
     PS. Years ago, after a lecture here by Donald Davies on DES, and emboldened
     merely by my reading of David Kahn and the like, I brought a
     typically-academic discussion of its security to a screeching halt by
     suggesting that perhaps sometime in the future I would be the proud
     possessor of a DES-based cipher machine -- which (like the Enigma cipher
     machine that I already own) was historically famous for the importance of
     the messages that machines like it had failed to protect.  :-)
     Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne,
     NE1 7RU, UK   +44 191 222 7923
       [And of course the Brits also invented E-fish-ient Chips.  PGN]

Why cryptography is harder than it looks

Bruce Schneier <>
Wed, 6 Nov 1996 16:45:52 -0500
       [The item originally in this place was intended to be a draft, not a final
       submission.  I have removed it from the archive copy at Bruce's request.
       The final version will appear in RISKS subsequently.  PGN]

Previous Issue Index Next Issue Info Searching Submit Article

Report problems with the web pages to
This page was copied from:
Last modification on 1999-06-15
by Michael Blume