The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 6 Issue 73

Friday 29 April 1988

Contents

o RISKS of Amateur Radio Call-sign License Plates
Stanley F. Quayle
o Social Security Numbers on Driver's Licenses
Stanley F. Quayle
o A Short List of Nits about "Normal Accidents" by Perrow
Stanley F. Quayle
o A perspective on viruses
Bill Murray
o Write-protection for hard disks
Bill Murray
o FPP and garbled text
Joe Morris
o Swapping Cash Containers
Joseph M. Beckman
o Reference Legends of Caltech (Stop ending mail requests!)
Eugene Miya
o Center for Viral Monitoring -- I'm trying!
Chip Copper
o ATM blues
Bob Sidebotham
o Yet another ATM story
Bruce Hamilton
o YADBR (Yet Another DB Risk)
George Michaelson
o Info on RISKS (comp.risks)

RISKS of Amateur Radio Call-sign License Plates

bcd-dyn!sfq@csl.sri.com <Stanley F. Quayle>
Fri, 29 Apr 88 12:55:05 EDT
The discussions about "NOPLATE" reminded me of an incident that occurred
two years ago.  Also related is the hazards of using the first match from a
database.

I was in an auto accident.  The other driver was clearly at fault; however,
the police check the computer for both drivers and vehicles as a routine
measure.  The policeman called my plate in:  N8SQ.  I have amateur radio
callsign plates.

The response on the radio was something like:  "1974 Ford pickup truck, Farmer
Jones, Circleville, Ohio.  No wants or warrants."  The policeman looked at me:
the plates weren't on a truck, my name wasn't Jones, I wasn't from Circleville,
etc.  He was sure he'd caught a live one!

Just then, over the radio came, "Wait a minute...  There's ANOTHER one!  1986
Pontiac 6000, Stanley Quayle, ..."  *whew*!

Amateur radio callsigns start with A, K, N, or W.  They have an optional
letter, a required digit (0 through 9), and one to three letters.

In Ohio, truck license plates start with N, have an optional letter, one to
three digits, and one to three letters.

This was the first I'd heard of the problem.  However, since then, I've seen
a car and truck with the same vanity plate, owned by different people.  Truck
plates are a different "series" than car plates, it seems.  But they forgot
to tell the computer that.

Stanley F. Quayle   UUCP: cbosgd!osu-cis!bcd-dyn!sfq
(614) 424-4052      USPS: 505 King Ave., Columbus, OH  43201
N8SQ @ W8CQK        Fido: Stanley Quayle, Node 1:226/610
My opinions are mine.  What more of a disclaimer could you need?


Social Security Numbers on Driver's Licenses

bcd-dyn!sfq@csl.sri.com <Stanley F. Quayle>
Fri, 29 Apr 88 12:55:05 EDT
Ohio requires SSN for issuing a driver's license.  I don't like it, but they're
within the federal law (as amended).

However, they print the SSN on the face of the license, along with the
DMV-issued license number.

A chain of stores in the area requires a driver's license for
identification when paying by check.  The cashier enters the SSN from the
license on the register.  After a few seconds, at least in my case, an
approval code returns.

This store uses price scanners.  It would be possible to establish a profile
of each check-paying customer with this system.  They can also do the same
with each credit-card customer.

They can link the credit-card numbers with SSN for those customers who rent
video tapes, since both are required on the video application.

The question is, do I complain to the store?  If they haven't thought of this
already, I don't want to give them any ideas.

And, yes, I'm trying to pay by cash.


A Short List of Nits about "Normal Accidents" by Perrow

bcd-dyn!sfq@csl.sri.com <Stanley F. Quayle>
Fri, 29 Apr 88 12:55:05 EDT
I finally read this book, after hearing about through this group.  A few things
bother me about it.

First, a little background on myself, to make any possible biases evident.
I fly airplanes recreationally, and have a Master's degree in Nuclear
Engineering.

