The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 18 Issue 3

Wednesday 10 April 1996

Contents

o Intel shutdown by power company software bug
Bruce E. Wampler
o Daylight Savings Time problem
Bruce E. Wampler
o Re: De facto Daylight Savings
Dik T. Winter
o Don't go it alone -- the Risks of poor design decisions
Russ Broomell
o Warning! My [...] let me [dangerous/confidence-breaking act]
Rob Bailey
o Signing binaries
Bennet Yee
o Re: Jury Duty
D.C. Sessions
o Secure authentication falling back to insecure
Tim Kolar
o Re: Notes on e-mail: Use diaeresis
Jim Rees
o Re: Microsoft Exchange helpfully misdirects e-mail
Anthony Atkielski
Steve Sapovits
o COMPASS '96 Advance Program
Connie Heitmeyer
o The Second USENIX Workshop on Electronic Commerce: cfp
Bennet Yee
o Info on RISKS (comp.risks)

Intel shutdown by power company software bug

<wampler@cs.unm.edu>
Wed, 10 Apr 1996 11:50:05 -0600 (MDT)
>From April 9, 1996 Albuquerque Tribune:

  Computer-chip-manufacturing operations at Intel Corp.'s Rio Rancho plant
were back to normal today after a five-hour power failure, the company said.
Intel Corp. spokesman Richard Draper said today that Monday's power failure,
which ruined an undisclosed number of chips, including some of the plant's
Pentium microprocessors, was caused by a malfunction of Public Service
Company of New Mexico software.  "For business reasons, we're not going to
provide exact numbers as to the product loss from the shutdown," Draper
said. "However, the power outage won't have significant impact on Intel or
its earnings. It's expensive, but again, it's not a significant impact on
our bottom line."  Draper said the power failure occurred about 9 a.m.
Monday; full power was restored about 2 p.m. Monday.
  Intel evacuated about 600 workers during the outage because of dark and
potentially unsafe working conditions.  "The PNM people told us it was a
glitch in a switching system," Draper said. "The original glitch lasted a
few seconds, but we waited to start operations because we were uncertain
about what happened and wanted to make sure we could restore full power."
Draper said PNM's apparent software error is believed to have caused the
wrong circuit breaker to open at a substation, incapacitating three of six
transformers.
 Karin Stangl, a Public Service Company of New Mexico spokeswoman, said
power was restored after about a minute, and she could not explain the
longer problem at Intel.  Stangl said PNM and Intel are investigating.

  [I find Intel's conservative response, both in evacuation, and
  waiting to be sure the power was back, interesting.
  Maybe the software was running on a non-Intel processor trying
  to get even with the Pentiums...  BEW-are]

Bruce E. Wampler, Ph.D., Adjunct Professor, Department of Computer Science,
University of New Mexico   wampler@cs.unm.edu  http://www.cs.unm.edu/~wampler


Daylight Savings Time problem

<wampler@cs.unm.edu>
Wed, 10 Apr 1996 11:31:07 -0600 (MDT)
I was hit by a daylight savings time problem Monday, the day after the time
changed here. My machine is running four different operating systems:
Windows 95, Windows NT, OS/2, and Linux. Since I'd doing cross platform
development, I usually boot at least two different OS's a day.

Monday, I booted Windows 95 first. At startup, I was greeted by a polite
messages asking if the time should be changed to DST.  Fine. Time changed
and correct.

Later in the day, after booting both NT and Linux, I noticed the time was
yet another hour ahead. Either NT or Linux (and I suspect NT, but can't
confirm that) had also, but invisibly, changed to DST.

After some thought, and a class discussion in the software engineering class
I teach, I've concluded this is not an easy problem to solve. In this case,
there were two basic contributing factors I can figure out. First, PCs keep
the internal clock in local time. Not a good idea -- it should be Universal
Time -- but reality. The problem is then that NT or Linux made the assumption
it was the only OS on the machine, and was free to update the time. Unlike
Win95, which could be polite about the change because it is normally a
single user system, NT and Linux both could reasonably assume they don't
normally get shut down each evening, and thus the silent time update (I'm
guessing). It would be unreasonable to expect confirmation from an operator.

