Text File

RISKS-LIST: RISKS-FORUM Digest Tuesday, 1 December 1987 Volume 5 : Issue 68

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

Contents: Logic Bomb (Brian Randell, ZZASSGL) Re: hyphens & Mariner I (Jerome H. Saltzer) Re: Mariner, and dropped code (Ronald J Wanttaja) Minuteman and Falling Trucks (Joe Dellinger) Re: Fiber optic tap (Mike Muuss) Re: Garage door openers (Henry Spencer) Dutch Database Privacy Laws (Robert Stanley)

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).

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

From: Brian Randell <br%kelpie.newcastle.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Fri, 27 Nov 87 10:57:34 GMT To: RISKS@csl.sri.com Subject: Logic Bomb

Here, in response to Gligor Taskovich's request in RISKS DIGEST 5.65, is an article on the trial here in the UK relating to a "logic bomb". It comes from Computer Weekly, November 26, p. 3, and is quoted here in full. (br)

MAN CHARGED WITH PLANTING TIME BOMB

Criminal damage charges have been brought against a computing specialist who allegedly doctored a customer's software so it would give his firm a contract to put things right. James McMahon, 32, from Watford denies four charges of criminal damage and one attempt at criminal damage to discs and systems belonging to Pandair Freight, obtaining over (pounds)1,000 from Pandair by deception for his company, Wendmist, and attempting to obtain (pounds)372.

In January 1986 Pandair's system in Heston, Middlesex, running on a DEC computer, broke down. Prosecutor David Radcliffe told the court that the problem was caused by a time bomb, inserted earlier. The 1985 version would still work but after McMahon spent time on it things got worse, Radcliffe said. McMahon arranged to work on the faults on returning from holiday. While he was away a Pandair programmer did some tests and found a section of unauthorised code. "He found the time bomb and defused it," Radcliffe said. The programmer then looked at a similar system at Pandair's Birmingham office. Here he found a time bomb which would have erased the computer's memory.

Radcliffe suggested McMahon had acted out of revenge, because he had just failed to win a (pounds)50,000 contract to update Pandair's system at Maidenhead. Pandair says the system problems cost it (pounds)15,000.

This is believed to be only the second case of alleged criminal damage of its kind. The first, last year, followed a farewell prank by a Dixons employee who tried to get the company's mainframe to display "goodbye folks" whenever his leaving date was entered in staff records. he was conditionally charged and orderd to pay Dixons (pounds)1,000. John Kavanagh

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

Date: Mon, 30 Nov 87 12:35:49 GMT From: "ZZASSGL" <ZZASSGL@CMS.UMRCC.AC.UK> To: risks@csl.sri.com Subject: UK Logic Bomb Case

[This contribution included TWO news reports, including excerpts from the article noted above. It also commented thereupon. PGN]

Both reports are somewhat confusing about the actual details, but the basic facts seem simple. McMahon did some work on the system, was expecting to get a contract for more, but didn't. Shortly after the system had problems and when Pandair programmer investigated he found the ''bombs''. As the case is still proceeding it is not possible to connect these two facts.

