RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (11/24/87)
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 Novermber 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 turnted 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
************************
-------