RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (04/12/88)
RISKS-LIST: RISKS-FORUM Digest Monday 11 April 1988 Volume 6 : Issue 58
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Computers are a drain on police cruisers (Mark Brader)
What happened to personal responsibility? (George Michaelson)
Re: Intolerant Fault-Tolerance (Tom Lane)
Another Security Clearance Story (Ronald J Wanttaja)
A new VMS security hole? (Jonathan Corbet)
Re: Notifying users of security problems (John O. Rutemiller, William Smith)
April Fool's Warning (Piet Beertema)
Viruses (Fred Cohen)
Virus Distribution (Peter G. Rose)
Re: The "(c) Brain" virus is not a new virus. (Rob Elkins)
There is a VT220 with block mode available from DEC. (David E A Wilson)
Enfranchising the disenfranchised: our responsibility? (Tom Betz)
Discrimination and careless arguments (David Thomasson)
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 in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).
----------------------------------------------------------------------
Date: Sun, 10 Apr 88 16:26:24 EDT
From: msb@sq.com (Mark Brader)
Subject: Computers are a drain on police cruisers
Abridged from an article by Jack Lakey in the Toronto Star, April 9, 1988.
Booster cables are fast becoming the Metro[politan Toronto] police officer's
best friend.
Deputy Chief Bill McCormack says the force is having problems with batteries
dying in some police cruisers equipped with both computers and radios.
However, McCormack denied that the dead batteries are compromising the ability
of the force ... to respond quickly to emergencies. "We always have cars
available on an emergency basis... But I quite agree that it's a problem and
some of the equipment we have in place is the cause of it."
The computer and radio draw power from the battery when the cruiser isn't
running. ... At the scene of a murder ... last Sunday, a Star reporter watched
as two cruisers -- both Plymouth Caravelles -- needed boosts from other police
vehicles to get started. An officer driving the second vehicle said many
cruisers equipped with radios and computers were having similar problems. ...
the force uses heavy-duty batteries in the cars. Two suspects in the murder
were arrested ... another Star reporter watched police boosting a third cruiser
that wouldn't start.
Police have noticed the problem is most common to a particular year and model,
but McCormack didn't want to identify the manufacturer. "We're going to be
consulting with the manufacturer on finding a way to upgrade the power to the
battery ... But we are finding that it happens with the older cars or spares."
Allan Gibb, fleet administrator for the ... Metro police, said the power drain
was an "operational problem" common to any vehicle heavily equipped with
electronics. However, police departments in Winnipeg and Calgary, where most
cruisers are equipped with computers, said they haven't had any problems
maintaining battery power.
Abridged and posted by Mark Brader
------------------------------
Date: 09 Apr 88 12:20:35 +1000 (Sat)
From: munnari!ditmela.oz.au!george@uunet.UU.NET
Subject: What happened to personal responsibility?
I've just finished re-reading L.T.C Rolts classic 'Red For Danger'
which is an updated version of the book, with new text by G Kichenside.
-alas Rolt died in 1974 and this edition was published by PAN in 1986.
This book should be required reading for all COMP.RISK-ers.
Technology *always* brings problems of "risks", and how we dealt
with those faced yesterday lends weight to how we could/should
approach similar problems today.
Reading the book I was struck by how often Rolt said (obvious BNF paraphrase):
"...at the board of enquiry the {<driver>|<guard>|<signalman>|<other>}
was rightly found innocent of the charge of manslaughter due to
{<extenuating circumstances>|<genuine act-of-god>} ..."
Rolt also highlights the problems the Inspectorate faced persuading
Railway Companies to adopt basic working practice, or upgrade equipment
to be in line with current practice. Then as now there was an ongoing
design cycle, existing systems were being kludged to work under increasing
loads and beyond design parameters.
(1) even though "hardware" failed in many cases, a bolt sheared,
a retaining wall collapsed, a signal was not visible SOMEONE
stands up and says "yes, it was my responsibility". They could
be "let off" but it wasn't possible to say "the machine was
to blame".
(2) *when* hardware failed, "rules" were changed to reflect
experience, designs re-worked, fail-safe factors increased.
the problem was getting $-obsessed people to become accountable
for the consequences of $-based decisions.
(3) "software" (I think the rules governing single-track usage
and point-settings and even how to behave when a train stops
in an emergency can be described as programs can't they?) was
very often to blame, but usually the problem lay with human
"interpretation" of the rules, or conflict in their application.
Railways are among the most public users of computer-based systems
we have. To sit in a 30mph steam train was not only a joy, you placed
your life in the hands of engineers who were ultimately accountable. To
sit in a 125mph bullet train or a high-speed local subway is no longer
quite so joyful. You *still* place you life in the hands of the company,
but is it the Engineers, software or otherwise that carry the can?
-George Michaelson
ACSnet: G.Michaelson@ditmela.oz.au
Postal: CSIRO, 55 Barry St, Carlton, Vic 3053
Phone: (03) 347 8644 Fax: (03) 347 8987
------------------------------
Date: Sat, 09 Apr 88 19:26:19 EDT
From: Tom.Lane@ZOG.CS.CMU.EDU
Subject: Re: Intolerant Fault-Tolerance
Here's another "amen" to Tim Mann's and Jerome Saltzer's comments about
reporting faults masked by fault-tolerant systems (RISKS 6.53, 6.54).
I have another example to add to the list.
For the past several weeks, considerable net bandwidth in Usenet newsgroup
comp.sys.hp has been devoted to discussion of a posted set of benchmark
numbers, which allegedly demonstrated that a certain new HP machine was not 3x
faster than its predecessor (as claimed by HP), but actually more like 15x
slower. Other people were unable to duplicate the original poster's results.
It eventually emerged that the machine he tested had a bad floating-point
processor. The operating system detected this at bootup and *silently*
installed software emulation traps for all the floating-point instructions...
tom lane
BITNET: tgl%zog.cs.cmu.edu@cmuccvma
UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl
------------------------------
Date: Thu, 7 Apr 88 23:10:30 pst
From: ames!uw-beaver!ssc-vax!wanttaja@ucbvax.Berkeley.EDU (Ronald J Wanttaja)
Subject: Another Security Clearance Story
It's one thing to be truthful on a background questionare for a security
clearance. It's entirely *another* thing when nothing in the chain...
human or computer... actually LOOKS at the data input!
This I'm afraid, is one of those "friend of a friend" stories you hear in
the high-security world. But it certainly seems possible.
A person was filling out the background investigation form for a clearance,
when he came upon the question,
"Have you or any member of your family ever attempted to
overthrow of the government of the United States?"
The guy thought about it for a while. Then answered 'yes.'
Months went by. His questionaire routinely traveled up the chain.
Finally, someone noticed his response to that question. Down came the
FBI, hauling our hero off to one of those high security interview rooms:
"Why did you answer yes to that question?"
"Because it's true."
The Feds leaned closer and invited him to explain.
"It's true. My Great-great grandpappy fought for the South during the War
Between the States" (Civil War to you Yankees)
They changed the question to read "Have you or any member of your IMMEDIATE
family..."
Ron Wanttaja
------------------------------
Date: 9 Apr 88 17:25:40 MST (Sat)
From: gaia!jon@husc6.harvard.edu (Jonathan Corbet)
Subject: A new VMS security hole?
It was interesting to read Andy Goldstein's remarks on DEC's new policy on
security patches. Such a policy was certainly needed after the delays
associated with the SECURESHR problem last fall.
What made it more interesting, though, was the arrival, via Federal Express, of
another one of those urgent-install-it-right-now patches from DEC yesterday
morning. Yes, it is another security patch, but this time, nobody seems to
have heard about the hole yet. It looks to me like DEC is living up to its
word on this one. Good news.
But, now that the cat is out of the bag, does anybody out there know what the
situation is? This patch contains about 1200 blocks of stuff -- lots of fixes!
Jonathan Corbet
National Center for Atmospheric Research, Field Observing Facility
------------------------------
Date: Fri, 8 Apr 88 10:43 EDT
From: "John O. Rutemiller" <Rutemiller@DOCKMASTER.ARPA>
Subject: Re: Notifying users of security problems
I believe the procedure outlined by Andy Golstein in RISKS 6.54 is a sound way
to manage the problem, with acceptable compromises. Eric Postpischil's work
arounds in RISKS 6.56 fail to take a couple of points into consideration.
> Almost every site has a big red button (or equivalent) that will make
> any computer system secure, and a very few sites might have information
> sensitive enough to warrant the button's use.
This big red botton may do wonders in keeping intruders out of the system, but
it also prevents users who NEED to do work from accessing the system. Also,
your reasoning seems to indicate that the system should stay in this state
until the security flaw is fixed. How long will that be? Can your site stand
to be down for one month or maybe longer?
> For another few sites, the VMS software might be only a portion of
> their computing resources, a portion they can do without or with
> limited use for a period.
Emphasize the word FEW.
> Many sites can restrict accounts, temporarily removing general
> accounts.
Removing general accounts (the existence of which has its own problems)
does not prevent attacks from those with valid accounts.
> And other sites may be satisfied with establishing some sort of
> auditing procedures so they can tell who is being naughty and stop it
> if not prevent it beforehand.
If you simply announce that a flaw exists without a fix, the most
auditing will tell you is that you have just been had. :-)
John Rutemiller
------------------------------
Date: Fri, 8 Apr 88 15:24:23 cdt
From: wsmith@m.cs.uiuc.edu (William Smith)
Subject: Re: notifying users of security bugs
>From: goldstein%star.DEC@decwrl.dec.com (Andy Goldstein)
>Subject: Re: Notifying users of security problems
>So we get to the critical distinction between security bugs and
>others: Because invocation of a security bug requires a deliberate,
>unusual action, a security bug is only harmful to an installation when
>malicious users gain knowledge of the bug.
This is patently false. If my Unix kernel has a security bug that let anyone
delete a file owned by root, and I *accidentally* (not maliciously) type rm *
while I am accidentally in /, I will have invoked the security bug and force
the sysadmin to reload the system. Or, if I misspell a command and execute a
different command that causes the system to crash, the security bug is still
harmful, but I am am not malicious.
You need to protect the system from inadvertant misuse by normal users as much
as you need to protect it from malicious users. Each system adminstrator
should have the right to decide which set of users is more prevalant at his or
her site and act accordingly. Some sites require their administrators to be
paranoid as you are suggesting. Other sites can fire or remove the accounts of
malicious users and do not need to be paranoid. A simplistic model of the risk
of system security bugs says that (bug + malicious-user) => danger. A more
accurate analysis would also say that (bug + hapless-user) => danger. How
likely a user might stumble over the bug is also a factor. To fix an obscure
bug may not be worth the risk of breaking the operating system when the fix is
installed.
Bill Smith pur-ee!uiucdcs!wsmith wsmith@a.cs.uiuc.edu
------------------------------
Date: 10 Apr 88 18:47:13 EDT (Sun)
Subject: Viruses
From: fc@ucqais.uc.edu (Fred Cohen)
For details on theory of computer viruses, call Fred Cohen (513)475-6575
We can detect all viruses, but cannot decide whether or not a program is
infected. That is, if we detect all files as suspects of containing viruses,
we catch all viruses. Whether or not a program contains a virus is undecidable
(i.e., we cannot write a program that determines whether or not another program
contains a virus correctly and in finite time in all cases). I suspect that
the Israeli defense is useless against most of the viruses we have done
experiments on - I wish I was on the attacker's side of that bet!!! - FC
------------------------------
Date: Mon, 11 Apr 88 16:28:13 +0200
From: mcvax!cwi.nl!piet@uunet.UU.NET (Piet Beertema)
Subject: April Fool's Warning (Re: RISKS-6.55) [The last word was the first!]
>Subject: April Fool's warning from Usenet
>From: spaf@cs.purdue.EDU (Gene Spafford)
> ==================================
>Date: 1 Apr 88 00:00:00 GMT
^^^^^^^^^^^^^^^^^^^^^
[Piet points out that the key line that I inadvertently deleted
-- and already noted so doing -- was the path:]
... which contained ...!kremvax!perdue!spaf
(kremvax was one of the sites warned for!).
[Piet of course is famous as the perpetrator of the Chernenko hoax four
years ago. That was the Ur-hoax and deserves many kudos. RISKS has
received quite a few queries from neophytes who were not around on 1 April
1984. They may find the message "from" mcvax!moskvax!kremvax!Chernenko and
the delightfully annotated ensuing responses in their entirety -- including
all of the header stuff! -- in ACM SIGSOFT Software Engineering Notes vol 9
no 4, July 1984, pp. 6-8. Or ask Piet if he still has it on line. PGN]
------------------------------
Date: Mon, 11 Apr 88 19:27 EDT
From: EAE114%URIMVS.BITNET@MITVMA.MIT.EDU
Subject: Virus Distribution
Will Martin's fears about a possible Virus in a 'computer Interview' seem a
little overblown to me. In the first place, putting your address on your virus
sounds like a good idea to get yourself in serious trouble. (How hard/easy is
it to trace someone through a mailing address? Does the Postal service have
ANY verification?) Anyway, if your really concerned about a diskette, just
park the head on your hard-disk, or pull its cable, or whatever, and run the
diskette in isolation. Then just be sure to power-down before you do anything
else.
I've heard rumors that the Macintosh OFF switch only pretends to power down, so
maybe this won't work. Is this true? If so, why does apple do that?
Peter G. Rose
------------------------------
Date: 11 Apr 88 14:42:47 GMT
From: Rob Elkins <relkins@vax1.acs.udel.edu>
Subject: Re: The "(c) Brain" virus is not a new virus. (RISKS-6.55)
>It is a basically harmless virus which first emerged ...
That may not be exactly true. From reading RISKS extensivly, it seems to me
that the command.com virus may not be harmless. It may have "evolved" since
its discovery into something more harmful, and I remember reading that it had
sort of date trap set for Friday the 13th. It is still in your best interest
to copy the data on any infected disks onto fresh disks and reformat the
infected disks.
Rob Elkins
BITNET: FFO04688@UDACSVM UUCP: ...!sun!vax1.acs.udel.edu
------------------------------
Date: 11 Apr 88 05:44:39 GMT
From: munnari!uowcsa.oz.au!david%uowcsa.cs.uow.oz.OZ@uunet.UU.NET (David E A Wilson)
Subject: There is a VT220 with block mode available from DEC. (Re: RISKS-6.52)
Organization: Uni of Wollongong, NSW, Australia
Jerry Leichter is not quite correct in saying that NO VT220 made
by DEC has BLOCK mode. In Australia, DEC modified the standard VT220 to
create a VT220-Z (VT220 + VT131/2 block mode) as a special for the
New South Wales Department of Health. They then also made it available
to anyone else who wanted to buy it. Whether or not this has the security
hazard described in RISKS 6.51 I cannot tell as I no longer work for the
NSW Dept of Health.
David E.A. Wilson ACSnet: david@uowcsa.oz
Dept. of Computing Science UUCP: ...!munnari!uowcsa.oz!david
Uni. of Wollongong ARPA: david%uowcsa.oz@uunet.UU.NET
------------------------------
Date: 2 Apr 88 10:47:02 GMT
From: cmcl2!phri!dasys1!tbetz@rutgers.edu (Tom Betz)
Subject: Enfranchising the disenfranchised: our responsibility?
Kim Greer writes:
> ... if someone does not like the state they are in they should do
> something to change it.
I would go so far as to say that there is nobody who can use a VCR who can
not use a computer for >something<.
> ... If someone is "disenfranchised" from using computers because they
> can't read, let them learn how to read.
Unfortunately, much easier said than done. Computers can, however, be a
useful tool for aiding the teaching of reading/writing.
>... But people are generally able to do anything they really want to...
I know, through a skills training program for welfare mothers living in
motels because they have no other home, of one woman who has managed to buy
her kids an Adam, a C=64, and a TI-99A, all on a welfare budget. This
woman, though a part of the most disenfranchised classes in America today,
has obtained (leaving aside for the moment the question of whether or not
she uses them for this purpose) the tools to join into this peculiar
Republic we here are a part of, using a very powerful lobbying tool to guide
our elected officials. Recent proof of the power of this medium is the
defeat of the FCC's connect charge for computer systems.
A question I would find most interesting to discuss here would be the
question of this Republic within the Republic. How are the lives of those
who are too ill-educated to use these tools effectively going to be affected
by the increased power of those of us who >do< use them?
Do we have a responsibility to do whatever we can to spread the power around
to these people? How can we do this? How can our computers help us help them?
Serious questions....
Tom Betz {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!tbetz
New York, NY, USA {sun}!hoptoad/
------------------------------
Date: Mon, 11 Apr 88 15:09:18 EDT
From: David Thomasson <ST401405%BROWNVM.BITNET@MITVMA.MIT.EDU>
Subject: Discrimination and careless arguments
In an earlier note I pointed out what I take to be weak points in some recent
RISKS items about discrimination. Literary critic John Lavagnino replied that
my complaints are "off the mark." As irony would have it, Lavagnino's reply
further substantiates my precautions about shoddy arguments.
>In all the instances I recall, and particularly Les Earnest's,
>nobody was talking about the question of what the ideal Motor
>Vehicle Bureau should ask you on their application.
Nor was I. Explaining why he refused to reveal his race on a license
application, Earnest argued as follows (I paraphrase): (1) Race has nothing
to do with driving a car. Therefore, (2) asking for an applicant's race isn't
justifiable. My point was not about ideal motor vehicle bureaus; it was about
logic: (2) doesn't follow from (1). The suppressed premise is: (1A) If X has
nothing to do with driving a car, then X cannot justifiably be put on a
license application. *If* once accepts that premise, then most of the
information on drivers licenses is unjustified: name, address, color of eyes,
color of hair, etc. And this, of course, is patent silliness.
>Les Earnest's was a *story* that told of becoming uneasy about certain
>classifications in the light of substantial evidence of their misuse.
No, Earnest did not give any evidence at all that racial information on
drivers license applications had been misued. He simply lumped this anecdote
in with others that did suggest such misuse.
>Thomasson would have us ignore how information is used in society, and once
>you do that then of course a discrimination's bad effects will often
>disappear from view; you can pretend that a Southern state, in the early
>60s, would ask about your race merely because it's useful for
>identification. Just because they can cite good reasons doesn't mean their
>real reasons aren't bad.
Rather than ignore such information, I would suggest that writers *present*
it. Here, Lavagnino confuses two separate actions: gathering information, and
misusing information. Asking for race on a driver's license is, I suggest,
justified because it is useful in identifying the licensee. If the state then
uses that information for other (discriminatory) purposes, *that* action is
not justified and should be stopped. But one must not confuse the reasons that
justify including such information with its subsequent misuse. The state could
just as easily misuse information about one's address or age. It is this
*misuse* of information, and not the gathering of it, that is wrong. Careful
argument requires that such distinctions be made, especially on the overheated
hot topic of discrimination.
[We are drafting in RISKS relevance, but this reply is still useful. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
-------