Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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
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>|
Re: Intolerant Fault-Tolerance
<Tom.Lane@ZOG.CS.CMU.EDU>
Sat, 09 Apr 88 19:26:19 EDT
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:
Another Security Clearance Story
Ronald J Wanttaja <ames!uw-beaver!ssc-vax!wanttaja@ucbvax.Berkeley.EDU>
Thu, 7 Apr 88 23:10:30 pst
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
A new VMS security hole?
Jonathan Corbet <gaia!jon@husc6.harvard.edu>
9 Apr 88 17:25:40 MST (Sat)
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
Re: Notifying users of security problems
"John O. Rutemiller" <Rutemiller@DOCKMASTER.ARPA>
Fri, 8 Apr 88 10:43 EDT
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
Re: notifying users of security bugs
William Smith <wsmith@m.cs.uiuc.edu>
Fri, 8 Apr 88 15:24:23 cdt
>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
Viruses
Fred Cohen <fc@ucqais.uc.edu>
10 Apr 88 18:47:13 EDT (Sun)
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
April Fool's Warning (Re: RISKS-6.55) [The last word was the first!]
Piet Beertema <mcvax!cwi.nl!piet@uunet.UU.NET>
Mon, 11 Apr 88 16:28:13 +0200
>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]
Virus Distribution
<EAE114%URIMVS.BITNET@MITVMA.MIT.EDU>
Mon, 11 Apr 88 19:27 EDT
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
Re: The "(c) Brain" virus is not a new virus. (RISKS-6.55)
Rob Elkins <relkins@vax1.acs.udel.edu>
11 Apr 88 14:42:47 GMT
>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
There is a VT220 with block mode available from DEC. (Re: RISKS-6.52)
David E A Wilson <munnari!uowcsa.oz.au!david%uowcsa.cs.uow.oz.OZ@uunet.UU.NET>
11 Apr 88 05:44:39 GMT
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
Enfranchising the disenfranchised: our responsibility?
Tom Betz <cmcl2!phri!dasys1!tbetz@rutgers.edu>
2 Apr 88 10:47:02 GMT
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/
Discrimination and careless arguments
David Thomasson <ST401405%BROWNVM.BITNET@MITVMA.MIT.EDU>
Mon, 11 Apr 88 15:09:18 EDT
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]
Please report problems with the web pages to the maintainer
x
Top