Text File

precedence: bulk Subject: Risks Digest 20.04

RISKS-LIST: Risks-Forum Digest Weds 21 October 1998 Volume 20 : Issue 04

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at http://catless.ncl.ac.uk/Risks/20.04.html and at ftp.sri.com/risks/ .

Contents: The risks of elbows on the French futures exchange (Steve Bellovin) Electromagnetic interference on defense systems (PGN) Wrong result in German Bundestag elections due to FAX machine (Harald Kucharek) Emissions software glitch fails hundreds of older cars in Atlanta (J Quinby) Another wild bank saga, from England (PGN) AOL bytes the dest (PGN) SRI voice-mail woes (PGN) Re: Risks of installing Microsoft's Media Player (Michael F. Hogsett) Software dictates names (Ruth Milner) REVIEW: "Personal Encryption Clearly Explained", Pete Loshin (Rob Slade) Dependable Computing for Critical Applications: CFP (Chuck Weinstock) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 16 Oct 1998 09:10:22 -0400 From: Steve Bellovin <smb@research.att.com> Subject: The risks of elbows on the French futures exchange

It turns out that elbows and computer keyboards don't get along. No, I'm not talking about RSI problems; rather, I'm talking about what can happen when an errant elbow hits a too-powerful key...

According to the 16 Oct *Wall Street Journal*, a trader at a French futures exchange accidentally leaned on his keyboard. Without realizing it, he placed an order to sell 14,500 government bond contracts, which caused the price to drop. His firm ended up losing several million dollars.

