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 5 Issue 11

Sunday, 12 July 1987

Contents

o Old News from New Olds: Check that Backup!
Fleischmann
o Auto Computers
Tony Siegman
o Re: Liability of Expert Systems Developers
George Cross
o Re: Hardware failures
Sam Crowley
o Hardware/software interaction RISK
Robert Weiss
o More on Risks in "Balance of Power"
Heikki Pesonen
o Re: Sprint access code penetration
John Gilmore
o Info on RISKS (comp.risks)

Old News from New Olds: Check that Backup!

<decvax!savax!nhqvax..fleischmann@ucbvax.Berkeley.EDU>
Fri, 10 Jul 87 07:07:41 edt
From the latest issue of Car and Driver page 34:

"A computer technician sent to check out a problem at Oldsmobile reports
this disaster; a 70-megabyte hard disk in the company's computer system
failed, completely wiping out the computer-aided design of a 1990 Olds car.
Since hard disks are routinely backed up by separate magnetic-tape systems,
however there wasn't much reason to panic at first.  But there soon was;
examination of the backup tapes revealed that they were blank.  Our insider
reports that Olds will have to do the design all over again."


Auto Computers [A rebootal?]

Tony Siegman <SIEGMAN@Sierra.Stanford.EDU>
Sun 12 Jul 87 10:25:28-PDT
My new Dodge Caravan has an elaborate microprocessor-controlled radio, and
a large array of interior courtesy lights all linked to all the doors and
hatches.  If you leave any opening even slightly adjar overnight, your
battery goes dead, and the radio's computer goes into a catatonic state
which is NOT cured by jump-starting or recharging the battery.  After
battery power is restored the cassette tape will play, but the radio won't
tune or respond to anything, manual or pushbutton.  To restore it, you have
to pull momentarily one of the two fuses supplying the radio's power.  This
isn't mentioned anywhere in any of the car or radio manuals; I've had to
figure it out three times thus far.


Re: Liability of Expert Systems Developers

George Cross <cross%cs1.wsu.edu@RELAY.CS.NET>
Thu, 9 Jul 87 15:31:55 PDT
I don't know about any pending cases, but readers interested in this subject
should check the article by Christopher J. Gill, High Technology Law Journal, 
Vol 1, #2, P483-520, Fall 1986 entitled "Medical Expert Systems:  Grappling
with Issues of Liability."  An important legal issue is whether the use of a
medical expert system constitutes a product or a service.  If an expert
system is a product, strict liability applies whereas if it a service then a
negligence standard applies.  Perhaps some lawyer reading Risks or AILIST
could read this article and summarize it for us.  It is not easy going.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 George R. Cross, Computer Science Department,  Washington State University,
 Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636
 ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!cs1!cross      faccross@wsuvm1.BITNET


Re: Hardware failures

Sam Crowley <crowley%astroatc.UUCP@wisc.edu>
Fri, 10 Jul 87 11:11:58 CDT
> The assumption is that hardware will work or fail catastrophically, or that
> error correcting circuits will detect problems.  Is this always so?
   In the work I have done I have never made the assumption that hardware will 
either work or fail catastrophically. There can be a fault in hardware that 
will only appear when exercised. The 80386 fault only appears when certain 
numbers are multiplied together, otherwise the chip functions properly. 
   By error correcting circuits I assume you are including error detecting
circuits. Error detecting methods include parity and checksums. Error
correcting methods involve the use of error correcting codes (ECC) such 
as SEC-DED (single error correcting, double error detecting). It is possible 
for error detecting methods to not detect an error. With parity if an even
number of bits change value there will be no error detected. With ECC it
is possible for an error to be corrected wrongly or not detected at all. 
A paper authored by C. Chen and M. Hsiao titled "Error-Correcting Codes for
semiconductor Memory Applications: A State of the Art Review" in the March
1984 issue of IBM J. Res. Develop. magazine will explain the gory details.
It should be noted that proper implementation of ECC and prompt removal of 
faulty parts will minimize this risk.
   An error detection method to check arithmetic operations is to encode the
operands in an arithmetic code. Arithmetic codes are preserved by arithmetic
operations but not by boolean operations. To check a boolean operation usually
involves doing the computation on two separate units and then comparing the
result. A computer that did this was the STAR (self test and repair) computer
designed at JPL for use on board planetary probes.

