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…
[from *Stars & Stripes*, 7 Dec 1996, a daily newspaper for military and such overseas. Excerpted by DWW.] A soldier is under investigation after allegedly transferring more than a half-million dollars into his checking account from his savings account. The problem was, it wasn't his money. On 29 Nov 1996, he unsuccessfully attempted to withdraw money from his overdrawn accounts. Then he conducted a transfer of 600,000.21 from his savings to his checking account at an ATM (banks were closed for the day after Thanksgiving). Because of a defect in the ATM computer system, the transfer was completed without verification of whether funds were available in the soldier's account. Over the next few days, the soldier was able to withdraw $300 in cash and deposited $30,005 into a newly opened credit union savings/money market account. On 2 Dec he attempted to wire $60,000.15 to California. Officials noticed the error and stopped the transaction. The soldier was apprehended, but has not been charged and is not in custody. A spokeswoman for the bank said the incident was the result of a one-time glitch in the bank's computer system. An anonymous customer service representative said there have been problems with the bank's computer accounting system since 8 Nov 1996 - the day the data from Bank A was converted to Bank B [the military awards banking contracts for a limited time. They have problems at every change-over, it seems.] "From that point on, we've just been trying to fix messes," the bank employee said, noting that the problems range from lost data to false duplication. [I wonder if the "uneven" amounts contributed to the mess, or if it was a foul-up in general. - dww] Debora Weber-Wulff Technische Fachhochschule Berlin, Luxemburger Str. 10, 13353 Berlin GERMANY weberwu@tfh-berlin.de <http://www.tfh-berlin.de/~weberwu/>
A Brooklyn federal jury awarded nearly $6 million to three women who had sustained arm, wrist, and hand injuries apparently resulting from use of a Digital LK201 keyboard: $5.3m to Patricia Gerassy, $306,000 to Jill Jackson, and $278,000 to Jeanette Rotolo. This is the first such case in which the computer manufacturer lost. Earlier cases involved Compaq and IBM. Digital will appeal. [Source: Diana B. Henriques in *The New York Times*, 10 Dec 1996, C1, also in *San Francisco Chronicle* same day, A1, PGN Abstracting.] [Many years ago my keyboard had a very rough touch that caused severe pain in the little finger of my left hand (the *emacs* finger). I had two foot pedals installed for the control and meta keys, and the problem went away. It also helped my organ-playing technique, speaking of manual systems. But, clearly it is good advice that you should not sit at your keyboard for long unbroken sessions. Unfortunately, I don't take my own advice enough.]
The latest (free) beta release for linux of the adobe acrobat .pdf reader
from adobe contains an interesting risk-enhancing feature, according to its
documentation.
from MapTypes.pdf:
If the file cannot be opened as a PDF file, the viewer
examines the UNIX file permissions. If the file can be executed by the
*********************************
user who launched Acrobat Reader or Exchange, the viewer attempts to
*******************************************************************
launch the file as an application. If the file cannot be launched as an
*********************************
application, the viewer returns an error message.
The risk - of death by execution - is obvious. I have to admit I haven't
had time to try it. I suspect I am the only person in some radius to have
time to read the documentation! I report this to you as I find it.
Peter T. Breuer, Universidad Carlos III de Madrid, Butarque 15, E-28911
Leganes SPAIN +34 1 624 9947 ptb@it.uc3m.es <http://www.it.uc3m.es/~ptb>
I've noticed increasingly that a lot of system administrators have placed an incredible reliance in "out of the box" security products (firewalls etc) . These products tend to provide a fair degree of auditing and it seems that quite a few administrators don't understand what it really all means. I get the impression that the response is a typical "Quick, call Chuck, we've got a situation down here!" every time a message is logged. (Why would these security products log messages if it wasn't a threat?) The first example is when a friend in Luxemburg e-mailed me saying that he had a new job and this was his e-mail address. He doesn't know too much about computers and asked me how I could chat to him. I asked if he was on a Unix machine, and if he had chat, we could use that. He said that he thought it was a Unix but wasn't sure - as a quick check I just telnetted quickly to his site and pressed ctrl-D as most machines tell what OS they are as a login message. The machine was TCP wrapped, but answered SunOS anyway. I guess I could have used another method to find out (nslookup etc) but this was quick & simple. It turns out that the machine was the helpdesk for a major bank of sorts - the connection spawned a return finger @mymachine - which answers for a group of local machines. It told them that five people were currently logged on to a bunch of local machines. The log should have been read as "You had a connection attempt on port 23 which was denied - it _may_ have come from any of these five users.." Apparently the bank admins freaked - supposedly they had forgotten the root password the day before and read the log as something like "you have five people simultaneously breaking in to your machine from a variety of places; machine1.au , machine2.au , ...". They admins freaked and ran around the bank looking for Australians working there. They then waved logs in their face and asked them if they knew any of these people - any why they would be using all these accounts trying to break in. My friend called frantically from Belgium at 1am in the morning and had to send me the log so I could explain what it meant. Sheesh. Another quick example comes from the fact I am the technical administrator for xxxx.com. We all know that spamming is on the rise - and it seems xxxx.com is an ideal choice as a fake source domain as it is a fairly generic sounding name. The risk is where admins who wish to stop the spamming then go ahead and bar or send complaints to postmaster@xxxx.com asking for the spamming to stop - when if anyone read the header properly would see it sure didn't come from the real xxxx.com. I've even had TOSEmail at AOL send complaints - aren't these guys meant to be experienced admins? Surely aol receives more than their fair share of spamming - these people should know what they're on about by now. I know places like cybervalue.net are having the same sort of problems. matt
The January 1997 issue of "Dr. Dobbs Journal" has an article in which the author reports that his software simulation of the automatic baggage handling system of the Denver airport mimicked the real-life situation. In his conclusion, he notes that the consultants did perform a similar simulation and had recommended against the installation of the system currently in place. The city, however, overruled the consultant's report (the contractors who were building the system never did see the report) and gave the go-ahead.
A field service engineer for a major computer company relates the following recent true story: One day, he was working in a government office, when the police arrived with a search warrant. They asked, "which desk does Mr. X work at ?". On being shown the desk, they proceeded to remove the Macintosh from the desk and took it away with them. Mr. X was not there to protest, having been incarcerated that morning on charges of forging identity papers using PageMaker, a Macintosh, and a high-quality color laser printer. As the police left, everyone burst out laughing, not least at the thought that almost all the tools Mr. X was using (software and data files stored on the server downstairs, networked printer in the next-door office) were still sitting in the office. I don't know if anything incriminating was ever found on "his" Macintosh; perhaps he'll be found guilty of nothing more serious than possession of an unlicensed copy of AfterDark. The RISKS? Well, apparently it's getting worthwhile (but not _perfectly_ so !) to forge official documents at work, on company time, using taxpayer-funded high-quality printing tools; and secondly, of course, law enforcement has a way to go in its understanding of how technology works, but then I think we might already have suspected that. Nick Brown, Strasbourg, France
In a piece entitled "Computer errors cause several plane crashes", Martin
Minow summarised in RISKS-18.65 an article from Aftonbladet suggesting the
above. There ensued a lengthy discussion between Martin, myself, and Danny
Kohn in Sweden, about the null-, whole-, or half-truth of most of the
assertions. Of the 11 assertional sentences contained in Martin's quote, I
found 10 of them misleading or false. Including, especially, the title. PGN
suggested I *briefly* summarise the discussion. Faint hope.
I would argue:
(a) against sensationalism and for precision;
(b) against the common habit of picking on one of many contributory causal
factors and calling it *the cause*;
(c) for a classification of problems into computer-per-se/requirements/HCI;
(d) against the assumption that even if computer behavior is directly
causally involved, the *type* of error must be a computer error
(I myself was disabused of this notion by Mary Shafer).
Martin would agree with me on (a) and (b), worries that the classification
proposed in (c) may lead one to miss some important aspects of system
failure, and is prepared to consider (d): he was struck by the similarity
many of the (pre-heavy-automation) accidents discussed by Perrow (`Normal
Accidents') bear to the (potentially computer-related) accidents we
discussed. Martin went to some trouble to distance himself from the views
expressed in the article.
Martin would also like to point out that he has absolutely no training or
competence in aircraft-safety and thus cannot judge the accuracy of the
article, but definitely distances himself from the sensationalistic
"death-trap" tone of the writing.
On the other hand, Danny thinks it is `fully correct', and cites Reason's
book on `Human Error'. He considered some military aviation accidents, such
as the two accidents with the Gripen fighter (I agree with the official
position that these were control-system design problems, not computer
problems per se). I also separate military aviation concerns from commercial
aviation. Two cheers for diversity, I guess. But just in case the gentle
reader doesn't believe in diversity, here's my view on journalistic
sloppiness.
The Aftonbladet article suggested that new-technology airplanes are
death-traps (the statistics actually show that they have a far better
accident rate per departure than older-technology airplanes or even
wide-bodies); claimed that `technicians and engineers' are the people who
test-fly the aircraft (patently absurd. In any case, pilots are very
involved in the cockpit design of all new transports); and also seemed to be
restricting its comments to the autopilot ("The critical point is when the
computer system should be disconnected" - you'd hardly want to disconnect
your control system, or your navigation information system, or your air data
system, even were it to be possible).
The article apparently cited four accidents to justify its claim: AA,
Cali 1995; Lauda Air, Thailand, 1991; Gottro"ra (SE), 1990; Svalbard
(SE) 1996. I consider these briefly. (Thanks to Martin for translations.
He warns they're a little dog-eared, but I don't think this affects my points.)
Cali: "The accident investigation concluded that the contact between the
pilot and computer system broke down [failed]."
None of the conclusions said any such thing. Readers may check the report
for themselves in `Computer-Related Incidents with Commercial Airplanes' at
http://www.rvs.uni-bielefeld.de
(This is not to deny the serious HCI issues that arose.)
Bangkok: "A computer error that caused one of the plane's engines to
reverse could have caused the accident, concluded the investigation."
It is not possible for a `computer error' alone to cause an in-flight thrust
reverse on a B767. As I understand it, there is a hydraulic interlock which
prevents this. It was determined in tests that there exists a failure mode
of this interlock on high-time engines. No potential explanation other than
(interlock failure *plus* pilot-uncommanded in-flight thrust-reverse
request) has been found. No probable cause was determined.
Gottro"ra: "Both motors broke up. One of the better supported
theories about the cause was problems in the computer system. The
throttle [?] in one of the motors stopped working. The computer
ran the other motor at full power and destroyed it completely."
It is my understanding that no probable cause was determined. Danny pointed
out that this is a hot example amongst pilots in Sweden at the
moment. However, I would caution against `theory' which supposes computers
are the modern form of gremlins. A synopsis of a PhD thesis on this accident
may be found at
http://info.admin.kth.se/info/pressmeddelanden/1995/0517-1.html
This Swedish press-release was an invitation to Dr. Martensson's
doctoral thesis defense.
Svalbard: "[..] a Russian passenger plane flew straight into a mountain
[..] The accident cause is unclear, but there is a suspicion
that the computer system broke."
They said it themselves: the cause is unclear.
Does anyone actually know of *any* accident to a commercial airplane
in which some sort of `computer error' is cited as the probable cause?
Example and direct quotes, please. Caveat: `probable cause' and
`contributing factor' are semi-technical terms.
Peter Ladkin
There are two small errors that should be corrected in my item in RISKS-18.65: 1. The correct URL for the Aftonbladet article is http://www.aftonbladet.se/nyheter/dec/06/flyg.html "aftonbladed" -> "aftonbladet" . As always, note that newspaper archives may not be kept for a long time. 2. The article title, "Computer errors cause several plane crashes" would be better translated as "computer errors a cause of several plane crashes." My translation made a sensationalistic Swedish article rather more sensationalistic than necessary. There is an important "risk" here — that technically sophisticated readers should avoid giving excessive weight to specific terms appearing in the popular press. Journalists often use "terms of art" without the precision and accuracy expected of scientific writing. In this case, readers must also understand that terms are translated from English to Swedish to popular-press Swedish and back to English, and have probably lost much of the subtlety and gradation of the original. Martin Minow, minow@apple.com
Mitch Kabay quotes Reuters quoting Michael Bagshaw, head of aviation medical services at British Airways, in an address to the Royal Society: > "If we examine the accident rate by type of aircraft, it > can be seen that although the overall trend is down ... new > highly-automated types have a relatively higher accident rate." Such statements need careful qualification. Boeing produces a statistical report on worldwide aviation accidents each year, from 1959-[present year]. My 1995 copy (courtesy of Pete Mellor) divides fatal accidents worldwide into three classes: Second generation (B727, Trident, VC-10, BAC 111, DC9, B737-100/200, F28), Widebody (B747-100/200/300, DC10, L1011, A300), and `New' (MD80/90, MD11, B737-300/400/500, B747-400, B757, B767, B777, A300-600, A310, A320/A321, A330, A340, BAe146, F100). The annual rate of fatal accidents per million departures since 1983 is in all years lower than that of either second-generation or widebodies, except for 1988, 1994 and 1995, when widebodies had 0 and new types non-zero rates. The new types are all `glass cockpit' aircraft of the sort to which Dr. Bagshaw's comments are relevant. So what can Dr. Bagshaw's comment as reported by Reuters be referring to? Maybe a different measurement. One that may seem prima facie reasonable is passenger deaths per passenger-mile. However, this measurement can be misleading, because 91.2% of fatal accidents occur in the takeoff or landing phases of flight, and only 8.2% in cruise. The widebodies spend most of their miles in cruise, and the new types are mostly short-haul aircraft which may only spend an hour to two hours in flight - similar to the second generation, whose accident statistics overall are worse. The different characteristics of airplane use could be reflected in the standard deviation: the figures, rounded to whole numbers, for widebodies from 85-95 are 1, 0, 1, 0, 3, 1, 2, 5, 1, 0, 0. Those for new types, rounded, are 0, 0, then all 1's. Those for second generation are 1, 1, 1, then higher than new's but less than 2, except for 94 (2). But these statistics do not reflect the vast differences in `safety cultures' across the world's airlines. These differences can be large enough that the US prohibits aircraft operated by airlines in certain countries from flying into the US - and this system may be extended to Europe. So, on these measures, the `new technology' aircraft seem to be safer overall than other types. Dr. Bagshaw's measurements lead him to a different conclusion. The moral is: beware of facile quotation of statistics. Dr. Bagshaw's comments on human factors are pertinent, and in fact justifiable independently of statistics. His comments focus on the cognitive capabilities of pilots, as `information processors'. Such a view lies behind much current research in aviation human factors. And there have been some recent accidents which have focused attention on the pilot's awareness of the system state and its proper functioning: A320, Bangalore 1990; A320, Warsaw 1993; A300-600, Nagoya 1994; B757, Cali 1995; B757, Puerto Plata 1996. The reason for this attention is that these new systems allow failure modes (such as pilot's faulty awareness of system state) that simply didn't exist in older aircraft. Thus we need to pay attention to these problems and solve them, no matter what comparative accident rates are. Solving such problems will, of course, affect accident rates, no matter how measured. Airline accident rates (pick your measure) are the lowest in history, but they do not appear to be going down. To bring this down, it is reasonable to suppose that research and new techniques will be needed. And since nearly 60% of fatal accidents worldwide are primarily due to flightcrew behavior (Boeing again, 1985-95), human factors issues must form a major part of this program. There are two aspects to this: establishing expectations of flight crew; and ensuring these expectations are met. The first is the focus of Dr. Bagshaw's comments: what can we reasonably expect from flight crew? The second is the business of appropriate and thorough training (that `safety culture' again). To summarise: it is appropriate, and appears to be necessary, to focus on human factors to reduce the rate of airline accidents (however measured). Recent accidents with `new technology' have uncovered human factors issues that could not arise with older-generation aircraft. These new issues must therefore be addressed. However, I am not aware that accident rates as currently measured and analysed enable us to judge whether `new technology' aircraft are inherently `safer' or `less safe' than either second-generation or widebody aircraft (in Boeing's classification). They're `differently safe'. Peter Ladkin
Why didn't the original sign state "Emergency Power Shutoff"? Who would casually press a button so labeled, especially in the offices of a "Major Computer Company." Instead of being a bunch of dumb sheep, let's think about this situation. (There's a lot of computer hardware and software which commits the same sin, after all.) _Why_ would "MCC" leave that switch in place, since it has obviously caused them much grief in the past? The answer, of course, is it's an important piece of safety equipment. Computer rooms need emergency power shutoffs, and for those shutoffs to be useful in an emergency they can't be in the computer room itself. As I vaguely recall building codes won't even allow them in the doorway of the computer room; there has to be at least a doorway between the cutoff switch and the heavy electrical wiring. Yet this important piece of safety equipment is effectively useless (and actually slightly harmful) since someone posted a paternalistic "do not touch" sign instead of posting a sign explaining the purpose of the switch. It would be too much to suggest that we have a professional duty to press every unlabeled red button we encounter, but the problem in this auditorium isn't the emergency power cutoff switch or the hard-to-find screen controls. It's the paternalistic author who thinks most people can't be trusted to know not to touch the cut-off switch if they know what it is — and that they can't be trusted to know when it _is_ important to use it. Bear Giles bear@indra.com
This is not a computer risk; it is the even more common human risk of people who seem to think that signs, lights, guide ropes, barricades, etc., apply to everyone but them. There is no way to design around such attitudes other than removing all potentially dangerous articles from their reach. Like child-proofing. :-) -harlan [As I have noted in the past, our forum deals with COMPUTER-RELATED RISKS (not coincidentally, the title of my book). Unfortunately, a lot of events that seem not to be computer risks are computer-related risks. When your computer wipes out, for whatever reason, that is certainly relevant here. People-tolerant systems is still a good research area. PGN]
Fourth ACM Conference on Computer and Communications Security
(Preliminary Technical Program, Abridged for RISKS)
Zurich, Switzerland
1-4 April 1997
Sponsored by ACM SIGSAC
For more information, including registration and hotel information,
see: http://www.zurich.ibm.ch/pub/Other/ACMsec/index.html .
TUESDAY, 1 APRIL
4 half-day tutorials in two parallel tracks:
Theory Track Practice Track
Morning Cryptography CERT and Practical Network Security
Jim Massey, Ueli Maurer Tom Longstaff
(ETH Zurich) (Software Engineering Institute)
Afternoon Internet Security Info-Wars
Refik Molva Paul Karger
(Eurecom) (IBM TJ Watson)
WEDNESDAY, 2 APRIL
09:00-09:30 Introduction and Opening Comments
Richard Graveman (Bellcore)
Phil Janson (IBM Zurich Lab)
Li Gong (JavaSoft)
Clifford Neuman (Univ. of Southern California)
09:30-10:30 Invited talk 1: To Be Announced
10:30-11:00 Coffee Break
11:00-12:00 Session 1: Fair Exchange of Information
* Fair Exchange with a Semi-Trusted Third Party
Matthew Franklin, Mike Reiter (AT&T Research)
* Optimistic Protocols for Fair Exchange
N. Asokan, Matthias Schunter, Michael Waidner
(IBM Zurich Lab and Univ. Dortmund)
14:00-15:30 Session 2: Language and System Security
* Static Typing with Dynamic Linking
Drew Dean (Princeton University)
* Secure Digital Names
Scott Stornetta, Stuart Haber (Surety Technologies)
* A Calculus for Cryptographic Protocols: The Spi Calculus
Martin Abadi, Andrew D. Gordon (DEC SRC and Cambridge)
16:00-17:30 Panel 1: Programming Languages as a Basis for Security
Chair: Drew Dean (Princeton), Panelists: To Be Announced
THURSDAY, 3 APRIL
09:00-10:30 Session 3: Authentication
* Authentication via Keystroke Dynamics
Fabian Monrose, Avi Rubin (New York Univ. and Bellcore)
* Path Independence for Authentication in Large-Scale Systems
Mike Reiter, Stuart Stubblebine (AT&T Research)
* Proactive Password Checking with Decision Trees
Francesco Bergadano, Bruno Crispo, Giancarlo Ruffo (Univ. of Turin)
11:00-12:00 Invited talk 2: To Be Announced
14:00-15:30 Session 4: Signatures and Escrow
* Verifiable Partial Key Escrow
Mihir Bellare, Shafi Goldwasser (UC San Diego and MIT)
* New Blind Signatures Equivalent to Factorisation
David Pointcheval, Jacques Stern (ENS/DMI, France)
* Proactive Public-Key and Signature Schemes
Markus Jakobsson, Stanislaw Jarecki, Amir Herzberg,
Hugo Krawczyk, Moti Yung (IBM TJ Watson and Bankers Trust)
15:30-16:00 Coffee Break
16:00-17:30 Panel 2: Persistence and Longevity of Digital Signatures
Chair: Gene Tsudik (USC/ISI), Panelists: To Be Announced
Banquet Dinner
FRIDAY, 4 APRIL
09:00-10:30 Session 6: Commerce and Commercial Security
* A New On-Line Cash Check Scheme
Robert H. Deng, Yongfei Han, Albert B. Jeng,
Teow-Hin Ngair (National University of Singapore)
* Conditional Purchase Orders
John Kelsey, Bruce Schneier (Counterpane Systems)
* The Specification and Implementation of 'Commercial' Security
Requirements including Dynamic Segregation of Duties
Simon Foley (University College, Cork, Ireland)
11:00-12:30 Session 5: Cryptography
* On the Importance of Securing Your Bins: The Garbage-Man-in-the-Middle Attack
Marc Joye, Jean-Jacques Quisquater (Univ. Louvain)
* Improved Security Bounds for Pseudorandom Permutations
Jacques Patarin (Bull)
* Asymmetric Fingerprinting for Larger Collusions
Birgit Pfitzmann, Michael Waidner (Univ. Hildesheim and IBM Zurich Lab)
Please report problems with the web pages to the maintainer