In this case, however, the time update did come at boot time. It seems to me
a better update policy for NT/Linux would be to silently update the time if
the change happened while running, and require a confirmation if it happens
at boot time. Not perfect, but better. I tried OS/2, also, and it just
ignored the time change.

Bruce E. Wampler, Ph.D., Adjunct Professor, Department of Computer Science,
University of New Mexico   wampler@cs.unm.edu  http://www.cs.unm.edu/~wampler


Re: De facto Daylight Savings

Dik T. Winter <Dik.Winter@cwi.nl>
Tue, 9 Apr 1996 22:08:02 GMT
 > At http://www.timing.se/Daylight.html there is a brief discussion
 > of the rules for Daylight Savings Time changeovers for central Europe
 > and the UK. At the end of the page it says:
...
 > > The rule is a "de facto standard," not a law.
...
 > With all of our scrambling about to deal with the Year 2000 problem,
 > shouldn't we be just as concerned with this inconsistency that arises
 > yearly (especially if there are no 'hard and fast' laws/standards to dictate
 > DST changeovers)?

But there *are* 'hard and fast' laws that dictate DST changeovers.  There is
however *not* a law that dictates this far into the future but only for a
few coming years.  (Note that these laws, EU directives, are made up far in
advance.  It was already known a few years ago that the EU would change the
rule this year.)  It appears not to be very advisable to cast changeover
dates in concrete.  It is up to the software to deal with this flexibility
and Andrew Olson's timezone package deals very well with it.  (And some
software does not handle it well at all.  Most annoying was a bug in SGI's
software which thought the last Sunday in September last year was October 1,
and so switched out of DST one week late.  Exactly the same bug stroke again
this time when the software thought that the last Sunday of March was March
24, and so switched into DST one week early.  Surprising that the bug was
not fixed in that half year.)

dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/


Don't go it alone -- the Risks of poor design decisions

"-Broomell, Russ" <MARKETING/MARKETING/RUSS%Konica_Imaging@mcimail.com>
Wed, 10 Apr 96 15:21 EST
     I have read posts recently about several risks that all boil down to
one thing -- the Risk of making poor information system design decisions.
 Poor security systems, employees selling data, even the CDA are all at
least partly the result of poor technical decisions.  Unfortunately, this
often happens in low-bidder-gets-the-job situations.
     Konica, the company I work for, has come up with a partial solution to
this problem.  We formed a group called the Information Partners, a
cross-functional group of technical people, managers, and end users from
across our company.  This group steers our corporate information and
technology resources.  We serve as an interface between programmers, users
and upper management, and frequently call in outside help to get the best
systems at reasonable prices.

NOTE: I am not representing Konica as good, bad or otherwise, just stating
how one group met a Risk.

     Our solution has its own Risks, but we help to highlight the importance
of technology in a business environment.  This usually gets us away from the
lowest-bidder reasoning.  The key to success seems to lie in not getting
bogged down in the committee mentality, but rather contributing where we can
add something.  Is a committee the answer to every problem?  Certainly not,
but where computers and systems are concerned, more input can mean a better
result.


Warning! My [...] let me [dangerous/confidence-breaking act]

<wm8s@citynet.net>
Wed, 10 Apr 1996 02:18:50 -0400
I've seen hundreds of stories here and elsewhere about software, hardware,
hybrid and other systems that get blamed for dangerous actions, actions which
compromise security or confidential information, etc., and then always end
with the standard "risks are obvious" caveat. So I though I'd relate a
description of a tremendous danger I just discovered right here in my own
residential neighborhood.

There's a partly computer-controlled / partly operator-controlled mechanical
system near my house that must weight a couple of thousand pounds and has what
I consider to be an unacceptably dangerous user interface.

Today, I noticed that the operator had the ability to operate the system in a
manner that was in violation of numerous laws -- local, state and federal --
without any type of lockout mechanism built in, that there were essentially NO
facets of the user interface that were designed to preclude (or even hamper)
the operator from exceeding the system's absolute maximum operating parameters
(leading quickly to a complete, catastrophic and dangerous failure of the
system), and that the system could be easily operated in a manner which very
seriously jeopardized the safety of the operator and anyone else within a mile
or two (easily fatally), all without even the slightest intervention by the
control system's software or hardware.

