| 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/18.59.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Intel product reaches directly into networked workstations
Big Internet is Watching You
Careful AeroPerusal
Risks of using keyless coinlockers in Vienna
Re: Fault-induced crypto attacks ...
Why cryptography is harder than it looks
Info on RISKS (comp.risks)
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:
http://www.intel.com/comm-net/sns/showcase/netmanag/ld_virus/whites/wp-etem.htm
"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."
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 http://www.yahoo.com
(Four11 people search)
-- Birthday from http://www.boutell.com/birthday.cgi/[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 http://www.dejanews.com 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, minow@apple.com
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 http://www.techfak.uni-bielefeld.de/~ladkin/ Until 8
November, information on the B757 pitot-static system may be found under the
BirgenAir section.
Peter Ladkin
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
circumstances.
Dr. Stefan Sachs, Ringreiterweg 20, 23558 Luebeck, Germany +49-451-8714936
ssachs@acm.org Dalbacka 30, 66600 Bengtsfors Sweden +46-531-26069
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!
Brian
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 Brian.Randell@newcastle.ac.uk +44 191 222 7923
[And of course the Brits also invented E-fish-ient Chips. PGN]
[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]
| This page was copied from: | http://catless.ncl.ac.uk/Risks/18.59.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |