Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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]
Please report problems with the web pages to the maintainer