Of course... it's my car. My point is that, yeh... your software can make it
*easier* for you to send a confidential memo to your lover and dirty pictures
to your boss, or a Man-Machine Interface can make it *easier* to land a plane
down with the landing gear up, or an engineer can crash a locomotive into the
station *quicker* because the signals weren't triple-redundant and both
warning lights had burned out...

But *YOU'RE* the one that didn't carefully review the address list on that
memo before you clicked [SEND], and *YOU'RE* the one that didn't religiously
observe the standard landing checklist, and *YOU'RE* the one that should have
realized that you shouldn't be going 65 MPH 100 yards from Grand Central.

I'm not trying to defend my profession; I've cursed up and down many a poorly
designed system. But I wonder: are we trying to build better MMI's or just
encouraging dumber operators to distance themselves from responsibility for
their own actions?

Rob Bailey, Bailey Computer Systems  Kanawha / Charleston
WM8S (wm8s@citynet.net) Radio Amateur Civil Emergency Service


Signing binaries (Palme, RISKS-17.95)

Bennet Yee <bsy@Play.UCSD.Edu>
Sat, 6 Apr 1996 14:58:35 -0800
In RISKS-17.95, Jacob Palme suggested the use of peer-review to filter out
malicious software.  While potentially useful, there are a wide variety of
attacks such a strategy would likely miss.  For example, suppose a virus /
alternative-model-Java applet author specifically targetted machines which
were in a particular domain.  Such a form of malicious software is much less
likely to be detected by however large a user pool.  (And a virus targetting
a single company has been found ``in the wild'' before, I believe.)  It is
risky to believe that our past experiences with malicious software is a
completely accurate predictor of the future; riskier still not to consider
the entire collective past experience.

The idea of signing software is not new.  Bellcore's Betsi system uses PGP
to have the author sign their software, and the idea has certainly been
bounced around the security community before that was implemented.  The
effect of CAPI signatures is to make governmental agencies happy so that the
API may be exported.  I doubt that Microsoft cares very much whether the
cryptographic service provider code written by third parties are bug free.
In the CAPI signing model, it is a central authority doing the signing.
Certainly there might be liability issues if MS -- or Sun/Netscape/... for
centrally signed Java applets -- says anything about having looked
cross-eyed at the third party code (risks of deep pockets?).

With author-signed code, the picture wouldn't be entirely rosy either.
Given the number of potential individual coders on the 'net, the
process of knowing who writes good code and who writes buggy code (and
potentially cause security problems) is rather daunting.


Re: Jury Duty

"D.C. Sessions" <dc.sessions@tempe.vlsi.com>
Tue, 02 Apr 1996 12:18:08 -0800
Governments aren't the only organizations that make stupid database-key
decisions.  Our prescription-drug plan has limitations on how much of a
given drug a patient can get at a time -- generally one month's supply.  A
reasonable restriction, all in all, and especially so with Federally
controlled substances such as Ritalin and Dexedrine.

The trouble is, their computer systems check this by keeping a history of
each patient's prescription fills.  The primary database key is the plan
number (basically the primary beneficiary's SSN) and the secondary key, to
distinguish family members, is the individual's birthdate.  (Anybody see the
problem here?)

We have identical twins.  Both are on similar long-term medications for
asthma and ADD, which routinely sends the pharmacy nuts because they can't
get approval for the second set.  (A related problem would be if both
parents were covered, thus having different primary keys.  Why do I suspect
that THAT problem was resolved early?)

The RISK here is in programming for the 95% case without any provision for
not-all-that-rare exceptions.

D. C. Sessions  dc.sessions@tempe.vlsi.com


Secure authentication falling back to insecure (RISKS-18.02)

Tim Kolar <tkolar@cisco.com>
Wed, 10 Apr 1996 09:27:55 -0700 (PDT)
In RISKS-18.02, eggenste@noether.informatik.uni-dortmund.de wrote to explain
security problems with Compuserve's new client.  One of the major ones was
that, although they had switched the primary authentication to do a
challenge handshake, the client would still happily accept a request for
plaintext authentication.