First, the smallest nit:  Twice in the book, once in the text and once in the
glossary, "LNG" is defined as "Liquified Nitrogen Gas".  Probably a common-mode
failure.  Of course, it's liquified natural gas.  Much more flammable.

Medium nit:  References to the pilots with personal airplanes in southern
California.  He makes it sound like all pilots who like to fly are rich and
inconsiderate.  I almost stopped reading right there.  At least I don't have
any prejudices against book authors.

And, the nuclear power nit:  Well, he has a point.  My own opinion is that the
current crop of nuclear power plants are too complicated and too difficult
to control and maintain.  Some of his facts sound like he doesn't understand
nuclear power very well.  (Sorry, no specific examples right now.)  The length
he goes to bury nuclear power appears to be born from a dislike of the concept
rather than analysis of it.  And he doesn't mention any of the proposals for
inherently-safe reactors.  There are designs available now that are simple 
and that don't have complex interactions.

Overall, however, it is a fascinating book.  The parts about marine safety
are really shocking.  I'm glad that I'm living a long way from water.

By all means, read this book.


A perspective on viruses

<WHMurray@DOCKMASTER.ARPA>
Fri, 29 Apr 88 15:33 EDT
One should not be surprised that the discussion of viruses by computer users
should focus on how to protect their own systems.  However, as I read RISKS I
become concerned that is how the problem is perceived.

A virus is a special case.  It is a social disease.  It attacks not only a
target system, but a population of systems, and social order all at the same
time.  I am sure that if you have imported one into your system and if it does
something destructive, you will see primarily in terms of the destruction that
it does.  However, similar damage could have been done by any Trojan Horse or
even by your own error.

The problem with the virus is not in the damage that it does to one system, but
with the damage that it does to a population and to the fabric of trust that is
essential to the sharing of programs and other data and to commerce in general.

Suppose that viruses become so pervasive that even those who have never seen
one become afraid to use any program that they did not write themselves.
Suppose that because of the publicity received by viruses, the public at large
were to loose confidence in all computers, in the information they generate,
and in information in general.

If you think that that is far-fetched, then I ask you to think back to the
panic that followed the Tylenol contamination.  In a society in which 1500
hundred people a year die early because of the use of asbestos, another 15000
from the use of fossil fuels, 40,000 from the use of the automobile and 200,000
from the use of tobacco, the level of concern was out of any realistic
proportion to the number of deaths.  But it was not out of proportion to the
effect of the loss of confidence in the medicine supply or even of the food
supply.  I suggest that it was the unconscious concern for the effects of the
potential loss of confidence that caused the panic.

The perpetrators of the virus know very well how it will behave in the target
system, but they have no idea how it will behave in the population.  The
XMASCARD program did not do any damage in the user's machine, but it brought a
multi-million dollar network to its knees.  The scope and sensitivity of that
network was not only beyond the perpetrator's knowledge, but it was beyond his
comprehension.

The perpetrators of these toys are, like the sorceror's apprentice, playing
with powers far beyond their knowledge or control.  The potential for damage is
far beyond their puny powers to predict, skills, motives, or their intent.
They are toying with the mechanisms of cooperation and coordination that
characterize humanity.  They are to be pitied for their ignorance, but they are
not to be tolerated, much less admired or emulated.  A society that depends for
its own proper functioning upon any mechanism, dare not tolerate any
interference with the intended operation of that mechanism.


Write-protection for hard disks

<WHMurray@DOCKMASTER.ARPA>
Fri, 29 Apr 88 17:16 EDT
On April 22, 1988 I received two back issues of a newsletter entitled 
"Computer Virology" along with along with a product description for the 
Disk Defender (tm).

  "Computer Virology is published in Evanston, Illinois by Director
  Technologies, Inc.  Director Technologies is the manufacturer of DISK
  DEFENDER, a product which write protects in hardware all or part of a
  personal computer hard disk.  It is our belief that hardware write protection
  is the only 100% reliable virus protection for the operating system and
  commonly used programs.  If you have any comments, questions, suggestions or
  article submissions, please address them to:

  Director Technologies, Inc., Technology Innovation Center
  906 University Place, Evanston, IL 60201     312-491-2334