>      How often do microprocessors fail in minor ways?  People have written
> about proving correctness of code: it is not possible to prove the
> correctness of hardware.  For example, a complete test of a 32 bit
> multiplier would require 2**64, or 1.8E19 operations.  
   There seems to be two issues here, design verification and testing to see
if hardware is fault free. Design verification is the process of verifying
that the hardware meets the specification it was designed for. I am not 
knowledgeable in this field. Testing to see if hardware is fault free I do know
about. I have written test vectors to completely test a 74F181 which is
a 4 bit ALU. It was 100% tested in around 30-40 vectors. By knowing
the gate level diagram and the possible faults it was not necessary to run
every combination of inputs through the chip. What was done was to setup the
input vector so that a particular fault if it was present would change the
output of the chip. It was written assuming that you were able to control
the inputs and observe the outputs, something typically found on a chip or 
board tester. Tests that do not or cannot use a tester are more complicated
but follow the same method of having a fault affect the output in a way that
can be observed. 

>  Even without complete tests, writing diagnostic
> programs was extremely difficult when various margin and worst case
> conditions had to be considered. 
   If a diagnostic is to be effective it is going to have to take into
consideration most fault cases. The tests I have worked with and written make
the assumption of a single fault occurring. This simplifies the possibilities
with a good probability of detecting multiple faults when they occur.
Testing is simplified by the use of circuits to aid in testing the hardware.
As hardware becomes more complex, testing needs to be considered when the 
hardware is being designed or else the test designer will have a difficult
time writing tests and the tests will not be as effective as they could be.

              Sam Crowley               uwvax!astroatc!crowley

   [Concerning SINGLE-FAULT-TOLERANT SYSTEMS, I noted recently that most
   of the nuclear power plants are designed to remain safe as long as only
   a single pipe ruptures.  Two pipes are too many.  Earthquakes could make 
   things quite difficult.  PGN]


Hardware/software interaction RISK <Alan Wexelblat>

"Robert Weiss" <weiss@umnstat.stat.umn.edu>
Sun, 12 Jul 87 14:27:57 CDT
>Friends of mine were recently stung by an unanticipated problem in the
>interaction of the hardware and software.  They were using a random
>number function which was not truly random...

The modification described here to a pseudo random number generator 
(pseudo-RNG) is a really bad idea.  RNG's are developed to have some 
basic statistical properties, such as little or no autocorrelation, 
a uniform distribution similar to an idealized sequence of uniform 
random numbers, unpredictable without a fair bit of work, non-repeating 
over very long sequences.  Often these sequences are called pseudo-random.  
Whether it is possible to develop "real" random numbers is a philosophical 
problem.

Pseudo-RNG's have several advantages over a hypothetical sequence 
of "real" random numbers.  For example, you can restart the generator
to find the sequence of inputs to your program that caused the program 
to bomb.  You don't need to store the entire sequence of numbers because
the code to generate them is quite compact.  A competent developer of a
pseudo-RNG has already tested the sequences that come from the generator 
to make sure it indeed does pass statistical tests such as listed in 
Knuth's Art of Computer Programming chapter 3.  When you modify the 
generator by changing the seed at each call, you have created a new 
pseudo-RNG and you don't have a clue as to the statistical properties 
it now has.  Quite probably, you have reduced the number of possible 
sequences that the generator might produce - as happened to the people 
in Alan's story. 

If you feel a need to have a higher quality pseudo-RNG than what you 
have available, Statistical Computing, by Kennedy and Gentle has a 
good discussion of various pseudo-RNG's.

Robert Weiss, Statistics Grad Student, University of Minnesota.


More on Risks in "Balance of Power"

Heikki Pesonen <LK-HPE%FINOU.BITNET@wiscvm.wisc.edu>
Sun, 12 Jul 87 21:53:53 FIN
Many thanks to all who commented on my contribution in RISKS DIGEST 5.8,
"RISKS in Balance of Power".  In this contribution I hope I can make it
clear, why I dislike the game, although my adult children found it funny
when they played it.  Also in the journal Byte, May 1987, Chris Crawford's
book about his game is reviewed and appreciated.  In a Finnish home computer
magazine "Balance of Power" received "****" (the maximum is 5 stars).

In the Instruction Manual the goal of playing is defined as "increase your geo-
political prestige and weaken the geopolitical prestige of the Soviet Union."

As a beginner you proceed to the goal by 
BLOWING INSURGENCY AND TERRORISM TO FLAMES.

