The RISKS Digest
Volume 4 Issue 95

Wednesday, 3rd June 1987

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

COMPASS '87, of particular interest to the RISKS audience
Stan Rifkin
Re: Run-time checks
Jerome H. Saltzer
Risks of Inappropriate Technology to Prevent Password Overwrites
Michael Robinson
Clarification of PL/I array checking
Michael Wagner
Risks for computer junkies
Robert Hartman
Re: When Computers Ruled the Earth (Bank Stupidity)
Ed Sachs
Clarification on CHAPPARAL and VULCAN
Bill Gunshannon
Info on RISKS (comp.risks)

COMPASS '87, of particular interest to the RISKS audience

Stan Rifkin <rifkin@tove.umd.edu>
Wed, 3 Jun 87 17:48:42 EDT
COMPASS '87 will be held in Washington DC the week of 29 June - 3 July 1987
at Georgetown University.  COMPASS stands for COMPuter ASSurance and is
concerned with software safety and process security.

"Our safety, health, and welfare are increasingly dependent on the safe and
correct use of computers.  Despite advances in software engineering and
system design, it is common to find major bugs and untrustworthy performance
in critical computer-controlled systems.  Existing approaches to computer
assurance need to be refined technically and economically, and brand new
approaches need to be explored."

The keynote speaker is Harlan Mills, IBM Fellow.  Dr. Mills will speak 
about his quiet revolution at IBM, his "cleanroom" approach to software 
development.  Dr. Mills is trying to convince the DoD and NASA not to 
acquire debugged software, rather to buy only software that didn't have 
any bugs in the first place!  And he is receiving a receptive audience.

The keynote address and formal papers will be given on 30 June and 1 July.
The other days include special-interest group meetings and a tutorial (2
July) by Nancy Leveson on software safety.  COMPASS is sponsored by the IEEE
Washington DC Section, NASA, Computer Sciences Corp., and George Mason
University.  The Proceedings contain some sure-to-be classic papers: Mills
on how to acquire software, Neumann on the N best (or worst) computer risks
and the implications, several surveys of trustworthy systems and tools, and
lessons learned from the NASA Shuttle disaster and other real-world systems.
There are panel sessions on software safety, on the role of high-level
programming languages, and on legal implications.  In addition, there is a
banquet talk by Henry Petroski ("To Engineer is Human: The Role of Failure
in Successful Design"), and a luncheon talk by John Shore.

For further information on the program or registration, please contact Al
Friend in Washington DC either over the network at friend@nrl-csr.arpa or by
telephone at 202/692-7235.  Many people are staying the weekend after to
enjoy the Fourth of July in the Nation's Capital.

Stan Rifkin, Publications Chairman

      [I hope that in early July RISKS will have some relevant comments on
      Harlan's talks and other COMPASS topics.  (Last year's COMPASS program
      featured a rousing talk by David Parnas as Keynote Speaker.)  PGN]


Re: run-time checks (RISKS DIGEST 4.94)

Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Wed, 3 Jun 87 13:16:41 EDT
Henry Spencer mentions on the subject of run-time checks,

 > The distinguishing feature here is that both Multics and MCP 
 > are running on special hardware... 
 > ... many people will trade off safety for performance any day...

That comment was widely accepted as the dominating concern in the 1970's,
when people were actively debating whether or not to carry forward the
hardware features that were required to support Multics and MCP.  At the
time, hardware features were still quite expensive.  But with 1980's
technology available, those concerns somehow look diminished.

With moderately clever implementation, hardware run-time checks can usually
be done in parallel with the main stream of computation, so they don't
directly impede performance that much.  At most they have the indirect
effect of using up silicon that might have been invested in performance
enhancements.  They also use up chip design time, but one would expect that
cost to be repaid many times in applications development time savings.

It seems to me that there remain two real barriers to introduction of
hardware run-time checks:

  1.  Developing a conviction that they are a good idea.  Those of us
  who have developed programs on Multics or MCP are easily convinced,
  but those of us who haven't are in a majority.

  2.  It is hard to sell a new architecture.  Life is more rewarding
  for people who do improved, compatible implementations of old ones.

                        Jerry Saltzer

      [Jerry has put his finger on one of the stumbling blocks in
      trying to attain systems with critical requirements for security, 
      reliability, safety, etc.  There are obvious incentives to use
      available hardware, software, programming languages, network
      facilities, etc., even if atrociously malsuited to the application.
            [For you old Don Marquis fans, we have a clear-cut 
            case of Archi(tecture) and Compatibel.  PGN]]


Risks of Inappropriate Technology to Prevent Password Overwrites

Michael Robinson <MIKE%UTCVM.BITNET@wiscvm.wisc.edu>
Wed, 03 Jun 87 09:33:50 EDT
A very thorough bounds test could be performed millions of times in the time
that it has taken you to read this sentence. The test has done nothing to 
further the purposes of the program, but it has given you that much more cause 
to believe that the program is working properly.  If something IS wrong, you 
know that you will know about it before it completely wrecks your program.

Dependability, serviceability, future expansion, and the need for defensive
posturing are basic engineering concerns — whether you're building a
footbridge or a computer program. They do nothing for the bridge, but they do
help to guarantee that something infinitely more expensive than the bridge, 
namely a human being or his payroll record, won't fall into the waters below.  
If you can't be sure of that, then the cost of failure has completely eaten
up any cost that you "saved" by not anticipating the possibility.

The computer is the least expensive part of the whole scenario. You can always
buy a bigger one. If you "waste" a few milliseconds being very sure that you
don't have a problem, then it's time well spent.  If and when a problem does
crop up, then the defensive code kills two birds with one stone: alerting
you to the fact that you have a problem, and giving you a clear(er) picture
of exactly when, what, where, and why the problem has occurred.