[Quoted without permission from the masthead of the newsletter.  I am in no
way associated with this firm.  This is not a recommendation or endorsement of
their product.]

The product appears to be a half-card that installs between the drive and the
hard disk drive controller card.  It can make a portion of the or all the hard
disk "write-protected."  It has an outboard component with a 3-position switch
which permits you to select between "full|zone|none."  The outboard switch can
be removed in order to remove the discretion from the user.  In other words, it
is a hardware write-protect tab for a hard drive zone.  The size of the zone
appears to be chosen by setting dip-switches on the card itself.

To suggest that it is 100% effective against a virus is to overstate.  Studies
in biology suggest that a virus can thrive even in a population in which a
large percentage of the members are immune, if a there is sufficient commerce
among the non-immune members.  This is not an argument against vaccines but
only a caution about the limits of their effectiveness.

Depending upon design of the virus, the target system and population, and the
chosen distribution vector, the effectiveness of this mechanism against the
spread of the virus might vary from high to none at all.

Good hygiene is the general defense against viruses, but there are limits to
how effective it can be.  Nonetheless, the individual can and should protect
himself within those limits.

Bill Murray      WHMurray at DOCKMASTER


FPP and garbled text

jcmorris@mitre.arpa <Joe Morris>
Fri, 29 Apr 88 11:26:34 EDT
In RISKS 6:72, Hugh Davies comments on a problem with text being garbled due
to the software and hardware disagreeing about the presence of a floating
point processor.

I'm told that at least in DEC's VAX line, the ULTRIX (UNIX-like) system can
be made to handle characters with significantly higher speed by adding
an FPP to the computer.  Apparently the FP opcodes provide some kind of
fast path which can be exploited by programs which are processing strings,
even if no floating point calculations are performed.

Perhaps some parts of the system recognized the presence of the hardware
while others didn't.  If A interfaces with B and each has a different set
of assumptions about the environment, the results can be "interesting" if
they also assume that everybody agrees.  (Remember the analysis of the 
word "assume"?  It makes an ASS out of U and ME.)

There is an indirect RISK here in that an optional feature on the computer
is named in a way which fails to describe its function.  Who would have
thought that floating point hardware would improve character processing?


Swapping Cash Containers

"Joseph M. Beckman" <Beckman@DOCKMASTER.ARPA>
Fri, 29 Apr 88 08:58 EDT
I assume when people load containers into ATMs, they replace the ones
already loaded with another set.  They then return the first set for
accounting purposes.

Seems like the problem of having people install cash containers in ATMs
incorrectly could be (partially) solved by a technique mentioned in at
least two other areas in RISKS.  In the last issue (6.72), we heard how
an airline company fixed a problem of crossing their fire extinguishing
lines by making the connections different sizes.  Some time ago, there
was a discussion on plugging medical equipment into the wrong sockets.
(Come to think of it, a third area was the ability to plug some computer
equipment (LAN connections?)  into a wrong socket (no pun intended))

The different containers could have a small bit of metal or plastic
added to them that would fit only in the proper slot in the ATM.  This
at least reduces the risk; you still have to have the person originally
loading the container do so with the correct denomination.  Another
simple fix (but not as robust) would be to color code each container.

Joseph


Reference Legends of Caltech (Stop ending mail requests!)

Eugene Miya <eugene@ames-nas.arpa>
Thu, 28 Apr 88 11:18:18 PDT
%A Willard A. Dodge, Jr.
%A Reuben B. Moulton
%A Harrison W. Sigworth
%A Adrian C. Smith, Jr.
%T Legends of Caltech
%I California of Institute of Technology, Alumni Association
%C Pasadena, CA 91125
%D 1983
%K ARCHES program, senior ditch day, room stacking, color blindness
and traffic jams, Rose Bowl Hoax 1961 (U of WA [1]).

