The RISKS Digest
Volume 17 Issue 70

Thursday, 8th February 1996

Forum on Risks to the Public in Computers and Related Systems

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

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…

Contents

Train operators get permission to use manual backup
Tom Comeau
Electronic Medical Records and Images
Jay Brown
Risks of web robots
Joe A. Dellinger
Air Traffic Control Dependability
Jim Wolper
So many RISKS, where do you start?
Steve Doig
CFP : Dependable Computing for Critical Applications
Catherine A. Meadows
Info on RISKS (comp.risks)

Train operators get permission to use manual backup

"Tom Comeau @ Space Telescope Science Institute" <tcomeau@stsci.edu>
Sun, 04 Feb 1996 21:22:05 EST

During the early hours of the "Blizzard of '96" in the Washington metropolitan area, a Metro train operator was killed when his train ran into the back of a parked train at the Shady Grove Metro station. Shady Grove is one of the endpoints of the system, and is located in Gaithersburg, Maryland, a northern suburb of Washington.

The train was being taken out of service for the night, and had moved past the station platform and into a railyard at the terminus. Press reports at the time indicated the train rolled past the station at normal track speed, and struck a parked train. The operator, who sits in a very small (< 2m square) compartment at the very front of the train, was pinned in the car and died of his injuries.

There were early conflicting reports about the cause of the accident. Several sources reported hearing radio calls from the train to the track supervisor, asking for permission to take the train off automatic control and manually move into the yard. There was disagreement over whether permission had been granted, and one source suggested the operator had failed to pay attention to his speed after taking manual control. More recent reports suggest that permission was refused, and the train was under automatic control at the time of the collision.

While the investigation is ongoing, Metro announced today that changes in operational procedures were being made immediately in light of what had already been learned. The change announced today is that operators will have discretion at all times to take trains out of automatic mode.

A local radio station reports that the operator asked for permission to take the train under manual control, that permission was refused, and the train proceeded through the station at fairly high speed, applied the brakes normally, but failed to stop on the icy rails.

Some of the risks are obvious: The automatic system is unable to determine if traction on the rails is poor, and so does not adequately adjust a train's speed. The trains are routinely operated in automatic mode in crowded rail yards, which builds confidence in the system under ideal (dry) conditions. Supervisors must approve taking a train out of manual mode, and those supervisors may not be fully aware of track conditions.

Particularly tragic in this case is that a manual system was available, and the train operator wanted to use that system, but was prevented by the rules from doing so. Today's change at least reduces that risk.

Tom Comeau tcomeau@stsci.edu Space Telescope Science Institute

Electronic Medical Records and Images

Jay Brown <jay@asinc.com>
Wed, 7 Feb 1996 15:14:53 -0500

From Communications of the ACM, February 1996, Newstrack:

"Heart of the matter... The first film-less heart imaging system that stores its pictures of the human heart on CD-ROM disks has been built at the North Shore University Hospital in Manhasset, L.I., in collaboration with General Electric. The disks store full-motion pictures of cardiac catheterization tests, or angiograms, and within a year North Shore doctors hope to be transmitting medical records electronically between hospitals in its growing network, as well as to outside specialists. North Shore officials say the computerized records will save the hospital $12,000 a year on film, processing chemicals, and labor and storage in outside warehouses. "The advantage is in instantaneous retrieval of the images at a level of clarity that is better than a filmed angiogram," says the hospital's chief of cardiology."

One potential risk with this type of system would be the "configuration management" challenge - what image goes with what patient? As any sotware developer knows, keeping track of a lot of different files on disk, many of which have more than one version, is not a trivial task. While many solutions to this problem exist in the form of version control systems for source code and document management systems for large amounts of documentation, electronic medical records and images may introduce some new dimensions to this challenge, especially in a distributed environment. A system like the one described above must have the necessary facilities to help insure that the right images are associated with, and retrieved for, the right patient. In cases where the wrong image is retrieved, whether for diagnosis or to guide a procedure, the risks are, as they say, obvious. These types of problems can and do occur with the current "manual" procedures. The shift to electronic record keeping approaches must be accompanied by changes to the procedures used to prevent these kinds of situations, and will require a lot of electronic "support".

Jay Brown, Applied Systems Intelligence, jay@asinc.com

