12-Jul-87 23:16:32-PDT,17065;000000000000 Return-Path: Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Sun 12 Jul 87 23:13:50-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA13751 for RISKS-LIST@f4.csl.sri.com; Sun, 12 Jul 87 23:15:01 PDT Message-Id: <8707130615.AA13751@csl.csl.sri.com> Date: Sun 12 Jul 87 23:12:31-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 5.11 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Sunday, 12 July 1987 Volume 5 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Old News from New Olds: Check that Backup! (Fleischmann) Auto Computers (Tony Siegman) Re: Liability of Expert Systems Developers (George Cross) Re: Hardware failures (Sam Crowley) Hardware/software interaction RISK (Robert Weiss) More on Risks in "Balance of Power" (Heikki Pesonen) Re: Sprint access code penetration (John Gilmore) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Fri, 10 Jul 87 07:07:41 edt From: decvax!savax!nhqvax..fleischmann@ucbvax.Berkeley.EDU To: "decvax!ucbvax!csl.sri.com!risks"@savax.dec.com Subject: Old News from New Olds: Check that Backup! 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." ------------------------------ Date: Sun 12 Jul 87 10:25:28-PDT From: Tony Siegman Subject: Auto Computers [A rebootal?] To: risks@csl.sri.com 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. ------------------------------ Date: Thu, 9 Jul 87 15:31:55 PDT From: George Cross To: ailist@sri.stripe.com, risks@csl.sri.com Subject: Re: Liability of Expert Systems Developers 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 ------------------------------ Date: Fri, 10 Jul 87 11:11:58 CDT From: crowley%astroatc.UUCP@wisc.edu (Sam Crowley) To: uwvax!RISKS@csl.sri.com Subject: Re: Hardware failures > 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] ------------------------------ Date: Sun, 12 Jul 87 14:27:57 CDT From: "Robert Weiss" To: RISKS@csl.sri.com Subject: Hardware/software interaction RISK >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. ------------------------------ Date: Sun, 12 Jul 87 21:53:53 FIN From: Heikki Pesonen Subject: More on Risks in "Balance of Power" To: Risks Digest 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. ------------------------------ Date: Sun, 12 Jul 87 18:02:51 PDT From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) To: RISKS@csl.sri.com Subject: Re: Sprint access code penetration 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] ------------------------------ End of RISKS-FORUM Digest ************************ -------