These are some of the ideas that went into the design of the newer
languages.  It doesn't take much effort to become proficient in any one of
them and it behooves us very much to take advantage of them when we can.
Bounds tests, "inefficiencies," and all.  It's just plain good sense.

Michael Robinson, Univ. Tennessee at Chattanooga, CECA - 413 Hunter Hall
615 McCallie Avenue, Chattanooga, TN  37403, BellNet: (615) 755-4003 


Clarification of PL/I array checking (re: RISKS DIGEST 4.94)

Michael Wagner +49 228 303 245 <WAGNER%DBNGMD21.BITNET@wiscvm.wisc.edu>
Wed, 03 Jun 87 14:45 CET
> > The particular error ... could not have happened in a
> > language such as PL/I ... where over-running the bounds of an
> > array is a required run-time check...

I winced when I read this, because 'required' is such an ambiguous word (on
whom is the requirement placed), but assumed that people would know enough
PL/I to understand.  Then came Henry's comment ...

> ... my recollection is that every PL/I compiler I've ever seen
> has a turn-checks-off option, and usually it's the default.

I have experience with only 3 PL/I compilers.  Subscript checking defaults
to on for two of them (PL/C from Cornell and PL/I Checkout from IBM), and to
off for one (PL/I Optimizer from IBM).

> The reason is clear:  such checks are expensive, particularly
> with a naive compiler that can't eliminate many of them at
> compile time, and the overrun condition is rare.

We may disagree about what 'expensive' means, but I have examined the output
from the PL/I Optimizer with full subscript checking turned on and estimated
the cost of run-time subscript checking to be less than a few percent of the
total.  I ran a production subsystem with checking on for a few weeks, and
this yielded a number in concert with my estimates.  In the end, I turned
subscript checking off, but if the output of the system had mattered in any
real sense, I would have considered it false economy.
                                                           Michael


Risks for computer junkies

Robert Hartman <sun!rdh@seismo.CSS.GOV>
3 Jun 87 22:38:28 GMT
Regarding Steve Thompson's article about gambling addicts (RISKS-4.94), the
drug involved is ... adrenalin! This may also be true for computer junkies.
There is indeed cause for worry about the dangers of addiction to a
"response-pattern generator" that seems to be so emotionally neutral (giving
no feedback whatsoever about the user's habits or characteristics), and as
intellectually absorbing as the computer's user interface.  (Although the
shell isn't the most exciting person to spend time with, it never calls you
a jerk either.)

An emotionally vulnerable person can indeed be sucked in, and can tend to
lose sight of the fact that dealing with people isn't as straightforward as
dealing with computers.  One cannot usually "correct a relationship
malfunction" with an "abort/restart sequence" and "different inputs."
Because the addict may feel incompetent to deal with people anyway, spending
increasing amounts of time on the machine tends to compound his feeling of
isolation.  This can lead to a vicious circle in which he returns to the
relatively "safe" (if emotionally stultifying) environment of the computer,
after increasingly disappointing experiences with people that he is less and
less able to cope with.

As interfaces get better, this risk gets worse.
                                               -bob. Sun Microsystems, Mt. View


Re: When Computers Ruled the Earth (Bank Stupidity)

Tue, 2 Jun 87 20:56:49 EDT
The ultimate case of bank stupidity came when we bought our house eleven
years ago.  At that time, they offered us the option of an automatic payment
plan, where we gave them the authorization to write a check on our checking
account (at a different bank, we're not stupid) for the monthly mortgage
payment.  As a side bonus, they were willing to do it twice a month for
half-payments, which was convenient as I was getting payed twice monthly at
the time (not to mention the postage savings).

About a week after we signed all the papers, I got a call from the nice lady
at the bank saying that could not put us on the automatic payment plan.  The
reason?  Our monthly payment amount was odd, and the two half-payments had
to be equal.  A few minutes on the phone and the nice lady checking with her
supervisor determined that we were allowed to make a greater payment with
the extra money going toward the loan principal, so we increased the monthly
payment amount by $0.01 to make the two half-payments equal.  And so we
thought we had it licked.

Act III:  Bank statement arrived at end of month.  Two automatic
payment checks to mortgage had cleared, each for $0.01!!!

Ed Sachs, AT&T Bell Laboratories, Naperville, IL, ihnp4!ihlpa!essachs


Clarification on CHAPPARAL and VULCAN [but for the record]

Bill Gunshannon <bill@westpt.usma.edu>
3 Jun 87 15:30:31 GMT
>From: Iglesias%UCIVMSA.BITNET@wiscvm.wisc.edu
>To: RISKS@CSL.SRI.COM
>Subject: Re: Phalanx Schmalanx                              [For the record]
>
>   > Years ago, the US Army had a weapon called the "Chapparal", which 
>   > was a 20mm gatling mounted on an armored personnel carrier....
>
>You may be confusing the Chapparal with something else...

The weapon they are trying to identify was called the VULCAN.  It was a sister 
to the CHAPPARAL and was used to shoot down low-altitude aircraft.  I served in
Europe with 2/60th ADA C/V which was one of the first CHAPPARAL/VULCAN units to
be deployed over there.  They were the last thing the enemy had to get past 
before hitting something important like an airbase or equipment depot.  That's 
assuming they made it past the NIKE and HAWK batteries.  I believe from what I 
have seen in the news photos that the PHALANX is merely a sea-going VULCAN.

bill gunshannon

UUCP:      {philabs,phri}!westpt!bill        PHONE: (914)446-7747
Martin Marietta Data Systems, USMA, Bldg 600, Room 26, West Point, NY 10996

Please report problems with the web pages to the maintainer

x
Top