RISKS-LIST: RISKS-FORUM Digest  Friday, 19 February 1988  Volume 6 : Issue 29

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
  When in doubt, blame the computer.  Mistaken-identity nightmare. (PGN)
  Re: Last Clasp credit cards; Mistaken identities (Wm Brown III)
  Magnetic clasps on purses (Art Evans)
  Code-altering viruses (News System Administrator)
  Viruses (Larry Nathanson)

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.
 > > > > > > > > > PLEASE LIST SUBJECT in SUBJECT: LINE. < < < < < < < < <
  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: Fri 19 Feb 88 15:27:07-PST
From: Peter G. Neumann <NEUMANN@csl.sri.com>
Subject: When in doubt, blame the computer.  Mistaken-identity nightmare.

  Neil Foster from Marlborough and Neil Foster from Somerset are both 38,
  with brown hair, moustaches, and almost the same height.  One was wanted
  for motor vehicle violations, but the other one got picked up.  The
  other one also lost his job, his savings, and his car in the process.
  Wiltshire police blamed their computer.  But other police admitted that
  the computer is "only an aid to identification, and information on it
  should always be cross-checked..."

  The real culprit was found after a three-month search by the other Neil
  Foster, who explained what had been happening and got the guilty one to
  go to the police.
  
  The national police computer system currently houses records of stolen
  and suspect vehicles, fingerprints, names of known criminals, wanted and
  missing persons, and disqualified drivers.  Plans are underway to expand
  it to use by the courts, the crown prosecution service, probation
  service and prisons.  It currently contains 25 million names.  An
  individual may be identified by name, age, sex, height, and vehicle
  type.  "In theory, with a correctly spelt name and date of birth, a case
  of mistaken identity should be impossible."

[Source: An article by Stephen Davis and Nick Rufford in the Sunday
Times, London, 10 January 1988, contributed anonymously.]

Lousy theory.  But in practice, I would think that adding birthplace might
help reduce the probability of two people with the same identification.  And
what about someone who lies about his/her age or height?

Here we have a case of an accidental name confusion.  Other such cases have
been reported in RISKS in which computer systems were implicated, but in
which human laziness may ultimately have been to blame -- such as the
Shirley Jackson and Sheila Jackson case in 1983.  This should be contrasted
with the case of Terry Dean Rogan, in which someone assumed his identity and
caused him great grief.  (Both of these cases were noted in Software
Engineering Notes 10 3, July 1985.)

------------------------------

Date: Thu, 18 Feb 88 18:16 PST
From: Wm Brown III <Brown@GODZILLA.SCH.Symbolics.COM>
Subject:  Re: Last Clasp credit cards (RISKS-6.28); Mistaken identities

  From: Jack Holleran <Holleran@DOCKMASTER.ARPA> [...]
  First, you need a sufficient strength to really erase.  How much is enough?

How much is enough?  My last employer used a magnetic card key to provide us
with access to the building on weekends or after hours.  This was one of the
old brute-force types, about 2 mm thick, made of a flexible ferrite-plastic
composite like the magnet tape used to hold doors closed on refrigerators.
The magnetic field from the card was strong enough to levitate a very small
magnet inside the lock by a few thousandths, lifting it out of a hole and 
allowing the mechanism to move.  Several magnets were randomly located above 
the card slot, and of course each could be oriented in either of two ways.

Several people, myself included, had the bits wiped off our bank machine and/or
credit cards which lived next to these card keys in our wallets.  I have no
idea how to relate this field strength in absolute numbers, however we could
find the active spots in our cards by 'dowsing' for them with a staple on the
end of a piece of thread.  In other words, not very strong at all.  Certainly
not strong enough to work as a magnetic clasp.


[Unrelated pet peeve]     
          [But ironically related to Neil Foster in the first item above.  PGN]

I don't use the "III" suffix on my name out of vanity or pride; it isn't even
on my birth certificate (although I am indeed the third William E. Brown in
my family line).  I started using it way back when my mail, checks and credit 
ratings started getting mixed up with others, including my own Father's.  Do
you have any idea how many people named Bill Brown there are in Los Angeles?
Even with this fairly unique addition, I have still had lawyers, collection
agencies and even private detectives threaten me with someone else's problems.