This actually turns out to be a relatively common problem with PPP client
implementations.  There are a number of public domain and commercial clients
that will accept a PAP negotiation even if configured only for CHAP.
Security nightmare.

It seems to me that this mistake flows very naturally out of the PPP
specification as a whole.  A good PPP implementation will attempt to
negotiate just about anything -- Ask for X, if they refuse, ask for Y, if
they refuse ask for Z -- and that same implementation will be as generous as
possible in accepting options -- Sorry, we don't do X.  You want to do Y?
Okay.

This mindset is great for interoperability, but it's a very bad failing when
it comes to security.

-Tim Kolar  cisco Systems


Re: Notes on e-mail: Use diaeresis (Pierce, RISKS-18.02)

Jim Rees <rees@umich.edu>
Wed, 10 Apr 1996 19:13:50 -0400
 > Though many machines on Usenet are eight-bit clean, NNTP is defined to be
 > seven-bit.  There's no guarantee that the use of raw characters in
 > ISO-Latin-1 will come out unharmed on the other end.

NNTP says nothing about character set in the text of an article.  In fact,
it says, "No attempt shall be made by the server to filter characters, fold
or limit lines, or otherwise process incoming text" [rfc977].  I take this
to mean it is intended to be 8-bit clean when used over an 8-bit clean
transport, such as TCP.

USENET messages are not explicitly limited to 7-bit, but "all USENET news
articles must be formatted as valid ARPANET mail messages, according to the
ARPANET standard RFC 822" [rfc850].  Read literally, this excludes all
non-encoded non-ascii text.

Current practice varies from one newsgroup to the next, and even within
newsgroups.  Some use 8-bit characters, others use some sort of 7-bit
encoding, and there is usually nothing in the headers or the body to
indicate what the encoding and character set are.


Re: Microsoft Exchange helpfully misdirects e-mail (Hoffman, R-18.02)

Anthony Atkielski <73064.2766@CompuServe.COM>
10 Apr 96 13:35:01 EDT
In RISKS-18.02, John Hoffman (<john@netweave.com>) describes risks that he
felt were associated with the methods used by the Microsoft Exchange e-mail
client to resolve partial addresses in outgoing messages.

As it happens, there are two features of Exchange that can help to avoid or
eliminate these risks: the Check Names feature, and an option in the client
that controls the query order for address providers.

The first feature (activated by a toolbar button or Alt-K on the keyboard)
resolves all partial addresses in a message header before the message is
actually sent; the user may then verify that the selections made by Exchange
actually correspond to the recipients he has in mind.

The second feature (found on the Tools | Options | Addressing property
sheet) lets the user change the order in which address providers are
queried.  By placing the Global Address List ahead of the Personal Address
Book (the opposite of the default) in this way, Exchange can be forced to
look for a match within the user's organization before checking any
(possibly external) addresses in his Personal Address Book.  (As John has
correctly surmised, Exchange stops at the first address book that contains
one or more matches for a partial address.)

I use both of these features, and I rarely encounter any problems with
incorrect resolution of ambiguous partial addresses.  If I have any doubt, I
do a quick double-click on the resolved name in order to verify that it is
really pointing to the recipient I have in mind.  I do try to use display
names in my Personal Address Book that do not match anything in the Global
Address List, so that I can spot incorrect resolution of an address at a
glance (e.g., the display name for my own CompuServe address in my Personal
Address Book is slightly different from the display name of my internal
address on the Global Address List).

Anthony Atkielski


Re: Microsoft Exchange helpfully misdirects e-mail (Hoffman, R-18.02)

