Text File

RISKS-LIST: RISKS-FORUM Digest Friday, 27 November 1987 Volume 5 : Issue 66

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Mariner I (Eric Roberts) FORTRAN pitfalls (Jim Duncan) PIN verification (Otto J. Makela) Sudden acceleration revisited (Leslie Burkholder) Re: CB radio and power (Maj. Doug Hardie) An earlier train crash -- Farnley Junction (Clive D.W. Feather)

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. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

----------------------------------------------------------------------

Date: Wed, 25 Nov 87 18:33:14 pst From: roberts@src.DEC.COM (Eric Roberts) To: risks@csl.sri.com Cc: roberts@src.DEC.COM, berlin@mit-xx.ARPA Subject: Mariner I

When Steve Berlin and I were writing the chapter on SDI for the new CPSR book _Computers in Battle_ (Boston: Harcourt Brace Jovanovich, 1987), I tried to track down a more complete reference to the Mariner I story. The theory that this was due to the substitution of a period for a comma in a FORTRAN DO statement seems to stem initially from the following quote from G.J.Meyers, _Software Reliability: Principles and Practice_ (New York: John Wiley, 1976):

In a FORTRAN program controlling the United States' first mission to Venus, a programmer coded a DO statement in a form similar to the following:

DO 3 I = 1.3P

The mistake he made was coding a period instead of a comma. However, the compiler treated this as an acceptable assignment statement because FORTRAN has no reserved words, blanks are ignored, and variables do not have to be explicitly declared. Although the statement is obviously an invalid DO statement, the compiler interpreted it as setting a new variable DO3I equal to 1.3. This "trivial" error resulted in the failure of the mission. Of course, part of the responsibility for this billion-dollar error falls on the programmer and test personnel, but is not the design of the FORTRAN language also partially to blame?

Unfortunately, Meyers lists no references for this version of history. Some years ago, as part of the background work for the slide show _Reliability and Risk_, Steve Berlin had called to ask about sources for this story. Meyers could not remember an exact source.

Since this much tracing left me without a definitive source, I checked the _New York Times_ index and _Readers' Guide_ indices for 1962. The most informative article appeared in the _New York Times_ of Saturday, July 28--six days after the aborted launch:

For Want of Hyphen Venus Rocket Is Lost

By GLADWIN HILL Special to the New York Times

LOS ANGELES, July 27--The omission of a hyphen in some mathematical data caused the $18,500,000 failure of a spacecraft launched toward Venus last Sunday, scientists disclosed today. The spacecraft, Mariner I, veered off course about four minutes after its launching from Cape Canaveral, Fla., and had to be blown up in the air. The error was discovered here this week in analytical conferences of scientists and engineers of the National Aeronautics and Space Administration, the Air Force and the California Institute of Technology Jet Propulsion Laboratory, manager of the project for N.A.S.A. Another launching will be attempted some time in August. Plans had been suspended pending discovery of what went wrong with the first firing. The hyphen, a spokesman for the laboratory explained, was a symbol that should have been fed into a computer, along with a mass of other coded mathematical instructions. The first phase of the rocket's flight was controlled by radio signals based on this computer's calculations. The rocket started out perfectly on course, it was stated. But the inadvertent omission of the hyphen from the computer's instructions caused the computer to transmit incorrect signals to the spacecraft....

The first paragraph makes it sound as if this might be a data entry error and not a coding error at all. Later paragraphs, however, indicate that this was part of the "coded mathematical instructions." Other references to the Mariner I failure appear in the letters section of the _New York Times_ of August 2 (page 24) and in the August 6 issue of _Newsweek_ (page 75) and seem to corroborate the view that this was a programming error.

This account agrees with the recent report from Henry Spencer (RISKS-5.64) who cites "Far Travellers" by Oran W. Nicks. On the whole, this explanation seems to have more documentary evidence than the FORTRAN version of the story presented by Meyers. The existence of other overstatements in his account (in particular, $18,500,000 << $1,000,000,000) also reduces its credibility.

Of course, the FORTRAN version of the story has received widespread distribution of late (it is, after all, a lovely story), including citations in

o Jim Horning, "Note on Program Reliability," _Software Engineering Notes_, 4:4, October 1979, p. 6. o Peter Neumann, "Letter from the Editor," _Software Engineering Notes_, 8:5, October 1983, p. 4 (credited to David Smith of CMU, who heard it from his instructor in 1970 or 1971). o H.S. Tropp, "Fortran Anecdotes," _Annals of the History of Computing_, 6:1, January 1984, p. 61. o Peter Neumann, "Risks to the Public," _Software Engineering Notes_, 11:5, October 1986, p. 17.

However, unless there is more definitive evidence to support this, I think it must be regarded as apocryphal.

My own solution in _Computers in Battle_ was to write:

Shortly after its launch on July 22, 1962, the Mariner I Venus probe veered off course and had to be destroyed by mission control officials. The problem was later traced to a single character error in the controlling software.

