Text File

RISKS-LIST: RISKS-FORUM Digest Monday, 23 November 1987 Volume 5 : Issue 63

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

Contents: Logic bombs and other system attacks -- in Canada (PGN) Video signal piracy hits WGN/WTTW (Rich Kulawiec) Garage Door Openers (Brint Cooper) Sudden acceleration revisited (Nancy Leveson) Centralized Auto Locking (Lindsay F. Marshall) Re: The Stark incident (Amos Shapir) Bank Networks (George Bray) Re: Optimizing for cost savings, not safety (Dave Horsfall) L.A. Earthquake & Telephone Service (LT Scott A. Norton, USN) Gripen flight delayed (Henry Spencer) Mariner 1 (Mark Brader) Systemantics (John Gilmore, haynes) [Old hat for old RISKers] Re: "UNIX setuid stupidity" (Joseph G. Keane, Martin Minow)

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: Mon 23 Nov 87 13:27:25-PST From: Peter G. Neumann <Neumann@KL.SRI.COM> Subject: Logic bombs and other system attacks -- in Canada To: RISKS@KL.SRI.COM

An article by Kirk Makin in the Globe and Mail, 3 November 1987, describe a talk given by Sergeant Ted Green of the Ontario Provincial Police at the recent annual conference of the Probation Officers Association of Ontario.

* A disgruntled employee of a London, Ontario, company planted a logic bomb that would have knocked out the computer system. It was detected. The man was prosecuted, but not convicted. Evidence of a previous logic bomb implantation was not admitted because the previous company (in Alberta) had refused to press charges.

* Another Toronto company had a logic bomb triggered the day an employee's termination notice was processed by the computer system. Sgt Green noted that "It wiped out the whole system."

* On the occasion of its 10th anniversary, a bank branch decided to honor the customer who had the most active account. It turned out to be an employee who had accumulated $70,000 funnelling a few cents out of every account into his own.

* On employee altered an access password and demanded $50,000 to reveal the new password. Apparently he got it.

* One Toronto student recently made 2177 attempts to enter the computer system of Alcan Aluminium's Kingston, Ont., plant.

Sgt. Green also noted $1000 in computer-initiated bogus charges, a[nother] bogus bank deposit slip scam attempt, and a case of a Toronto-area machinery supplier using mailing lists and blueprints extracted from a rival's computer.

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

Date: Mon, 23 Nov 87 17:20:56 EST From: rsk@s.cc.purdue.edu (Rich Kulawiec) To: risks@csl.sri.com Subject: Video signal piracy hits WGN/WTTW

At about 9:15 CST last night (Sunday, November 22, 1987), "superstation" WGN-TV (Channel 9 in Chicago) was the victim of an interesting technological crime; its signal was overridden for approximately 15 seconds by a pirate transmission. The incident was repeated at about 11:15 CST, with WTTW (Channel 11, the Chicago PBS station) falling prey on the second occasion, which lasted about 90 seconds.

The transmission, which interrupted a newscast on WGN and "Dr. Who" on WTTW, consisted primarily of someone in a Max Headroom mask throwing Pepsi and Coke cans around while raving in a largely unintelligible voice. The transmission concluded (I'm not kidding) with a shot of the Max-impersonator's exposed derriere' being whacked with a flyswatter. The video quality of the transmision was fairly good, but the audio was very garbled. I happened to be taping Dr. Who at the time, and so I've watched the broadcast several times; even so, I can't understand more than a word or two.

A couple of phone calls (to the local cable TV company, and to WTTW) led to a little more information; it is likely that the pirate transmission was inserted somewhere in the Chicago area, as it was distributed over WGN's satellite link and WTTW's (land-based) microwave links. If my information is correct, WGN has the capability of switching to a second frequency for the uplink portion of its broadcast chain, but it's not clear whether they actually did so during or after the incident. WTTW does not have this capability, and the person I talked to on the phone sounded (understandably) a little worried that this might happen again.

As one might expect, the FCC and the FBI, among other agencies, are investigating. It seems likely to me that the culprit found a point through which WGN's and WTTW's signals both pass, and tapped in at that point; while this certainly isn't the only way that this piracy could be accomplished, it seems the easiest. Rich Kulawiec, rsk@s.cc.purdue.edu, s.cc.purdue.edu!rsk

[This is becoming almost too frequent, but still worth noting. PGN]

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

Date: Thu, 19 Nov 87 11:40:39 EST From: Brint Cooper <abc@BRL.ARPA> To: risks@csl.sri.com Subject: Garage Door Openers

This morning's Baltimore Sun tells of folks in Frederick, MD, who are having great difficulty with their remotely controlled garage door openers. It seems that, installed in their houses, these things have just stopped responding to commands from the hand held unit. However, when taken back to the point of purchase, they work just fine.

The U.S. Army has an installation, Ft Detrick (sp?) nearby. One of its two functions has something to do with electronic communications. An Army spokesperson denies that the Army is radiating anything that would lock up these receivers. _Brint

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

To: risks%csl.sri.com@ROME.UCI.EDU Subject: Sudden acceleration revisited Date: Mon, 23 Nov 87 08:50:21 -0800 From: Nancy Leveson <nancy@commerce.UCI.EDU>

There was just a report on the NBC news (Sunday, Nov. 21 at 4:30 pm PST) on the sudden acceleration problems with the Acura Legend. The Acura dealers say it is driver error. The drivers all say they have been driving for 30-40 years without an accident or a ticket and they insist they had at least one foot on the brake (one woman said she had both feet on the brake). A mechanic who has been examining one of the cars involved says it is obviously a problem in the fuel injection system, and he is sure that the computer is involved.

Does anyone know if there is any connection between the microprocessor used in the Acura and in the other cars with this problem, e.g., the Audi 5000?

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

From: "Lindsay F. Marshall" <lindsay%kelpie.newcastle.ac.uk@NSS.Cs.Ucl.AC.UK> Subject: Centralized Auto Locking To: risks@kl.sri.com Date: Mon, 23 Nov 87 11:19:20 GMT

My father spotted a report in a paper about someone who was trapped in a car when the central locking mechanism went haywire. The person in question was too large to escape by climbing through the window, which was how some of the other passengers got out. Sadly I have no more details about this as my father couldn't remember where he had seen it - it sounds like a FOAF story ("friend of a friend" story - urban legend, if you're a sociologist), but I'd be interested if anyone else has heard it. Lindsay

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