When you master the beginner's level you can try the more difficult
"intermediate level".  On that a new channel of geopolitical interaction is
introduced:  THE SUBVERSION AND DESTABILIZATION OF FOREIGN GOVERNMENT.

You destabilize a government by sending in the CIA to encourage dissidents,
fund the opposition, incite riots and create other domestic political mayhem|

After you master these affairs (besides now and then sending money and
troops either to rebels or to governments) you become an expert.  The Expert
Level game introduces a new vehicle for governmental change, FINLANDIZATION.

Chris Crawford describes the term Finlandization by giving a short description
of the history and political situation of Finland.  The story is quite foolish
being on the level of the tourists jokes about the polar bears they have
met on the streets of Finnish cities.  For example, according to Crawford:

  "Finland is effectively under strong Soviet influence." and
  "Finland's relations with the USA are poor."

If things are so bad, how is it possible that our recent Prime Minister
and many other ministers are from the Right Party (Kokoomus).  How is it
possible for me to send this letter through a Finnish computer net with
many IBM and Digital computers, not allowed to export to countries connected
with Soviet Union?  How reliable are other so called facts in Crawford's game?

In "Balance of Power" you can Finlandize a country exerting diplomatic
pressure.  Pressure is an attempt TO INTIMIDATE A COUNTRY WITH WORDS AND
PROVOCATIVE ACTIONS, for example, holding naval maneuvers off the coast of
the victim.  (US Navy probably tried to Finlandize Libya when holding
maneuvers on the Gulf of Syrt.)

The errors and oversimplifications of Balance of Power are not its dangerous
features.  What irritates me is the worldview and the type of behavior the
game reinforces.  Thanks to the game certainly a lot of new Oliver Norths
are growing up in America. I am very glad to know, that Russians have only a
few Amigas and Macs, so that their youngsters are not playing this
geopolitical game.

The term "Geopolitics" is from German origin. "Geopolitik" was the strategic
methodology of Nazis. Hitler was a Master level player of a game very
similar to "Balance of Power".


I have written this letter in my Summer cottage not far from Russian
border using my old Commodore-64 sending it through telephone lines.


Re: Sprint access code penetration

John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
Sun, 12 Jul 87 18:02:51 PDT
It is no surprise that Sprint access codes can be penetrated.
It would be no surprise to find out that AT&T calling card numbers
(basically the same thing, but mishandled) can be penetrated.

In its early days, Sprint used 5-digit access codes and assigned
them in nearby groups.  This meant that knowing one or a few codes
made it possible with 15 minutes of manual trying to come up with
a bunch more.  Needless to say, they were hacked to pieces.

Their response to this was the "Travelcode", a 2-digit number tacked
on to the 5-digit number when you are calling a different Sprint CO
than your usual one.  They also presumably started doing more random
assignment of the numbers.  Even if you knew someone's access code,
you'd have to try 50 travelcodes with it before it's likely you would
hit on the right one, and by then they could have noticed you scanning
for it.

Look at AT&T:  their charge codes contain the user's phone number,
which is publicly available information.  They only add 4 digits to it,
and in prior years, these digits were assigned by a trivial scheme,
which was typically discovered and published by the Yippies.

I suspect that the Telecom digest archives have a lot more information
on telephone billing security, if anyone is interested.

As with any public protestation about crime, the value is inflated.
Wholesale cocaine is always reported at inflated retail prices.  Similarly,
the phone companies lose beelyuns and beelyuns of dollars at this, though
they haven't shown that it requires them to increase their call handling
capacity.  What they claim to lose is the thousands of dollars that each
teenage phone hacker would have paid them making these calls legitimately.

In a recent article, someone from AT&T said "these calls have got to stop".
I challenged him, and AT&T, to stop them then.  Any time is fine by me.

   [This message duplicates some previous discussion, but also summarizes some
   useful points and is therefore worth including in RISKS.  The bottom line
   is usually $, and here as usual it seems cheaper to the producer and more
   acceptable to the user community to swallow the "losses".  Yes, in telephone
   calling it (marginally?) increases the load on the system, but in credit
   cards (VISA, etc.) fraud actually results in real losses -- but they are
   simply passed on to the customers through increased fees and service
   charges.  In both cases the burden is distributed to the users, who must
   watch for unauthorized charges and then negotiate to have them undone.  PGN]

Please report problems with the web pages to the maintainer

Top