This covers both explanations and seems to be on relatively safe ground.

/Eric [Yes, but it bugs the question. PGN]

------------------------------

Date: Thu, 26 Nov 87 13:40:20 EST From: Jim Duncan <jim@xanth.cs.odu.edu> To: RISKS@KL.SRI.COM Subject: FORTRAN pitfalls (Re: RISKS-5.63) Organization: Old Dominion University, Norfolk Va.

(Regarding the DO ... I=1.3 problem:)

I too have heard this `story' many times, and each time the space vehicle took on a new name, and it was on its way to a different planet or mission. The text I am reading for a course in principles of programming languages is the first place I have seen this incident documented. The author is discussing the design of syntactic structures in FORTRAN and the unfortunate effects of adopting a lexical convention that caused blanks to be ignored everywhere:

"In FORTRAN, the statement

DIMENSION IN DATA (10000), RESULT (8000)

is exactly equivalent to

DIMENSIONINDATA(10000),RESULT(8000)

and, for that matter,

D I M E N S I O N IN DATA (10000), RESULT (8000)

While this may seem to be a harmless convenience, in fact it can cause serious problems for both compilers and human readers. Consider this legal FORTRAN statement:

DO 20 I = 1.100

which looks remarkably like the DO-statement:

DO 20 I = 1,100

In fact, it is an assignment statement of the number 1.100 to a variable called `DO20I', which we can see by rearranging the blanks:

DO20I = 1.100

You will probably say that no programmer would ever call a variable `DO20I', and that is correct. But suppose the programmer _intended_ to type the DO-statement above but accidentally types a period instead of a comma (they are next to each other on the keyboard). The statement will have been transformed into an assignment to `DO20I'. The programmer will probably not notice the error because `,' and `.' look so much alike. In fact, there will be no clue that an error has been made because, conveniently, the variable `DO20I' will be automatically declared. If you think things like this can't happen, you will be surprised to learn that an American Viking Venus probe was lost because of precisely this error."

The above is from Bruce J. MacLennan, _Principles_of_Programming_Languages_ (second edition), CBS College Publishing, 1987, pp. 89-90. Mr. MacLennan goes on to elaborate on the principles of good language design violated by FORTRAN, such as Defense in Depth.

To add my two-cents worth: When I first heard the Viking story, I inferred that the offending DO-statement was in the code which either positioned the navigational motors, or did the navigation calculations. I was told that the launch went perfectly and the probe reached the desired earth orbit. When the probe fired its motors to leave earth orbit, however, it supposedly rolled over on its back, fired in the wrong direction, and promptly _disappeared_ from all tracking systems. No one knows where the hell it went....

Jim Duncan, Computer Science Dept, Old Dominion Univ, Norfolk VA 23529-0162 (804)440-3915 INET: jim@xanth.cs.odu.edu UUCP: ...!sun!xanth!jim

------------------------------

Date: Thu, 26 Nov 87 13:11 O From: <MAKELA_O%FINJYU.bitnet@csl.sri.com> Subject: PIN verification To: RISKS@csl.sri.com

In RISKS 5.61, John Pershing <PERSHNG@ibm.com> writes: >I cannot speak for *all* ATM and POS systems, but the major banks >generally know what they are doing with respect to PIN security. The PIN >number is *not* stored on your ATM card -- it is stored in your bank's >database and, possibly, in one or more interbank clearinghouses. This >makes it possible to have your PIN changed without getting the card >re-magnetized (assuming your bank has it's act together). Note that your >account number probably isn't even written on the card -- only a number >that identifies that particular card. [...] >John A. Pershing Jr., IBM, Yorktown Heights

Well, it *would* seem that the Finnish banks use a different system. Perhaps I should first describe the most common types of plastics we have here:

* the autoteller cards, that can only be used in ATM's * the "Bank Cards", that work at ATM's and can be used for buying stuff; using them is legally the same as writing out a cheque for the same amount * the VISA-combocard, that is a combined ATM/Bank Card/VISA-card; when you use them for buying stuff you have to tell what you want it to be used as

All the abovementioned cards DO have the attached account number on them. It is possible also to have SEVERAL accounts on them, but I'm not sure how this is accomplished. This option is only offered by one bank, so it might be just their hack.

Follows a paragraph from the official guide to implementing off-line POS terminals using magnetic card identification:

PIN-verification is done by the Security Unit, which is connected to the POS terminal, according to the the PVV-number, which is read off the magnetic stripe of the card. The requirements for PIN- verification are given separately in "POS terminal security standards". Written requests for the distribution of these standards may be sent to AIP-security Chief Lars Anrkil, SKOP (Kilo), PL 400, 00101 HELSINKI.

[SKOP is a big Finnish banking group, more or less a "collection of competing fiefdoms", as David G. Grubbs <dgg@dandelion.CI.COM> put it in RISKS 5.61; it would seem that the Finnish Banking Association has given them the job of maintaining and distributing these security standards.]