Risks of web robots

Joe A. Dellinger <jdellinger@amoco.com>
Sun, 4 Feb 96 20:50:03 CST

Here are three risks of "web robots" I've run across recently that I think Risks readers might find interesting.

  1. The first is probably already well known to Risks readers: password files accidentally being exported to the world. Web servers are just yet another way of making that mistake.

    Here is a post that has already had wide circulation (and may have already appeared in Risks... I'm unable to scan back issues to check right now because of heavy network load):

    >Subject: BoS: Misconfigured Web Servers
    >
    > A friend of mine showed me a nasty little "trick" over the weekend. He
    > went to a Web Search server (http://www.altavista.digital.com/) and
    > did a search on the following keywords -
    >
    > root: 0:0 sync: bin: daemon:
    >
    > You get the idea. He copied out several encrypted root passwords from
    > passwd files, launched CrackerJack and a 1/2 MB word file and had a
    > root password in under 30 minutes. All without accessing the site's
    > server, just the index on a web search server!
    >
    .... >
    > The guy that showed me this found it funny, but I find it disturbing.
    > Are there that many sites that are that poorly configured?
    >
    > Mark_W_Loveless@smtp.bnr.com

    I just verified that indeed this search does work, although to my relief the majority of the "hits" found are legitimate documents discussing UNIX security. The risks are fairly obvious.

    1. Here is a variation on the above risk that I HAVEN'T seen discussed before, however. See what happens if you search AltaVista for THESE keywords:

      "unpublished proprietary source code actual intended reserved copyright notice"

      The results of this search are even more frightening, at least to me.

      The general risk is not just that you can conveniently find password files, but ANY kind of document that shouldn't be widely distributed: material useful for breaking into your system, copyrighted material, illegal material, libelous material, incriminating or embarrassing material, etc...

  2. The second risk works the other way: fooling stupid web robots so
    as to lure people to your web site.

    A month ago I tried searching for "eisner reciprocity paradox" on WebCrawler, hoping to find that it had indexed a paper of mine that I had reprinted electronically under my home page. Nope, it hadn't (or at least I was unable to find it using any of the likely keywords I could think of!). Instead the single match was on a URL intriguingly entitled "The information source".

    Gee, this "information source" must have an article in it about Eisner's Reciprocity Paradox, one that I hadn't known of before! So I followed the link, and ended up at something unexpected: "http://www.graviton.com/red/", "The Red Herring Home Page"! (It comes complete with gifs of red fish!)

    A little experimentation revealed that almost ANY obscure search would match "The information source", often as the only matching document found. As near as I could figure out, his site recognized probes by web robots and then threw a dictionary at them! (His point made, he has since stopped, although the Red Herring page is still there for your perusal.)

    I contacted the author, Tom White, and asked for more details. He didn't want to give his secrets away, but did reply:

    > I will say that I spent no more than an hour on the whole thing, including
    > writing the page, and it was effective far beyond what I thought a silly
    > trick like that would muster. I think that by virtue of not hiding what
    > I am trying to do, people who write web indexers may see the page and think
    > of ways to subvert feeble attempts like mine - which is a good thing since
    > the page could have as easily been any propaganda I wanted to push on people.

    The risk? It can be frustratingly difficult (or impossible) to get a web robot's attention for a legitimate page you WANT indexed, or to find a page you know is there amist all the distractions of "false hits". Part of the clutter may be wildly off-topic pages engineered to fool web robots into thinking that almost anything matches them. (Or simply long rambling pages containing lots of poems and such... documents that "fool" the robots more by accident than design.)

  3. Finally, the act of being searched can cause problems for certain kinds
    of sites: ones that carry hundreds of thousands of distinct URLs, often generated only on demand, and that don't expect any one site to ever have reason to download ALL of them, whether all at once or a few at a time.

    See for example "http://xxx.lanl.gov/RobotsBeware.html". The authors state there: "This www server has been under all-too-frequent attack from `intelligent agents' (a.k.a. `robots') that mindlessly download every link encountered, ultimately trying to access the entire database through the listings links. In most cases, these processes are run by well-intentioned but thoughtless neophytes, ignorant of common sense guidelines."

    They have been forced to take a "proactive" stance to protect themselves: "We are not willing to play sitting duck to this nonsensical method of `indexing' information." The rather UNIQUE hot link that follows, "(Click here to initiate automated `seek-and-destroy' against your site.)", doesn't actually do anything but pause for 30 seconds, I'm told...

    I'll let readers examine the page and draw their own Risks!


Air Traffic Control Dependability

Jim Wolper <wolpjame@cwis.isu.edu>
2 Feb 1996 15:14:04 -0700

The US National Transportation Safety Board has released a report stating that the Air Traffic Control system is "very safe", although they do recommend more training in the use of backup features and making the features easier to use. This is according to an article in Aviation Week, 1/29/96. They characterised the backup modes as "inefficient".

RISKs contributors (and, presumably, readers) seem to jump on every incident involving aircraft as identifying a new RISK, and I guess I resent the implicit accusation that those of us in aviation (I work part-time as a pilot and flight instructor, although my "real" occupation is mathematics professor) have not identified any of these RISKS. In fact, the entire corpus of aviation regulatory and training materials exists to address and reduce RISK. I won't claim that we have thought of everything, but very little has escaped our notice. If a new RISK is uncovered, regulations and procedures change quickly (alas, sometimes regulations change for no good reason, but that is the RISK of a bureaucracy at work).

Jim Wolper Department of Mathematics Idaho State University Pocatello, ID 83209-8085 USA <http://math.isu.edu/~wolperj>

So many RISKS, where do you start?

Steve Doig <0005038929@mcimail.com>
Thu, 1 Feb 96 11:04 EST

This news item, seen on Dave Farber's "interesting people" list, suggests that RISKS folks still will have plenty to discuss in the coming century... Steve Doig

WASHINGTON (Reuter) - The Air Force Wednesday projected a dazzling array of new U.S. arms and space sensors for the 21st century, from pilotless hypersonic attack jets to microwaves that cripple enemy electronics. The possible high-tech weapons listed in a year-long study released by the service are so advanced that special training would be essential to make sure humans are not overwhelmed by science. ``The keyboard and the mouse are simply not adequate for the 21st Century,'' said Gene McCall of Los Alamos National Laboratory, chief of the Air Force Scientific Advisory Board. Air Force Secretary Sheila Widnall and McCall presented the 2,000-page study, telling a Pentagon press conference these and other systems could be built in 10 to 50 years:

``Let me assure you that this study is not going to sit on the shelf and gather dust. We have already set aside funding for some of these promising new areas of research,'' Widnall said. McCall said some space and communications systems could be ready within a decade but hypersonic aircraft and missiles that could maneuver sharply would be a major challenge. He also said machines must not outpace human ability to use them. ``What we have to make sure of is that people are the primary actors at the major points,'' he said, showing a video of a blinking pilot, concentrating to use brain waves to control maneuvers in a flight simulator.
McCall said the Air Force could advance ``stealth'' technology, allowing an aircraft to better avoid ground radar by making the underbelly completely smooth and putting the wheels on top — landing the plane in a flip maneuver.
``The pilots don't like that,'' he smiled. Laser-guided bombs used to defeat Iraq in the 1991 Gulf War were only the beginning, the report suggested. But it stressed that speed was the hallmark of the future. Aircraft and satellite sensors, cooperating in the future, will tell U.S. forces within one second when an anti-aircraft missile site anywhere in the world is activated, sending a hypersonic missile to attack the site from 200 miles away within a minute.
The board also suggested that high-tech research will produce non-lethal or ``sub-lethal'' microwaves that attack the enemy's information systems. ``You could produce impulses that, if you are attacked by an airplane, you could simply turn off all the warning lights in that airplane and send it home. Or, force the pilot to bail out,'' McCall told reporters.


CFP : Dependable Computing for Critical Applications

Catherine A. Meadows <meadows@itd.nrl.navy.mil>
Thu, 8 Feb 1996 15:22:58 -0500 (EST)
DCCA-6 Call for Papers
********************************************************************
Sixth IFIP International Working Conference on
Dependable Computing for Critical Applications

Can We Rely on Computers?
March 5-7, 1997 Garmisch-Partenkirchen, Germany ********************************************************************
Organized by IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance In cooperation with IFIP Technical Committee 11 on Security and Protection in Information Processing Systems IEEE Computer Society Technical Committee on Fault-Tolerant Computing EWICS Technical Committee 7 on Systems Reliability, Safety and Security
Computer systems are used to perform many critical tasks, including guiding aircraft, scheduling railroads, assisting in surgery, controlling nuclear reactors, performing financial transactions, military command and control, and a host of other applications. Properties that such a system must have can include availability, reliability, safety, and security. Although the study of these properties evolved as separate disciplines, they have in common the fact that a user must have a high degree of confidence in the service that the system delivers. The notion of dependability captures these concerns within a single conceptual framework, making it possible to approach the different requirements of a critical system in a unified way.
The sixth IFIP Working Conference on Dependable Computing for Critical Applications aims at bringing together researchers and developers from academia, industry, and government who are advancing the state-of-the-art in dependable computing. Papers are sought in all areas of dependable computing, including but not limited to models, methods, algorithms, tools and practical experience with specifying, designing, implementing, assessing, validating, operating, and maintaining dependable computing systems. Papers that deal with man-machine interface issues (as they relate to dependability) are specifically encouraged. Of particular but not exclusive interest will be presentations that address combinations of dependability attributes, e.g., safety and security, through studies of either a theoretical or an applied nature.
Garmisch-Partenkirchen lies at the foot of Germany's highest mountain, the Zugspitze. The Olympic town is a winter sports capital and favored destination for excursions and trips in Upper Bavaria.
Submitting a Paper: Six copies (in English) of original work, neither submitted nor accepted for publication elsewhere, should be submitted by September 3, 1996, to the Program co-Chair:
Prof. William H. Sanders University of Illinois Tel: 217 333 0345 CRHC - Coordinated Science Lab Fax: 217 244 3359 1308 West Main Street E-mail: whs@crhc.uiuc.edu Urbana, Illinois 61801 USA
Papers should be limited to 6000 words, full-page figures being counted as 300 words. Each paper should include a short abstract and a list of
keywords indicating subject classification. Papers will be refereed, and the final choice will be made by the Program Committee. Notification of acceptance will be sent by December 1, 1996, and camera-ready copy will be due on January 3, 1997.
* Important Dates: * * * * Submission deadline: 3 September 1996 * * Acceptance notification: 1 December 1996 * * Camera-ready copy due: 3 January 1997 *
General Chair Mario Dal Cin University of Erlangen, Germany
Program co-Chairs Cathy Meadows Naval Research Laboratory, USA
William H. Sanders University of Illinois at Urbana-Champaign, USA
Organization Chair W. Hohl University of Erlangen, Germany
Program Committee Jacob A. Abraham, U. of Texas at Austin, USA Algirdas A. Avizienis, UCLA, USA Pietro Carlo Cacciabue, EU Joint Research Ctr., Italy Alain Costes, LAAS-CNRS, France Flaviu Cristian, UCSD, USA Joanne Bechta Dugan, U. of Virgnia, USA Klaus Echtle, U. of Essen, Germany Bernhard Eschermann, ABB, Switzerland W. Kent Fuchs, U. of Illinois, USA Virgil D. Gligor, U. of Maryland, USA Li Gong, SRI International, USA Dick Hamlet, Portland State U., USA Erik Hollnagel, OECD Halden Reactor Proj., Norway Ravi Iyer, U. of Illinois, USA Karama Kanoun, LAAS-CNRS, France Carl E. Landwehr, Naval Res. Lab., USA Jean-Claude Laprie, LAAS-CNRS, France Bev Littlewood, City U. London, Great Britain Teresa Lunt, DARPA, USA Henrique Madeira, U. of Coimbra, Portugal John McLean, Naval Res. Lab., USA John F. Meyer, U. of Michigan, USA Michele Morganti, ITALTEL, Italy Brian Randell, U. of Newcastle, Great Britain John Rushby, SRI International, USA Rick Schlichting, U. of Arizona, USA Ernst Schmitter, Siemens AG, Germany Yoshi Tohma, Tokyo Denki U., Japan Kishor S. Trivedi, Duke U. USA Y.C. Bob Yeh, Boeing, USA
Ex Officio Hermann Kopetz, TU Vienna, Austria IFIP WG 10.4 Chair

Please report problems with the web pages to the maintainer

x
Top