Now for the computer connection:  very few programmers seem to allow for names 
with trailers.  Many computer-generated letters are addressed correctly, then
start out "Dear Mr. III".  Even the ones which allow for any number of name 
segments outsmart themselves by assuming that only the first character of a 
string should be capitalized, so "III" turns into "Iii".  Bank and government 
systems, whose owners aren't trying to be polite, often address things to 
"III, Wm. E. Brown".  I can often track who sells mailing lists to whom by 
the patterns of error propagation.

The best one, however, came last month when I bought a used car.  The dealer's
system which types out nineteen different and complex forms from one set of
input data simply decided that the last group of letters had to be my last
name, and that everyone has two initials plus one name.  Now I have an
extended protection policy from Ford, complete with an embossed plastic card,
in the name of "W E III".

------------------------------

Date: Thu 18 Feb 88 10:03:42-EST
From: "Art Evans" <Evans@TL-20B.ARPA>
Subject: magnetic clasps on purses

After reading on RISKS about danger to credit cards from magnetic clasps on
purses, I asked my wife if she owns such a purse; fortunately, she does not.
However, in the course of the discussion it occurred to us that she sometimes
carries floppy disks in her purse.  Now that seems to me like a real RISK
possibility.  With bad luck the card could be within 0.25 inch or so of the
magnet and in continuous movement with respect to it as the purse is carried.

Art Evans/Tartan Labs

------------------------------

Date: Thu, 18 Feb 88 23:16:54 pst
From: uw-beaver!tikal!sigma!news@rutgers.edu (News System Administrator)
Subject: Code-altering viruses
Organization: Summation Inc, Kirkland WA

In some discussions around here about the recent virus articles in comp.risks,
someone raised the idea of the inevitability of viruses that target specific 
software products.

Unlike the current run of viruses which seem to be either fairly innocuous or
generally destructive, this type of virus would be designed to quietly alter
some particular (probably commercial) software with the intent of making it
look faulty or buggy.

For example, a virus of this type might be designed to attack a Brand X 
spreadsheet, to cause it to perform some computations incorrectly. The 
effect might not show up immediately, but would certainly eventually leave
the user with a poor opinion of the program, which might not go away even 
after the existence of the virus became known and the problem fixed (after
all, this software would now be known to be vulnerable and targeted).
The economic cost to the spreadsheet vendor could be considerable.

One motivation for writing such a virus comes immediately to mind. This is
the disgruntled employee, the same legendary figure who leaves time-bombs
in employers' code. (Have any instances of this ever been successfully
prosecuted?). This would be harder to prove than the time-bomb: the (source)
code is not left in the employer's hands.

One of the more insidious aspects of this kind of virus is that it can do 
its job and go away (erasing itself once its mission is accomplished),
leaving no hint that the targeted utility has been damaged nor that a virus 
was responsible. The blame for the induced problem will naturally fall on
the author of the utility, especially when it shows up "all over".

(What laws and penalties would apply against the author of such a virus?)

------------------------------

Date: Fri, 19 Feb 88 13:40:58 EST
From: bucsb.bu.edu!lan@bucsb.bu.edu (Larry Nathanson)
Subject: Viruses (Re: RISKS-6.28)

	A few years ago, while I was in high school, I read a short desciption
of what a virus was, and decided to write my own.  It was short, (<500 lines 
source code) and VERY contagious to a dos 3.3 disk.  Since it was a challenge
and not a malicous attempt to destroy data, when it triggered, all it said
was "BOO".  After a while I started wondering what use it could be, besides
the destruction of data.  One of the things I came upon, was that it could be 
used to get information out of a secure system.  For example,
let's take 3 sample computer systems: A, B, and C.  Someone at A
has a file that C wants.  B is a computer system that exchanges software, with
both A and C.  (B could also be a few computer systems, that exchange software
among themselves, and form a link from A to C.)  C introduces a virus to B's
system, with the hope that it will get to A's system.  All this virus does is 
check the date, and scan for a character string.  When a given character string
is located, it either opens up a communication channel to A, and dumps all
relevant information, or it appends a certain amount of the information to 
itself, and subtly changes itself: it is now an outbound virus, and will
only transfer the information to an already infected system.  Thus eventually,
the information will slowly come back to A.  If a copy of the "inbound" virus 
finds that the date is greater than a certain day, it decides that it is on a
dead end, and just erases itself. 

If a group of programmers, sat down, and came up with such a "smart" virus,
the implications could be staggering.  

Larry Nathanson         Boston Univ. CS Dept.          lan@bucsf.bu.edu

------------------------------

End of RISKS-FORUM Digest
************************