I am surprised at the number of peple who think this is just a text file
which you can just FTP.  [Oh, Aaron Schuman, you can just look at my copy.]
Please do not send me mail on this. This is a published book which
costs $10 and has important photos inside it.  (Text is completely
inadequate to describe this book, it has photographic proof.)
If you want a copy, please contact the Caltech Bookstore.
The general number for Caltech is (818)-356-6811.
P.S. There is also a Climber's Guide to the Caltech Campus (EE Dept.)
which I also have a copy (for a different type of RISK).

Any resemblence to the film "Real Genius" by M. Coolidge is intentional.
The Book does not contain recent stories of 1) the Rose Bowl Attack
on the score bowl (MIT 6 Caltech 25) [documented in earlier RISKs],
or 2) the recent changing of the Hollywood sign.  This will all have
to be covered in some future edition.

Of computer interest is the ARCHES program which was used to stuff
1.5 million entry addresses into a McDonald's contest in the 1970s.
This 11 line FORTRAN program is the reason why game cards make
comments about no electronic reproduction.

Please note: I was never a Caltech student.  I have many friends there and
was a Caltech employee at its Jet Propulsion Lab and at the Institute (CS
Dept.)  itself for which I have the greatest respect [I would rather donate
money to them than my old UC campus, it's better spent at Caltech].

--eugene miya


Center for Viral Monitoring -- I'm trying!

Chip Copper <copper%bgsu.edu@RELAY.CS.NET>
Wed, 27 Apr 88 10:18:06 EDT
I have been trying to keep track of Macintosh viruses, but unfortunately
my input is limited to articles in this group and on the news networks.

I've tried to send out surveys and solicit virus information from several
different sources, but everyone refuses to give you any information on
the virus.

I have no idea of how to legitimatize myself!  I am sincerely interested
in studying and tracking these rascals, but everyone assumes I'm just
trying to do further damage to the community.  Phone calls don't help!
Letterhead doesn't help!  Calls from officials at my University don't help!
I realize people have to cautious, but I'm stumped!  How do we solve a
problem no one is willing to discuss?

Everyone who gets a virus posts a message telling what it does and how
to rip it out of an infected system.  Ask for any other information on the
virus, and you hit a brick wall.

I am willing to study and track all Macintosh viruses, but it will take
the cooperation of those getting the viruses to help solve the problem.

I welcome ANY feedback on this!  Any suggestions?  Any of you out there
who have viruses willing to cooperate?  Any government agency
out there willing to investigate me and verify my intentions?

(A frustrated)  Chip Copper, Ph.D. 
Assistant Professor
Department of Computer Science
Bowling Green State University
Bowling Green, Ohio 43403-0214
(419) 372-8142  (My office)
(419) 372-2337  (Department office)


ATM blues

Bob Sidebotham <bob+@andrew.cmu.edu>
Wed, 27 Apr 88 12:00:16 -0400 (EDT)
My wife deposited a cheque in a Pittsburgh National Bank ATM.  After the ATM
had accepted the cheque, it aborted the transaction for some reason.  She
complained to the bank, and they assured her that everything would be taken
care of.  What actually happened is that all of our cheques this month
bounced...

Some years ago, I banked with the Canadian Imperial Bank of Commerce.  The
Commerce's system for deposits was different from any I've seen in the U.S.:
After keying in the particulars of your deposit, the system issued you a
deposit ticket which you then inserted into the envelope with the deposit.
When the transaction completed, you got the standard receipt.

This simple scheme was very useful because (1) it allowed you to deposit money
without getting frostbite while writing the particulars on the envelope, (2) it
provided a transaction identifier which the bank could (and presumably did) use
to verify that the transaction was committed, without any possible ambiguity,
and (3) it guarded against any mistakes that you might make (listing a
different chequing account, etc.), which would be compounded by an error on the
part of the ATM (such as aborting the transaction), and (4) it provided a
printed verification of the particulars of the transaction that the user could
check just before committing his end of the transaction.

I suppose it's possible that the American systems print this information
directly on the envelope as it's sucked into the ATM, but that doesn't seem
very likely.  In any event this would obviate the advantage of *knowing* that a
readable printed record was actually enclosed with the deposit.


Yet another ATM story

<"Bruce_Hamilton.OsbuSouth"@Xerox.COM>
25 Apr 88 18:19:07 PDT (Monday)
A few weeks ago I went to a local First Interstate Bank branch and tried to
withdraw some cash, using my Xerox Federal Credit Union card.  I got a rather
vague message back, something like "unable to complete transaction".  Thinking
it might be a local ATM problem, I went a couple of miles down the road to the
El Segundo First Bank.  That ATM told me "Your card is damaged".

The next morning I called XFCU and ordered another card (which takes them
over a week to mail to me).  I also retried the old card at XFCU.  Lo and
behold, it worked! It has since worked at many ATM's, including the one that
gave me the bogus "damaged" message.

I wonder how much these vague or bogus error messages are costing the financial
institutions in this country?  What's so difficult about putting up a message
like, "Unable to communicate with your bank's computer at this time.  Try again
in a few hours."?
                                        --Bruce


YADBR (Yet Another DB Risk)

<munnari!ditmela.oz.au!george@uunet.UU.NET>
27 Apr 88 10:26:31 +1000 (Wed)
George Michaelson, CSIRO Division of Information Technology
ACSnet: G.Michaelson@ditmela.oz.au                   Phone: +61 3 347 8644
Postal: CSIRO, 55 Barry St, Carlton, Vic 3053 Oz       Fax: +61 3 347 8987

(written by Colin Brammall in Computerworld Australia, reproduced
 without permission)

   HEADLINE: GOSSIP DATABASE - Uni dossier of 'soft' info

   SYDNEY - A computer-based intelligence-gathering system, which creates
dossiers of "soft information" such as rumour, gossip, ideas and
personal assessments has been developed at the University of N.S.W.

   Several Federal Government [that means Australia not USA] bodies
including the Army and the Department of Industrial Relations have
been shown the product, which runs on any DEC vax machine.

   It has apparent potential for intelligence bodies such as Asio and Asis
and even for Federal cabinet, as well as for departmental and
private-enterprise hierarchies.

   The basis is a high-level messaging system linked to a database which
electronically duplicates face-to-face meetings. It is intended to pull
together relevant information that might otherwise remain in
individuals minds.

   The discussion/conference is simple. "If people read a message and they
want to add to the information, or challenge it, they comment on it,
which causes a conference to be created, and a debate opens up with all
interested people on the system," said Cyril Brookes, professor of
information systems at UNSW, who headed the team which developed the
system.

   The keyword/message system is based on a thesaurus of terms unique to
the user organisation, designed to cover all the concepts that anybody
in the organisation is likely to message about.

   Each message is coded with one or more of the thesaurus terms, and is
given a level of importance. The highest level might be for the
minister/chairman of the board, the next for all first assistant
secretaries/general managers and so on.

   Each user builds an interest profile, putting an order on the system
for messages containing certain topics, sub-topics and keywords, and
levels of importance.

   Professor Brookes said the system reported informal information in much
the same way that traditional databases reported formal information
through such things as exception alerting and as-necessary detail.

   Because soft information did not pop completely in one place or time,
the system brought together all the people who had  information to
contribute.

"we have been fascinated for 10 years or so about the lack of attention
paid by the computer community to informal or soft information" Brookes
said.

"it is my view that the informal data are the most under-utilised
resource that managers have available to them."

   Normal databases recorded history he said. "The future, which is what
decisions are about, is not related to history tremendously. The clues
to what is going to happen are in peoples minds and in their informal
contacts."

   Bulletin boards and messaging systems do not do the job because they do
not massage the information.

Please report problems with the web pages to the maintainer

Top