Steve Sapovits <steves@telebase.com>
Wed, 10 Apr 1996 14:28:07 -0400 (EDT)
I haven't used this particular mailer, but maybe part of the risk is in the
design of the mailer.  The free UNIX mailer I use allows a long name to be
assigned to an alias (e.g., the person's real full name).  When I enter an
alias, that name immediately appears on the "To:" line in front of me.
That's saved me from embarrassment more than once.  Being extra paranoid, I
almost always also use a feature of the mailer that lets me see all the
headers before I send a message (and change them if I've goofed).  Silent
mapping of aliases is not something I would want.

Steve Sapovits  Telebase Systems steves@telebase.com  http://www.telebase.com


COMPASS '96 Advance Program

Connie Heitmeyer <heitmeye@itd.nrl.navy.mil>
Tue, 9 Apr 1996 18:00:15 -0400 (EDT)
                             COMPASS '96
                 11th Annual Conference on Computer Assurance
      National Institute of Standards and Technology, Gaithersburg, MD
                           June 17-21, 1996
                  ADVANCE PROGRAM [abridged for RISKS]

Monday, June 17 (Tutorials)

Safety Case Construction and Management
  by John A. McDermid (University of York, UK) -- FULL DAY
Automatic Formal Analysis of Cryptographic Protocols
  by Stephen Brackin (ARCA Systems, Inc., USA) -- HALF DAY
Impact and Design of the Human-Machine Interface
  by Michael Harrison (University of York, UK) --  HALF DAY)


Tuesday, June 18  (Tutorials)

ACL2, An Extended Reimplemented Version of Nqthm Logic
  Theorem Prover by J Strother Moore and William D. Young
  (Computational Logic, Inc., USA) -- FULL DAY
A Framework for Reasoning About Assurance
  by Jeffrey R. Williams (ARCA Systems, Inc.,USA) -- HALF DAY


Wednesday, June 19

8:45 am--Welcome and Keynote
Welcoming Remarks:  Karen Ferraiolo, General Chair
                    Stuart Faulk and Connie Heitmeyer, Program Chairs

Keynote Address I

"The FAST Process (Family-Oriented Abstraction, Specification and
 Translation)--A Study in Successful Technology Transfer"
 David Weiss  (Lucent Technologies, Bell Laboratories, USA)

10am--Formal Specification and Analysis I

"Table Transformation Tools: Why and How"
 H. Shen, J. Zucker, D.L. Parnas (McMaster University, Canada)

"Simulation vs. Verification: Getting the Best of Both Worlds"
 Aloysius K. Mok and Douglas Stuart (University of Texas, USA)

11:30 am--Applying Mechanical Theorem Provers

"ACL2: An Industrial Strength Version of Nqthm"
 Matt Kaufmann and J Strother Moore (Computational Logic, Inc., USA)

"Comparing Verification Systems: Interactive Consistency in ACL2"
 William D. Young (Computational Logic, Inc., USA)

"Mechanical Verification of Object Code Against Source Code"
 Sakthi Subramanian and Jeffery V. Cook (Trusted Information Systems, USA)

2 pm--Practical Applications of Formal Methods

"Industrial Usage of Formal Development Methods:
 The VSE-Tool Applied in Pilot Projects"
 Frank Koob, Markus Ullmann, and Stefan Wittmann
 (Bundesamt fuer Sicherheit in der Informationstechnik, Germany)

"Specifying, Validating and Testing a Semaphore System
 in the TRIO Environment"
 Angelo Gargantini, Lilia Liberati, Angelo Morzenti (Politecnico
 di Milano), and Cristiano Zacchetti (ATM-Azienda Trasporti Municipale, Italy)

"Feasibility of Model Checking Software Requirements"
 Tirumale Sreemani and Joanne M. Atlee (University of Waterloo, Canada)

4 pm--Panel: From Theory to Practice---Bridging the Gap
             Chair -- John Rushby (SRI Intern., USA)

Thursday, June 20

9 am--Keynote Talk

"Ontario Hydro's Experience with New Methods for Engineering Safety-Critical
 Software", Mike Viola (Ontario Hydro, Canada)

10am--Program Verification

"Developing a Translator from C Programs to Data Flow
 Graphs Using RAISE"
 Anne Elizabeth Haxthausen (Technical University of Denmark, Denmark)

"Verification of Consistency between Concurrent Program
 Designs and their Requirements"
 Marsha Chechik and John Gannon (University of Maryland, USA)

11:30 am--Formal Specification and Verification II

"Verifying SOS Specifications"
 Bard Bloom, Allan Cheng, and Ashvin Dsouza (Cornell University)

"A Correctness Proof of a Cache Coherence Protocol"
 Amy Felty and Frank Stomp (Bell Laboratories, USA)

