RISKS-LIST: RISKS-FORUM Digest Wednesday 23 March 1988 Volume 6 : Issue 48 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Verified microprocessor for critical applications (Jon Jacky) Computer rolls give indigestion to voters? (Dave Horsfall) Re: "NEW" Amiga virus has arrived in Europe (Harv Laser) "Drive by wire" autos in development (Jonathan Jacky) The COMMON Code Virus (Kevin Driscoll) Lazy Lousy Linkers Leave Large Loophole, Let LowLife Lads Loose (Kevin Driscoll) 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:, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: Tue, 22 Mar 88 09:25:33 PST From: jon@june.cs.washington.edu (Jon Jacky) Subject: Verified microprocessor for critical applications The March 14, 1988 ELECTRONIC ENGINEERING TIMES, pps. 54- 60, has a long story about a British effort to build a completely verified microprocessor for critical applications. The story is notable in that it motivates the effort throughout by calling attention to the possibility of major accidents involving computer failure. At the start of the story is a full-page illustration depicting a snake with fangs bared, and the lead: "THE VIPER -- Somewhere - at a nuclear plant, on board a missile, or at a chemical refinery, it's going to happen: a catastrophic computer-related disaster. A growing group of engineers and scientists say it's unavoidable with today's microprocessors, which they deem inherently unreliable. Prompted by sense of urgency, they have developed a high-integrity processor called ... The Viper. THE VIPER: DEVELOPERS PUSHED BY IMPENDING SENSE OF DANGER - Roger Woolnough ... John Cullyer, John Kershaw and Clive Pygott of the Royal Signals & Radar Establishment (RSRE) Computing Division ... make up the team that has designed the Viper 32-bit microprocessor. Viper - which takes its name from "verifiable integrated processor for enhanced reliability" - is the world's first microprocessor for safety-critical applications. It's designed using formal methods and subjected to a lengthy process of formal proof. ... The road that lead to Viper stretches back almost nine years, but the work began with software rather than hardware. In the summer of 1979, Cullyer and his colleagues believed they could firm up the analysis of computer programs to detect deeply buried mistakes. ... By the beginning of 1983, (they) had applied (static-code analysis) to the examination of a number of real military projects. "Put quite simply, we got quite a shock," said Cullyer. "We were very surprised at the mistakes which were left in software delivered to the British Ministry of Defence. What also came out was the fact that some of the problems were due to the microprocessor chips themselves - not only conventional processors, but also special-purpose chips. We found mistakes in things like the fundamental arithmetic - in the case of one processor, -1 x -1 = -1." ... But are the shortcomings of commercial microprocessors really so serious? The RSRE team has no doubts on that score, and the substantial literature it has produced on high-integrity computing spells out many of the dangers that lurk in today's chips and software. Says John Kershaw, "It is questionable whether any computer in general use has ever been fully specified, in the sense of allowing its response to every possible combination of inputs and instructions to be predicted. It is beyond question that none has ever been fully tested; an exhaustive test of even the simplest microprocessor would take billions of years." (Then followed a lot of material familiar to RISKS readers, but some unfamiliar (to me) reports of computer-related accidents:) ...At least one death has apparently been caused by a fault in a computer program controlling a hospital drug-dispensing machine. ...There are two claims for compensation currently going through the US legal system, one by the widow of a pilot who crashed in an F-16 and the other by the widower of a patient killed by a faulty intravenous drip machine ... (A sidebar tells the story of how Viper was verified, using the specification language LCF-LSM, invented at the University of Cambridge (England) by Michael Gordon, and a hardware description language called Ella, developed at RSRE) ... John Cullyer carried out a proof by hand to show informally that the major state machine did correspond to the top-level specification, but the formal proof was a much more extensive exercise. This was undertaken by Avra Cohn (of Cambridge). Cohn's work relied heavily on an automated theorem prover, and is one of the largest automated proofs ever undertaken. It took well over a year, and involved more than 1 million primitive inferences. ... Viper is a simple device from necessity, because a more complex architecture would have demanded proofs that are beyond the current state of the art. - Jonathan Jacky, University of Washington ------------------------------ Date: Tue, 22 Mar 88 09:52:49 est From: munnari!stcns3.stc.oz.au!dave@uunet.UU.NET (Dave Horsfall) Subject: Computer rolls give indigestion to voters? Heard on the news this morning, in the wake of the NSW State election, that a "computer error" caused a number of voters in the Bligh electorate being registered to vote in the adjoining McKell electorate instead. The Bligh electorate was a hotly contested one, with an independant candidate tipped to unseat the incumbent. (Note for non-Aussie readers - Aussie elections are still done manually, with ticks or numbers placed on a page, but electorate rolls come from a database. I get the giggles whenever I read about those American contraptions!) Dave Horsfall, Alcatel-STC Australia, dave@stcns3.stc.oz dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave ------------------------------ Date: 15 Mar 88 07:20:42 GMT From: hrlaser@pnet02.cts.com (Harv Laser) Subject: Re: "NEW" Amiga virus has arrived in Europe Organization: People-Net [pnet02], Redondo Beach, CA. The following message describes a new virus that has appeared on the Commodore Amiga. The important points for Risks readers are: 1. Like the MacMag virus, this Amiga virus ( the "Byte Bandit virus" ) has infected commercial disks. 2. Unlike previous Amiga virus strains, this one is harmful, crashing the machine. I have edited the original some, my edits are noted in braces {}. Scott Norton 4526P@NAVPGS.BITNET 4526P@NPS.ARPA --------------------------Original message------------------------- Cross posted from the AmigaZone (on PeopleLink) this is one man's experience with the Byte Bandit virus. Me, I've never seen the thing myself, only the SCA variety. I've got a ring of garlic cloves around my hard drive for now..... --------------------------[begin cross post]------------------------ February 29, 1987 Just got the Byte Bandit Virus from a commercial disk, straight out of the box. This is one nasty virus so I thought I would put up some of the features of this virus that maybe you don't already know about. { ... } 2. IT IS NOT NECCESSARY TO BOOT FROM A DISK, FOR THAT DISK TO BECOME INFECTED! That is, ANY write enabled disk will become infected as soon as it is inserted into ANY drive. That's right, just inserting a write enabled disk in df1: will cause that disk to become infected!!!! 3. The virus, once in the computer, will survive a warm boot and will still infect disks upon boot up. 4. VCheck1.2 will not detect infected disks. 5. VCheck1.2 will not detect infected computers. 6. If your machine is infected then re-installing an infected disk WILL NOT cure it because as soon as it is installed (Healed) it will be RE-INFECTED. {"INSTALL" is the AmigaDOS command to write a boot block on a disk - SAN } 7. VirusX will recognize non-standard boot blocks such as the Byte Bandit virus BUT NOT ALWAYS. If your machine is already infected and you put an infected disk in any drive and that infected disk is write-enabled, VirusX will NOT detect it!!! Otherwise VirusX will recognize it as a non-standard boot block. { ... } 9. There is a very complicated countdown mechanism within the virus that keeps track of how a particular disk became infected. { ... } I see this virus as being much more potent and contagious than the SCA virus. This one was created to be destructive, and can be IF we are not careful. A program like VirusX 1.01 that will detect non standard boot blocks is helpful, but not infallible. I usually run my system from a recoverable ram disk that contains my entire workbench disk. Every thing is assigned to the ram disk so that I don't need my workbench disk in any drive. I feel relitively safe so long as I know that my boot disk is clean. VirusX caught that commercial disk as soon as I inserted it in df1:, I became suspicious and checked it out. So long as a program can be run from my workbench then I would feel safe. If it becomes neccessary to boot from another disk then it would be wise to either know that the boot disk is clean or power down after using. If you have to write to other disks then always be sure that they have not become infected. March 4, 1988 Here's some more info on the new Byte Bandit virus. As I told you before, I received this virus on a commercial disk, straight out of the box, direct from the manufacturer. Virus caused crashes. In my last note I stated that the virus causes the Amiga to crash within 10 minutes every time. This is not quite true. A newly infected machine will NOT crash period. (as far as I can tell. Future generations of the self replicated virus as it is passed onto other disks may act differently) From the tests I have performed with this virus it would seem that an infected machine will not crash UNTIL the virus has replicated itself TWICE by FIRST DEGREE INFECTION.(I call first degree infection the infection of another disk by re-booting an infected machine with a write-enabled boot disk. The boot disk receives a first degree infection) After the second disk has been infected the machine will run for about 5 minutes 30 seconds before crashing with a solid blue screen. I have reproduced this effect many times with different generations of the virus. The virus may be passed on many times by second degree infection, without any effect on the source computer. Second degree infection is infection by inserting ANY WRITE-ENABLED DISK into ANY DRIVE of an infected machine WHILE it is already running. The inserted disk will receive second degree infection. { ... } Dave Crane ------------------------------ From: jon%uwafrodo.bitnet@uwavm.acs.washington.edu Subject: "Drive by wire" autos in development Date: Wed, 23 Mar 88 08:38:38 PST The following story appears in RESEARCH AND DEVELOPMENT, March 1988, p.41: FLY-BY-WIRE TECHNIQUES ARE BEING ADAPTED FOR AUTOMOBILE CONTROLS by Irwin Stambler "Fly-by-wire techniques, where electrical signals rather than mechanical linkages or hydraulic components are used to actuate controls in airplanes, are finding a new area of application - automobiles. One of the latest advances in this area is a sophisticaed steer-by-wire algorithm devised by researchers at Univ. of Southern California, Los Angeles, that is being tested in an experimental computerized car built by General Motors Corp., Detroit, MI. Dr. Petrous Ioannou, of USC's School of Engineering, said that the use of a variety of drive-by-wire systems in automobiles is nearer at hand than most people think. 'Recently BMW in West Germany introduced a V-12 drive-by-wire automobile. Now that one company has replaced hydraulic components with electrical ones, the door may be open for many others to follow suit,' he told R&D. The use of computer-controlled steer-by-wire systems offers a number of advantages. "The result would be a car that's significantly lighter...", he said. "A steer-by-wire system would be considerably more responsive and maneuverable." Ioannou and a team of graduate students are in the third year of a five- year program funded by the National Science Foundation to develop automotive control algorithms. The first part of the work involved computer simulation, and the researchers are now collecting data on how the algorithm works in the GM test car. "That car contains and electrical motor connected to a computer which, in turn, receives signals from the steering column. ..." The USC algorithm measures the velocity and and position of a steering section pinion. "Data are examined and the algorithm determines a voltage instruction to the computer to insure that the output of the motor follows a certain pattern. The computer then calculates the forces required to insure [sic] that commands are properly carried out." One important requirement in this application is that the system responds rapidly in situations where a driver needs to perform a sudden maneuver, such as to avoid a collision. "For a sudden turn, the algorithm must be able to determine the required electrical outputs extremely fast, and the system must respond very quickly as well." "We plan to get into braking and other control functions. We don't see this as involving any radical change from what we already have," Ioannou said. (end of excerpts) This article reminded me of a discussion of the possibility of drive-by-wire in RISKS about a year ago. As I recall, many people pointed out that fly-by-wire aircraft cost on the order of 1000 times as much as autos, and are subject to much more intensive maintenance. By the way, can anyone confirm Ioannou's statement that BMW has a drive-by-wire car on the market? Jonathan Jacky, University of Washington ------------------------------ Date: Sun, 20 Mar 88 13:17:30 CST From: umn-cs!srcsip!driscoll@rutgers.edu (Kevin Driscoll) Subject: The COMMON Code Virus In Risk Digest 6.46 Ewan Tempero writes: >>> What was interesting about this was that problems occurred in May 1986. I >>> had no idea that the computer virus had been around that long nor that it My first encounter with a computer virus (definition: a software parasite that replicates itself to a new location) was a quarter of a century ago. I assume that the basic concept is even older. This virus was the first of the COMMON code abuses that I wrote about earlier. The virus was the single instruction: MOVE (Program Counter) --> Program Counter + 1 It had the effect of copying itself to the next memory location, which was then executed . . . At the top of memory, the Program Counter rolled over to zero. Thus, in a matter of milliseconds, the entire memory contained just copies of this instruction (no memory protection in those days). This had an interesting symptom on the control panel. The normal random-like pattern of the address lights became the distinct binary counter pattern. Because every memory cell was overwritten by this process, it left no clues about its origin. (Was this the first single cell computer virus?) Like any virus, the computer virus needs population contact in order to spread. "In the old days", computers were relatively isolated so viruses were contained to single computer sites. Today, with networks, bulletin boards, and the wide spread sharing of storage media, the spread of viruses has become a major problem. The concept of a "clean room" for computers may have to take on a software as well as a hardware meaning. COMPUTER ROOM No Smoking No Food No External Media [And there is no cure for the COMMON code. PGN] ------------------------------ Date: Sat, 19 Mar 88 11:00:19 CST From: umn-cs!srcsip!driscoll@rutgers.edu (Kevin Driscoll) Subject: Lazy Lousy Linkers Leave Large Loophole, Let LowLife Lads Loose The recent discussion of linkers reminded me of the following: In the mid 1960s the university in my home town had an IBM 360 that was used for both administration and student programming courses. Realizing the potentional problems, the administration restricted the student access to punched card Fortran programs. Once an hour, all the student decks were run through a batch compile-and-execute which made sure that these programs did not do anything unsafe. This scheme was bypasssed with: COMMON /IT/I(1000) (fill array I with the integer equivalent of nefarious machine code) CALL IT The compiler made IT an external symbol when it saw the COMMON statement. The compiler then saw that IT was an external symbol in the CALL statement; so it left the resolution to the linker. The linker, not having any type checking, simply put the COMMON address in as the target of the CALL. After getting the operating system's microfiche documentation, the students could make the code in COMMON a starting point for anything they wanted to do. (Nothing made the system more sick than the COMMON code.) On the subject of pilots' reliance on avionics computers -- some pilots, in addition to relying on computers to give them information on the current situation, also seem to use the computers as a replacement for their memory. "What altitude are we supposed to be flying at?" "I dunno, check the computer." This was not the originally intended, nor currently sanctioned, use for this equipment. But, if this is the way it is sometimes used, does this equipment have to be built with the increased reliability needed for this unsanction use? ------------------------------ End of RISKS-FORUM Digest ************************