To: nsc!comp-risks@Sun.COM From: nsc!taux01!taux01.UUCP!amos@Sun.COM (Amos Shapir) Subject: Re: The Stark incident (RISKS DIGEST 5.62) Date: 22 Nov 87 09:38:59 GMT Organization: National Semiconductor (Israel) Ltd. Home of the 32532

It looks like the culprit in this case was whoever decided to classify incoming missiles into 'hostile' and 'friendly' categories - did they think that a friendly missile fired by mistake should behave any friendlier than a hostile one?

Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com (used to be amos%nsta@nsc.com) 34 48 E / 32 10 N

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

Date: Fri, 20 Nov 87 13:02:58 PST From: George Bray <lcc.ghb@SEAS.UCLA.EDU> To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@KL.SRI.COM> Subject: Bank Networks (Re: RISKS-5.61)

I have two comments on the article in RISKS 4.61 by David G. Grubbs:

>(VISA card numbers all start with 4, Master Card with 5, AMEX with 37, etc.)

Actually, AMEX cards can begin with 34, 35, or 37. (Nit-picky, I know.)

> Our money is managed by people who care nothing for the details of > an single transaction. They sell financial services like the grocer > sells apples. So what if a few are dropped on the floor? It's just a > "cost of doing business." As the throughput of transactions increases over > time, each detail gets commensurately smaller. It can only get worse.

That is quite true. In my days working for a bank (which actually was better than most about it) I was often astounded at the cavalier attitude towards a single transaction. Of course, from the point of view of the bank, fixing a major problem in the middle of the day (one that was costing thousands of dollars an hour) is clearly vital, but I couldn't help worrying about the poor customer who happened to go up to an ATM during the 10 minutes the front-end processor was being downloaded, or during any other downtime in the middle of the day. From the bank's point of view, a few transactions lost out of half a million or more a day is minor. From the customer's point of view (who is late for a flight and needs cash), that one transaction is critical. George Bray

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

Date: Sat, 21 Nov 87 01:33:04 AESST From: munnari!runx.ips.oz.au!dave@uunet.UU.NET (Dave Horsfall) To: RISKS@kl.sri.com Subject: Re: Optimizing for cost savings, not safety (RISKS-5.57)

> Re: Optimizing for cost savings, not safety (John McLeod) >From: bill@trotter.usma.edu (Bill Gunshannon) > A letter was published in an amateur radio oriented magazine called QST >a few years back by a ham who tried to install a UHF mobile radio in his >newly purchased Japanese import. He too had problems with interference to >the electronic ignition in the car. A call to the US Service Representative >for the cars manufacturer resulted in a very simple solution to the problem. >They told him "don't install the radio in the car". > > A novel approach to preventing interference. > bill gunshannon

Another "informed" reply that appeared in an amateur radio magazine was: "Try shielding the antenna". And these people design cars? -- Dave

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

Date: Fri, 20 Nov 87 15:17:09 PST From: "LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu> Subject: L.A. Earthquake & Telephone Service To: Risks Forum <Risks@csl.sri.com>

The December 87 issue of The Institute: News Supplement to IEEE Spectrum has a short but interesting article on the effect of Oct 1st's Los Angeles earthquake on the utilities. Most of the article deals with electric power, which had the most problems ( but still minor ). But a few paragraphs on the telephone service should be of interest to RISKS readers.

