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 <[email protected]>
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" <[email protected]>
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
[email protected] (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, [email protected], 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" <[email protected]>
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: [email protected]
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" <[email protected]>
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" <[email protected]>
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" <[email protected]>
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 <[email protected]>
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
[email protected]  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 <[email protected]>
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 [email protected]
%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 [email protected]
%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 <[email protected]>
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: [email protected]
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 <[email protected]> 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 <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> 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 [email protected] 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
************************