"The Specification of an Asynchronous Router"
 Faron Moller (Kungl Tekniska Hogskolan, Sweden)

2 pm--Software Safety

"Safety Analysis Tools for Requirements Specifications"
Vivek Ratan, Kurt Partridge, Jon Reese, and Nancy Leveson (Univ. of Wash., USA)

"Impact and the Design of the Human-Machine Interface"
A. M. Dearden and M. D. Harrison (University of York, UK)

"Object-Oriented - No Panacea for Safety"
Reginald Meeson (Institute for Defense Analyses, USA)

4 pm--Panel on High Assurance Computing
      Chair -- Richard Gerber (University of Maryland, USA)

6:30  Banquet
      Guest Speaker:  Nancy Leveson (University of Washington, USA)


Friday, June 21

9 am--Computer Security

"An Empirical Model of the Security Intrusion Process"
 Erland Jonsson and Tomas Olovsson (Chalmers University of Technology, Sweden)

"Increasing Assurance Through Literate Programming Techniques"
 Andrew Moore (Naval Research Laboratory) and
   Charles Payne (Secure Computing Corp., USA)

"A Framework for Composition"
 Todd Fine (Secure Computing Corporation)

"Composition of a secure system based on trusted components"
 Ulf Lindqvist, Tomas Olovsson, Erland Jonsson
   (Chalmers University of Technology, Sweden)

11:30 am--Testing

"Detecting Equivalent Mutants and the Possible Path Problem"
A. Jefferson Offut (George Mason University) and Jie Pan (PRC, Inc., USA)

"T-VEC: A Tool for Developing Critical Systems"
Mark R. Blackburn (Software Productivity Consortium) and
   Robert D. Busser (Motorola, USA)

"Defining an Adaptive Software Security Metric From a Dynamic
 Software Fault -Tolerance Measure"
J. Voas, A. Ghosh, G. McGraw, F. Charron (Reliable Software Technologies) and
   K. Miller (University of Illinois Springfield, USA)

1 pm--Conference ends [Breaks, lunches omitted above.  PGN]

  TOOLS FAIR
  8 am--5:30 pm on Wed. and Thurs., 8 am--11:30 pm on Fri.
  See demonstrations of NRL's requirements toolset SCR*,
  CLInc's ACL2 theorem prover, two model checkers, and more...

  FOR MORE INFORMATION, VIST OUR WEB SITE at
  http://www.itd.nrl.navy.mil/conf/compass96  or contact
  Karen Ferraiolo, General Chair (ferraiolo@md.arca.com)
  Stuart Faulk, Program Cochair (faulk@itd.nrl.navy.mil)
  Connie Heitmeyer, Program Cochair (heitmeyer@itd.nrl.navy.mil)


The Second USENIX Workshop on Electronic Commerce: cfp

Bennet Yee <bsy@Play.UCSD.Edu>
Sat, 6 Apr 1996 14:58:35 -0800
See <URL:http://www.usenix.org/ec.html> for full details.
Or you can send e-mail to our mailserver at info@usenix.org. Your message
should contain the line: send catalog.  A catalog will be returned to you.

Announcement and Call for Papers [abridged for RISKS]

The Second USENIX Workshop on Electronic Commerce
November 18-20, 1996, Claremont Hotel & Resort, Oakland, CA

Sponsored by the USENIX Association
Co-Sponsored by Fisher Center for Information Technology Management, UC
Berkeley, and the School of Information Management and Systems, UC Berkeley
Extended abstracts due: July 16, 1996

The Second USENIX Workshop on Electronic Commerce will provide a major
opportunity for researchers, experimenters, and practitioners in this
rapidly self-defining field to exchange ideas and present results of their
work. This meeting will set the technical agenda for work in the area of
Electronic Commerce by examining urgent questions, discovering directions in
which answers might be pursued, and revealing cross-connections that
otherwise might go unnoticed.

Doug Tygar (program chair)
Computer Science Dept, CMU
5000 Forbes Ave
Pittsburgh, PA 15213-3891
tygar@cs.cmu.edu
Fax: +1-412-268-5576

Please report problems with the web pages to the maintainer

Top