The article points out that telephone network was largely undamaged by the quake because many lines have recently been replace by fiber optic cables that were installed with a large amount of slack, which permitted them to move without breaking during the quake.

As we already know, many subscribers were unable to get dial tones after the quake. I thought "Lots of people calling relatives tied it up", which was a factor, but The Institute reports that most of the delays resulted because the quake knocked phone receivers off the hook. Of course, anxious and curious callers also tied up the lines, and two central offices lost power intermittently.

Can anyone with better knowledge of the phone companies' local offices tell me if there is some simple way to shed this extra load in a reasonable way? I know that after some minutes off the hook, the phone loses its dial tone. Does this adequately release the resources the off-the-hook phone was using?

LT Scott A. Norton, USN | From Internet, if you need a gateway, use Naval Postgraduate School | 4526p%navpgs.bitnet@jade.berkeley.edu Monterey, CA 93943-5018 | or 4526p%navpgs.bitnet@ucscc.ucsc.edu 4526P@NavPGS.BITNET | The WISCVM gateway will close 15 Dec 87. )

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

Date: Tue, 17 Nov 87 21:04:31 EST From: mnetor!utzoo!henry@uunet.UU.NET To: RISKS@kl.sri.com Subject: Gripen flight delayed

The Oct 5th Aviation Week reports that first flight of Sweden's new Gripen fly-by-wire combat aircraft will slip about eight months due to software development delays. This is on top of a previous six-month slip for the same reason. This is the last slip that can be absorbed without delaying the operational service date (1992). No real details were provided; on the surface it would appear that things are going well but unexpectedly slowly, and prime contractor Saab-Scania is just being cautious.

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

[Yes, this is a risk commonly attributed to computers, but it is hardly novel. It is included to remind us of the dependence on the software development process... PGN]

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

Date: Sun, 22 Nov 87 12:34:05 EST From: msb@sq.com (Mark Brader) To: neumann@csl.sri.com Subject: Mariner 1 Cc: utzoo!henry@uunet.UU.NET

* A rocket on the way to Mars has to be destroyed because a crucial line is left out of the computer software controlling it.

Presumably the above refers to Mariner 1. This is about the fourth or so version that I've heard of what the actual error was. Arthur C. Clarke says it was a missing "-". Others say that a "." was typed in place of a "," in a Fortran DO statement (thus turning it into an assignment).

Peter, do you know of a reference that tells authoritatively what the actual bug was? Normally I'd consider ACC authoritative, but the version he tells doesn't seem to appear anywhere else, so maybe not this time.

I posted the same question to sci.space a year or two ago and got no takers.

Mark Brader, Toronto, utzoo!sq!msb, msb@sq.com

[We've tried this one before, but perhaps someone new has joined us. PGN]

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

Date: Sat, 21 Nov 87 06:32:18 PST From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) To: RISKS@KL.SRI.COM Subject: Systemantics

David Chase's recommendaion of "Normal Accidents" reminded me of the book "Systemantics" which I read years ago and can no longer remember the vitals of. Its premise, well explored and humorously explained, is that sufficiently complex systems always have unexpected behaviours.

I suspect it's another RISKS cornerstone. John Gilmore

["Systemantics" by John Gall. Although humorous, in the spirit of Parkinson's Law, it has some great truths, such as

"Fail-safe systems fail by failing to fail safe."

haynes@ucscc.bitnet, ...ucbvax!ucscc!haynes]

[Legendary! Previously noted in RISKS by Jim Horning, RISKS-1.2; Earl Boebert, RISKS-2.16; Hal Murray, RISKS-2.18. Consult your local Books-in-Print. PGN]

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

Date: Sat, 21 Nov 87 10:51:03 -0500 (EST) From: "Joseph G. Keane" <jk3k+@andrew.cmu.edu> To: risks@sri.com Subject: Re: "UNIX setuid stupidity" (RISKS-5.57)

The designers of UNIX considered that a trusted program may wish to allow operations only on a certain part of the directory tree. So they provided the `chroot' system call, which allows a program to do just that, in a secure way. I was surprised as i saw the argument go by with no one mentioning this, but maybe i shouldn't have been. I guess the moral is that a feature doesn't do you any good if no one knows about it.

--Joe

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

From: minow%thundr.DEC@decwrl.dec.com (Martin Minow THUNDR::MINOW ML3-5/U26 223-9922) Date: 23 Nov 87 09:02 To: risks@csl.sri.com Subject: further comment on setuid problem

From Risks 5.62: >From: munnari!basser.cs.su.oz.au!steve@uunet.UU.NET (Stephen Russell) ... >This raises the interesting question of who is responsible for this security >bug - the person who wrote the buggy program, or the programmer who >installed it without vetting it?

Perhaps one might add to this list the people who designed an error-prone capability, or the people who failed to document the way in which a security-enhancing function can -- though used with good intent -- serve to decrease the security of the system. Martin.

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

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