I remember reading an earlier report (I can't find it now) about the problems that were expected because the jury would have to understand the background and jargon before being able to decide the case. They were all provided with a glossary for the technical terms to be used and also given a one day introduction to computers and DEC systems.

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

Date: Sun, 29 Nov 87 01:30:11 EST To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@KL.SRI.COM> Subject: Re: hyphens & Mariner I From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>

As long as people are still searching for the real story, here is another possible clue, based on yet another third-hand rumor: Back in 1962, when Mariner I failed, the story that quickly circulated around M.I.T. was that a minus sign had been miscoded as a hyphen. You see, the keypunches in those days had two different keys with similar-looking graphics, one interpreted as a minus sign, the other as a hyphen. The first Fortran compiler accepted only the minus sign for the subtraction operator. At one point in the evolution of that compiler a (fatal!) diagnostic was added to alert you that you had used the "wrong minus sign," leading to snide comments along the line of "if you're so smart, why don't you fix it?" and a standard test of skill was to figure out how to patch the Fortran compiler to accept a hyphen as an alternate minus sign. When a hyphen appeared in data, the result depended on the software that was trying to interpret it; some programs accepted it as an alternate minus sign, other programs ignored hyphens (effectively reversing the intended sign), and still other programs blew out with a bad data diagnostic. Given that kind of confusion every day in the keypunch room, when the rumor about Mariner I came through it sounded very plausible.

Whether or not Mariner I was a victim of hyphen/minus-sign confusion, the keypunches of the late 50's carry a cautionary tale for RISKS readers.

Jerry Saltzer [Hyphen the Terrible? PGN]

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

Date: Fri, 27 Nov 87 00:25:40 pst From: ucbcad!ames.UUCP!uw-beaver!ssc-vax!wanttaja@ucbvax.Berkeley.EDU (Ronald J Wanttaja) To: uw-beaver!KL.SRI.COM!RISKS Subject: Re: Mariner, and dropped code

I was in a NORAD satellite operations unit for four years, and "I was there" during several times when erroneous attack warnings were generated.

One sticks in my mind... it wasn't caused by a missing hyphen, or replacing a period with a comma, but by an INCORRECT VALUE OF *PI*! I dearly wish I had bothered to find out what the value had been, but, considering the circumstances of the error, it probably was in one of the later decimal places.

The system worked as advertised and the attack warning was quickly cancelled.

[This and Jerry Saltzer's contributions are just two of many that have been backlogged. More is coming... PGN]

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

Date: Mon, 30 Nov 87 02:46:45 pst From: Joe Dellinger <joe@hanauma.STANFORD.EDU> To: risks@csl.sri.com Subject: Minuteman and Falling Trucks

I was curious to find out how often incidents such as the "truck parked on the missile silo door" one mentioned here really occur, and how stupid this response really was. As it happens, my brother was until a few years ago the commander in charge of missiles at a Missouri base. While the answers to some of my questions were classified, here's what he said (as I understood it): False "launch in progress" status warnings aren't that rare. He saw about one per year at his base. There is a definite set of procedures to perform when this happens. Parking a truck on top of the silo door such that it will fall in on top of the missile if the door opens is one of them. The people that did this were doing the officially approved thing! The truck is to be parked such that one set of wheels is on terra firma and the other set is on the silo door. The truck is to be left in neutral with the parking brake off. The door itself is designed to open despite any debris on it, and there is a lip of sorts on the door to keep the debris from falling off the door and onto the missile. However, this lip can't handle more than a few inches worth of debris. The truck, properly parked, has no way of riding the door and will fall something like several hundred feet onto the missile. The damage thus inflicted should serve to "keep the missile in the hole". Worst possible outcome (unlikely to happen) is that the missile detonates its nuclear warhead in the hole, resulting in a quarter-mile wide crater and some local contamination. The silo door can be opened and closed with a hand crank, but even if you know all the required access codes (which no one person does) you don't have time to get to the crank before the security people have time to get to you. I've seen a field where missiles are kept. Looked just like any other farmer's field in the area to me, except that the "keep out" signs were especially intimidating and there were no cows in it. I was amazed to discover that the missile field was right next to a state highway! - joe@hanauma.stanford.edu

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

Date: Tue, 1 Dec 87 16:20:52 EST From: Mike Muuss <mike@BRL.ARPA> To: risks@csl.sri.com Cc: ABC@BRL.ARPA, Towson@BRL.ARPA, Randy@BRL.ARPA, ACST@BRL.ARPA Subject: Re: Fiber optic tap

Your message is neither surprising, nor is it "news". The device used by AT&T to splice cables "in the field" has used this principle for years. The device is suitcase-sized, rugged, portable, and inexpensive (< $100k). It injects a signal on one side of the splice, monitors the signal on the other side of the splice, and mechanically optimizes for the maximum transmission through the splice, then heat-welds the two fibers. The signal injection and recovery is non-intrusive and non- damaging, and very very easy.

Dr. Steve Wolff (now of NSF, formerly of BRL) jointly holds a patent for a spatial light modulation technique that renders this type of tapping useless. However, to my knowledge, there are no production modulators that embody this technique.

In summary, only physical security and encryption provide acceptable security for important transmissions. -Mike Muuss, Advanced Computer Systems Team, BRL

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

Date: Fri, 27 Nov 87 12:33:09 EST From: mnetor!utzoo!henry@uunet.UU.NET To: RISKS@kl.sri.com Subject: Re: Garage Door Openers

> An Army spokesperson denies that the Army is radiating anything that > would lock up these receivers.

What they may actually have said, or meant to say, is that they are not radiating anything that *should* lock up those receivers. Much consumer electronic equipment is cheaply (in both senses of the word) designed and is very vulnerable to interference from signals that theoretically it should ignore. Things like ham-radio transmissions interfering with TV reception are often the fault of the TV set, not the perfectly-legal-and-proper radio transmitter. The problem actually is not restricted to consumer equipment; things like police radars are often rather unselective as well.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

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

To: "utcsri!ai.toronto.edu!watmath!comp-risks" From: Robert Stanley <roberts%cognos%math.waterloo.edu@RELAY.CS.NET> Subject: Dutch Database Privacy Laws Date: 27 Nov 87 19:50:18 GMT

The following is an extract from a recent posting to comp.society.futures. This is a very advanced approach to the problem, and it would be extremely interesting to have more detail on the law in question. The issue of implementation is not totally resolved, however. I assume that the law requires each GOAL to be registered, and that some agency is empowered to audit and/or investigate (the latter only in the event of reasonable suspicion of misuse). But how do we prevent the meta-database of database GOALS from being misused - quis custodiet ipsos custodes remains true as the day it was written.

| From: FRUIN@HLERUL5.BITNET.UUCP | Newsgroups: comp.society.futures | Subject: Filtering A Global Hypermedia Network | Organization: The ARPA Internet | Posted: Fri Nov 20 08:18:00 1987 | | In Holland a new law will soon take effect regarding databases that store | information about people. It's basic premise is that a database should have | a GOAL, i.e. to send you your electricity bill or to keep track of your car's | registration number. It is FORBIDDEN two match or combine any two databases | that don't have the same goal. You can take anybody to court who does so | anyway. This should make it very hard for corporations and government agencies | to access any information about you. | | -- Thomas Fruin | | fruin@hlerul5.BITNET | thomas@uvabick.UUCP | 2:500/15 on FidoNet | | Leiden University, Netherlands

On a slightly different subject, I am becoming increasingly aware of a new computer-related problem which may yet develop into a full-blown risk. In our working environment we are pretty well established as workstation-per-user, and the technology of networking means that it is sometimes easier to relocate people rather than reconfigure electronic offices. We have a fair number of tools for which we have site licenses limiting us to x copies (x <= 5 for our group of 18 is typical). What we want is ability to run no more than 5 simultaneous copies at any of 18 workstations, what we have is software enabled on 5 specific workstations. Not only is this damnably awkward at times, but it can introduce a number of problems.

First of all, there is the classic problem of protected software. We use Sun/3 workstations, and the first engineering response to problems is swap out the processor board (our workstations are single-board). At this point we are in the identical position of the person who has irretrievably damaged their key-disk for a copy-protected micro product, because the workstation's serial number has changed. We have a company policy that pretty much says that no critical data will be dependent on a program for which we cannot generate replacement/alternate versions in case of emergency.

The second problem is when installation of software changes the workstation in subtle but important ways. When people shift workstations in order to access one of these restricted applications, the displaced owner can find him/herself misusing the (temporary) alternate environment. Once you have worked for a while on a configurable workstation, you rapidly forget how much of its behaviour is default, and how much is your customizing. Until, that is, you find yourself in an environment which appears almost the same, but behaves drastically differently in some key and unobvious fashion. Of course, there are ways round this, but the problem is a direct result of lazy or sloppy thinking on the part of the application vendor.

The vendor solution is to have a copy of their software on every workstation, but that is a totally unacceptable solution from the cost standpoint unless some massive price breaks are introduced. Interestingly, as standards such as X come into common implementation, we may end up remote-logging-in to a software server to which such tools are licensed, with X supplying the full interactive graphic windowing capability at the remote workstation. Back to the days of time-sharing a central computer!

R.A. Stanley Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1440 (Research: there are 2!) 3755 Riverside Drive FAX: (613) 738-0002 Compuserve: 76174,3024 Ottawa, Ontario uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts CANADA K1G 3Z4

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

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