Here's a few arguments against the systems working by being on-line to the bank computer or some other similar system:

* the guide was for OFF-LINE POS terminals. * the same PIN-numbers are used internationally, in VISA-card -based ATM-type machines, where you use your VISA-combocard to get money that will be billed in your next VISA bill. I have difficulties believing that even in this information age they would maintain a computer link from all over the world to remote Finland :-) * I have several times went to an ATM that is used by several banks in co- operation, inserted my card, typed in my PIN and received a message saying "Your bank's computer is down". The PIN was verified BEFORE the ATM tried to contact my bank's computer. * I have asked several times if it is possible to change my card's PIN number (just to know if it is possible), and have always received a reply stating "no, it's not possible, it's derived from your card number". This is very weak, since bank people generally aren't that good on technical aspects...

I think these taken together are pretty strong indications that the PIN verification CAN be done off-line, at least for the Finnish standard of cards.

I dearly do hope that security in these systems is not maintained by secrecy ONLY! However, I have had the company I work in part-time order the set of security standards, so as soon as we get them, I'll let you people know more...

Otto J. Makela, U of Jyvaskyla Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland Phone: +358 41 613 847 BBS: +358 41 211 562 (V.22bis/V.22/Bell 212A/V.21) BitNet: MAKELA_OTTO_@FINJYU.bitnet

------------------------------

Date: Thu, 26 Nov 87 13:15:59 -0500 (EST) From: Leslie Burkholder <lb0q+%andrew.cmu.edu@ROME.UCI.EDU> To: risks%csl.sri.com@ROME.UCI.EDU Subject: Sudden acceleration revisited

Honda motor company has offered replacements for the chip controlling acceleration in the 88 Civic. Some people have complained of problems with this chip in their Civics.

------------------------------

Date: Wed, 25 Nov 87 11:44 EST From: "Maj. Doug Hardie" <Hardie@DOCKMASTER.ARPA> To: risks@csl.sri.com Subject: Re: CB radio and power (RISKS-5.64)

[For the record. Truth-in-harmonics department.]

> The second harmonic of 26-27 Mhz signals rounds out to 104-108 Mhz, > or the upper half of commercial FM radio. [Jeffrey R Kell. RISKS-5.64]

According to my understanding of the new-new-math (I am a product of the new math), that would have to be the fourth harmonic. -- Doug

[I hope no one pleads the fifth. 130-135 would sound suspiciously like late Beethoven String Quartets. Gesunta-heit. PGN]

------------------------------

To: comp-risks@ukc.ac.uk From: "Clive D.W. Feather" <mcvax!root.co.uk!cdwf@uunet.UU.NET> Subject: An earlier train crash -- Farnley Junction Date: 27 Nov 87 16:48:37 GMT Organization: Root Computers Ltd, London, England

Not quite computers, but after the item in RISKS-5.64 about the Swedish train crash, readers might find this interesting.

Summary of official report on accident at Farnley Junction (Yorkshire) in 1977, on British Railways.

Farnley Junction is a few miles from Leeds Signal Box, and is remotely controlled from there. All safety interlocking logic is in the signal box itself (all signalling in this area is carried out by 12V relay logic). The distance is such that an intermediate repeater unit repeats all relay signals between the junction and the box.

The physical layout is as follows:

\ Little used \ branch line \ \ -------*-----| S \ --->-----------------------*------*------------->--- Up line \ ---<--------------------------------*-----------<--- Down line S * = points, S = signal

Normal logic, e.g., for signals, is binary, but the controls and position detection of the up-to-down-line crossover happened to be trinary (line A positive = straight ahead, line B positive = cross over, neither positive = no command / not correctly set).

On the day in question, a fault at the repeater unit was causing problems. Both signals were set to Danger by the signalman, and an engineering team then changed the rectifier in the power supply at the repeater unit.

The loss of power caused the main signalling logic to believe the crossover was not correctly set (no repeat of the detection), and so it set the control lines to drive the crossover back to the stright ahead position (this will stay driven until the detection is correct - meantime, the signals are locked at Danger).

Trains came to a halt at both signals.

The engineers restored power to the repeater, but had wired in the rectifier the wrong way round. This had the effect of reversing the polarity of voltages repeated - not important for binary signals.The crossover took the incoming voltage as a command to move to the "crossover" position, and did so. The detection mechanism correctly reported "crossover" - this was reversed at the repeater, and the main signalling logic (correctly) took the incoming signal to mean that the points were locked in the "straight ahead" position.

The signalman now set both signals to Proceed, and the signalling logic allowed him to do so. The train on the Up line started off immediately (the other driver was trying to figure out why the points were set the wrong way !), traversed the crossover, and collided with the train on the Down line, killing two people.

I know this isn't computing, but there's a lesson in it, even so.

[Don't lessen the lesson by thinking this isn't computing. Circuitry, programs, algorithms, and people have much in common. PGN]

------------------------------

End of RISKS-FORUM Digest ************************