[I received reports on this from many of you, with 145 separate sell orders resulting from the trader leaning on the "Instant Sell" key. Of course, in that "elbow" in French is "coude" (pronounced monosyllabically as "cooed"), it is clear that the futures exchange was "couped" (also pronounced cooed), the victim of a coude coup! Next it will be a little bird instead of an elbow, and we'll watch out for the "cuckoo coup". TNX. PGN]

------------------------------

Date: Tue, 27 Oct 1998 13:12:09 -0400 From: "Peter G. Neumann" <Neumann@CSL.sri.com> Subject: Electromagnetic interference on defense systems

Patriot defenses and Predator unmanned aerial vehicles reportedly cannot work properly in certain foreign countries (Germany, Japan, South Korea and Bahrain are particular instances) because of frequency clashes. For example, Patriot missile system radios, radars, and data-link terminals clash with Korean cellular phones; U.S. force pages clash with Japanese aeronautical systems; crib monitors used on U.S. bases clash with German telephone service. In Bahrain, SPS-40 and SPS-49 radars are unusable because of interference from the national telecommunications services. (See the *Defense Week* issue that came out on 26 October 1998. Thanks to pwalczak@emh3.arl.mil (Paul Walczak) for pointing out this article.

[Also see http://www.cnn.com/US/9810/17/pentagon.waves.ap/ "At least 89 telecommunications systems ... were deployed within the European, Pacific and Southwest Asian theaters without the proper frequency certification and host-nation approval." as noted by Roy Rodenstein, royrod@media.mit.edu, who reminds us of the HDTV interference with Baylor hospital equipment (RISKS-19.62), and points out that quasi-ad-hoc spectrum use must be stemmed in the light of ever increasing uses of the spectrum.]

[For background, see my Illustrative Risks compendium, which now provides an explicit descriptor (M) for the many cases of interference included therein: http://www.csl.sri.com/~neumann/illustrative.ps or .pdf ... PGN]

------------------------------

Date: Wed, 14 Oct 1998 17:54:02 +0100 From: "Harald Kucharek" <harald.kucharek@realax.com> Subject: Wrong result in German Bundestag elections due to FAX machine

The result of the elections to the German Bundestag has to be changed two weeks after the elections. The liberal FDP will loose one seat, the PDS will gain one. In the federal country of Brandenburg, the results were printed out double sided and then faxed to Bonn without taking into account that a fax only sends one side of a page.

------------------------------

Date: Mon, 19 Oct 1998 17:26:39 -0400 From: jquinby@s1.com Subject: Emissions software glitch fails hundreds of older cars in Atlanta

Due to a software glitch, hundreds of older cars in metropolitan Atlanta have failed emissions tests they should have passed. The state Environmental Protection Division allowed testing stations to keep flunking cars, even after EPD knew that the software thresholds in the ESP systems were a factor of two too low. [Source: the Georgia News section of Yahoo's News areas on 16 Oct 1998, and in the *Atlanta Journal and Constitution*, http://dailynews.yahoo.com/headlines/local/state/georgia/story.html?s=v/rs/ 19981016/ga/index_2.html#1 . PGN Abstracting]

------------------------------

Date: Wed, 14 Oct 1998 16:06:56 -0700 From: "Peter G. Neumann" <Neumann@CSL.sri.com> Subject: Another wild bank saga, from England

British Aerobics instructor Liz Seymour thought she might have overdrawn her bank account when she returned from vacation, but her bank statement claimed she was 121 billion pounds (British) overdrawn. That's 121 trillion pounds by American counting, because the British billion is a million million. The bank also notified her she would be charged 2.5 (British) billion pounds per day in interest. When questioned, the bank chalked it up to a typing error. [Source: 14 Oct 1998, *Yorkshire Evening Press*]

[FOLLOW-UP CORRECTION in RISKS-20.05. British Billion now US also. PGN]

------------------------------

Date: Mon, 19 Oct 1998 08:28:58 EDT From: PGN Subject: AOL bytes the dest

Someone masquerading as an AOL official sent e-mail to Network Solutions Inc. to change the aol.com domain-name entry on 16 Oct 1998. This request took effect automatically, because AOL was using lowest-level security (presumably not requiring manual intervention). As a result, AOL was effectively off the Net for incoming e-mail and Web use for about 12 hours. [Source: Bloomberg News, 17 Oct 1998]

------------------------------

Date: Mon, 19 Oct 1998 10:14:35 -0700 (PDT) From: "Peter G. Neumann" <Neumann@CSL.sri.com> Subject: SRI voice-mail woes

I was away the past two weeks (although I did manage to put out one issue of RISKS on the fly). However, SRI's voice-mail system was not operational for something like five days last week. This is tough on incoming callers, but even tougher on travelers like me who try to keep in touch. The problem initially was attributed to bad sectors on one of the four hard drives. Further diagnostics identified a possible fault in the link between the PBX and voice-mail. The absence of both voice-mail and call-forwarding certainly makes life tough.

------------------------------

Date: Tue, 20 Oct 1998 16:32:08 -0700 From: "Michael F. Hogsett" <hogsett@csl.sri.com> Subject: Re: Risks of installing Microsoft's Media Player (Love, RISKS-20.03)

The thing that I find interesting here is that Apple addressed this kind of issue back in the mid 80's on the Macintosh. Each file has a four-letter creator (application) code and a four-letter file-type code. This allows multiple applications to be associated with the same file-type, since the Mac uses both to determine which application to load when the file is double-clicked as well as which icon to display in the gui for this file.

The creator and file-type codes are not limited to only letters. They can be nearly any character, essentially they are both simply 32-bit values. This allows for quite a few more file-types (and creators) than are allowed with the DOS/Windows 3-letter file types.

Michael F. Hogsett

[And software librarians will note that MS also subscribes to the GUI Guessimal System. PGN]

------------------------------

Date: Tue, 20 Oct 1998 11:44:03 -0600 (MDT) From: Ruth Milner <rmilner@aoc.nrao.edu> Subject: Software dictates names

Late last year, when I renewed my license, I learned that the New Mexico Motor Vehicles Division had gone to a new computer system. How did I find out? They issued my license in the name of "MRUTH MILNER".

I'm among the significant minority of people who use their given names in some way other than first-name-middle-initial. During a lengthy (and quite reasonable) discussion with someone fairly high up in the MVD, I learned that the states are under some federal mandate to make their driver databases interoperate. This is a very sensible thing to do, but in order to simplify the effort, they have apparently put some rather simpleminded restrictions on the name formats that are allowed.

1. Initial(s) and last name. 2. First name, last name. 3. First name, middle initial, last name.

In June we received a refund check from the state taxation department, with the same erroneous form of my name. I was prepared to put up with it for a driver's license, but taxation is another story altogether. I wrote a letter to the department at the time, and today I heard back from them.

It seems that the taxation department has moved to the same computer system. The person I spoke with said that the old system was removed and the new one brought into production December 15 of last year, with no overlap period and no preliminary real-life testing, and they have been reporting problems with it ever since (surprise!). This is just one more. She is passing it on to the section head to bring up at the weekly meeting with the systems people. Given that this package is used in more departments than theirs, though, a change will probably not be trivial.

In addition to rejecting all but the forms shown above, the system does not accept embedded blanks (e.g. "Mary Ann"), periods, or even hyphens (!) in names. Worse, it cannot take both given names in full - i.e. the legal name that appears on one's birth certificate, passport, SS card, etc. (Although I didn't ask, I strongly suspect that it will not accept multiple middle initials, either.)

This strikes me as more than just an issue of people being forced to fit within unnecessary software limitations. By restricting the forms of names, they increase the chance of namespace collisions (especially on driver's licenses, where the name is often the only common key across states). Since the IRS doesn't appear to have this problem, there will be mismatches in the combination of SSN+name in the state and federal tax records. This could potentially make it harder to identify phony SSN numbers and bad duplicates. And it will add to the opinion held by many people that "computers" are dictating their lives, when in fact it's the people specifying and designing the software who are doing that.

If anyone has any more information about this database project, I would be very interested in hearing it.

M. Ruth Milner, Assistant to the Director -- Computing, NRAO, Socorro NM rmilner@nrao.edu 1-505-835-7282 FAX 505-835-7027

[This is an OLD tale in RISKS, but worth repeating, because it does not seem to go away. PGN]

------------------------------

Date: Wed, 21 Oct 1998 09:55:17 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Personal Encryption Clearly Explained", Pete Loshin

BKPERENC.RVW 980726

"Personal Encryption Clearly Explained", Pete Loshin, 1998, 0-12-455837-2, U$39.95/C$55.95 %A Pete Loshin pete@loshin.com %C 525 B Street, Suite 1900, San Diego, CA 92101-4495 %D 1998 %G 0-12-455837-2 %I Academic Press/Academic Press Professional/Harcourt Brace %O U$39.95/C$55.95 800-321-5068 fax: 619-699-6380 app@acad.com %P 545 p. %T "Personal Encryption Clearly Explained"

I am getting just a little tired of the car analogy. "You don't need to be a mechanic," so the metaphor goes, "to drive a car. Therefore, you don't need to know anything about the theory behind [encryption|networking|programming|etc.] in order to use a computer." This comparison ignores two important points. One is that in 1912 you *did* need to be a fair mechanic to operate a car effectively, and that is roughly where we are with regard to the development of the computer. The second point is that while computer programs are generally easy enough for a novice to use once they have been set up, the choice, evaluation, and configuration of systems requires much more background. Particularly in the field of encryption, in recent times "experts" have been recommending systems for which the time needed to crack keys has fallen to literally hours.

This book purports to give you everything that you need in order to both use and understand encryption, specifically with regard to digital signatures. While the text does provide some limited conceptual education and a little vicarious experience with a handful of commercial products it cannot be said to deliver on its promise.

Chapter one is a bit hard to define. It seems to start out as a sales pitch, trying to convince the reader that encryption is important. However, it also looks at the scope of privacy and threats thereto, and even starts to develop the background for encryption technologies. The quality is highly uneven. A discussion of security versus usability is excellent and notes that the convenience of modern personal networking systems pose tremendous security vulnerabilities. On the other hand, the introduction to information risks cites only computer criminals, without considering the possibility of transmission of sensitive information to unauthorized recipients through human errors or system failures. A review of types of data that should be secured fails to note that encrypting some files and messages while leaving others accessible can, in and of itself, provide assistance to the enemy. The material on security technologies and specific threats is fairly mundane.

A primer on encryption is presented in chapter two, although it is, as is all to usual, more of a history than a real explanation. Modern computer encryption is less than half of the chapter, and most of that space is dedicated to describing different applications rather than technologies. Appendix A should probably be considered as an extension of the discussion, and does provide a first rate explanation of the mathematical underpinnings to modern public-key encryption, but ends just as we get to the good bit. Neither the chapter nor the appendix gives the necessary preparation for assessing cryptographic strength.

Chapter three is a balanced but relatively superficial examination of the debate surrounding the US government's attempts to restrict the availability and use of encryption. The discussion of encryption implementation in chapter four touches on a wide range of issues, but none in any depth. A number of disparate products are briefly described (and the "installation" of two is presented in some detail), but the foundation for evaluation still has not been provided in chapter five. Chapter six looks at a number of security topics and features related to the Netscape Navigator browser, but not all relate to encryption, and encryption related topics are passed over quite quickly. There is, for example, no discussion of the ramifications of dealing with either "export" copies of Netscape products, or non-US Web servers, both of which may be restricted in the cryptographic keys they can deal with. Operational, but not functional, specifics of three e-mail products with cryptographic capabilities are detailed in chapter seven. Similar information is given for some file encryption products in chapter eight.

Chapter nine's explanation of digital commerce is simplistic and surprisingly abrupt. The review of key management in the Network Associates PGP product should be viewed together with the material in chapters five and eight (and even then isn't really complete) but additional content does begin to address some of the conceptual issues in chapter ten.

This is yet another example of a book that tries to explain encryption to a non-technical audience but seems to feel that a full background is not needed. Loshin does a better job than some other authors with the inclusion of Appendix A, but fails to provide either the explanation of function or the demonstration of relative strength that Garfinkel manifested in "PGP: Pretty Good Privacy" (cf. BKPGPGAR.RVW). Unfortunately this current work is neither clear not complete enough to be recommended for any particular audience.

copyright Robert M. Slade, 1998 BKPERENC.RVW 980726

------------------------------

Date: Tue, 20 Oct 1998 11:51:49 -0400 From: Chuck Weinstock <weinstock@sei.cmu.edu> Subject: Dependable Computing for Critical Applications: CFP

CALL FOR PARTICIPATION Seventh IFIP International Working Conference on Dependable Computing for Critical Applications (DCCA-7) The Fairmont Hotel San Jose, California, USA January 6-8, 1999

[See <http://www.conjelco.com/dcca/> for the full Call for Participation. This item is abridged for RISKS. PGN]

This is the seventh conference in a series dedicated to advancing the theory and practice of dependable computing for critical applications. DCCA differs from other conferences on related topics in encouraging participation across all fields that contribute to dependable computing, and in its format as a working conference that provides ample time for discussion; these attributes provide for a stimulating meeting that facilitates cross-fertilization of ideas and interaction between researchers and practitioners.

General Chair: Charles B. Weinstock, Software Engineering Institute, USA Program Chair: John Rushby, SRI International, USA

PRELIMINARY CONFERENCE SCHEDULE (tentative)

Wednesday January 6, 1999

9 am: Assessment of COTS Components There is increasing pressure to use COTS (commercial off-the-shelf) components in critical systems. How dependable are these components? These two papers respectively examine design faults in a commercial processor (Pentium II), and the reliability of a commercial microkernel (Chorus ClassiX).

* The Taxonomy of Design Faults in COTS Microprocessors by Algirdas Avizienis and Yutao He of UCLA, USA * Assessment of COTS Microkernels by Fault Injection by J.-C. Fabre, F. Salles, M. Rodriguez-Moreno, and J. Arlat of LAAS, France

11am: Coping with COTS These two papers respectively describe how to construct a reliable spacecraft controller and fault-tolerant clocks from COTS components.

* Minimalist Recovery Techniques for Single Event Effects in Spaceborne Microcontrollers by Douglas W. Caldwell and David A. Rennels of UCLA, USA

* Building Fault-Tolerant Hardware Clocks from COTS Components by Christof Fetzer and Flaviu Cristian of UCSD, USA

2pm: Formal Methods Formal methods can help develop verified systems, and can also be used to examine requirements and designs for bugs. The first of these papers uses theorem proving to develop verified controllers, while the other two use model checking in the validation of complex requirements.

* A methodology for proving control systems with Lustre and PVS by S. Bensalem, P. Caspi, C. Parent-Vigouroux, and C. Dumas, D. Pilaud, VERIMAG, France * Prototyping and Formal Requirement Validation of GPRS: A Mobile Data Packet Radio Service for GSM by Luigi Logrippo, Laurent Andriantsiferana, and Brahim Ghribi of University of Ottawa, Canada * Formal Description and Validation for an Integrity Policy Supporting Multiple Levels of Criticality by A. Fantechi, S. Gnesi, and L. Semini of Universitý di Firenze, Italy

4:30pm: Distributed Systems The first of these papers develops an infrastructure for fault-tolerance on top of CORBA; the second considers how to improve performance of one of the protocols used in such infrastructures.

* Proteus: A Flexible Infrastructure to Implement Adaptive Fault Tolerance in AQuA by Chetan Sabnis, Michel Cukier, Jennifer Ren, William H. Sanders, David E. Bakken, and David Karr of University of Illinois and BBN, USA * Improving Performance of Atomic Broadcast Protocols Using the Newsmonger Technique by Shivakant Mishra and Sudha M. Kuntur of University of Wyoming, USA

Thursday January 7, 1999

9am: Time-Triggered Architecture The time-triggered architecture (TTA) provides a robust foundation for critical control applications such as drive-by-wire. The first paper describes how fault-tolerant applications can be supported in this architecture, while the second describes formal verification of the clock-synchronization protocol used in TTA.

* The Transparent Implementation of Fault Tolerance in the Time-Triggered Architecture by Hermann Kopetz and Dietmar Millinger of TU Vienna, Austria * Formal Verification for Time-Triggered Clock Synchronization by Holger Pfeifer, Detlef Schwier, and Friedrich W. von Henke of University of Ulm, Germany

11am: Fault Tolerance and Safety The redundancy added to provide fault tolerance can introduce new failure modes that may compromise safety. The first paper describes such a situation and presents a protocol that overcomes it. The second paper describes validation of fault tolerant systems by fault injection.

* PADRE: A Protocol For Asymmetric Duplex Redundancy by Didier Essame, Jean Arlat, and David Powell of LAAS, France * Experimental Validation of High-Speed Fault-Tolerant Systems Using Physical Fault Injection by R. J. MartÌnez, P. J. Gil, G. MartÌn, C. PÈrez, and J.J. Serrano of the University and Politecnica of Valencia, Spain

2pm: Models of Partitioning for Integrated Modular Avionics Integrated Modular Avionics (IMA) bring together several airplane control functions that were previously performed by separate computer systems. This creates new opportunities for fault propagation that must be eliminated by partitioning. But what exactly are the requirements for safe partitioning? These three papers attempt to answer this question using models that have their roots in computer security.

* A Model of Cooperative Noninterference for Integrated Modular Avionics by Ben L. Di Vito of ViGYAN/NASA Langley, USA * Invariant Performance: A Statement of Task Isolation Useful for Embedded Application Integration by Matthew M. Wilding, David S. Hardin, and David A. Greve of Collins Commercial Avionics, USA * A Model of Non-Interference for Integrating Mixed-Criticality Software Components by Bruno Dutertre and Victoria Stavridou of SRI International, USA

Dependability Evaluation For some, dependability is closely related to reliability; for others, it is a more complex mix of properties. The first paper applies classical reliability modeling to phased missions, while the second proposes a method for evaluating a system against multiple criteria.

* Dependability Modeling and Evaluation of Phased Mission Systems: a DSPN Approach by Ivan Mura, Andrea Bondavalli, Xinyu Zang, and Kishor Trivedi of University of Pisa and CNUCE/CNR, Italy, and Duke University, USA * Dependability Evaluation using a Multi-Criteria Decision Analysis Procedure by Divya Prasad and John McDermid of the University of York, UK

Friday January 7, 1999

9am: Panel: Certification and Assessment of Critical Systems It is difficult or impossible to measure some important attributes of critical systems (e.g., experimental quantification of failure rates in the 10-9 range is infeasible). Therefore, many of the standards for critical software development (e.g., DO-178B, IEC1508, the Common Security Criteria) focus on the development process: "we cannot measure how well you did, so we measure how hard you tried." Some criticise these standards for having requirements whose compliance cannot be objectively determined, or for requiring use of techniques whose efficacy has not been established. Others note that multiple sources of evidence are required in assessing a critical systems, and ask how best to combine these different sources.

This panel will comprise experts representing a range of opinion who will examine the topic of certification and assessment of critical systems from several perspectives.

11:30am: Probabilistic Guarantees The first paper considers scheduling in the presence of faults, while the second considers detection of faulty components. Both papers employ statistical methods.

* Probabilistic Scheduling Guarantees for Fault-Tolerant Real-Time Systems by A. Burns, S. Punnekkat, L. Strigini and D. R. Wright of the University of York and City University, UK * Fault Detection for Byzantine Quorum Systems by Evelyn Pierce, Lorenzo Alvisi, Dahlia Malkhi, and Michael Reiter of University of Texas at Austin, and Bell Laboratories, USA

1 pm Adjourn

------------------------------

Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.04 ************************