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
************************