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 8 Issue 18

Monday 30 January 1989


o Hong Kong computer horse betting
George Moore
o Keycard badges vs. anti-shoplift systems
Bruce Hamilton
o Bank Fraud
Peter Golde
o Crashing a PDP-11/40 (Computer Folklore)
Jeff Makey
o Sprint to the Finish?
Steve Philipson
o Information Security/Computer Crime Statistics
Stan Stahl
o Re: ELIZA and Joe Weizenbaum
Bernie Cosell
Bob Krovetz
o Virus conference hosts software swap meet
Robert Lee Wilson Jr
o Structured Programs, Project Failures
Charles J. Wertz
o Losing Systems
Mike Albaugh
o Info on RISKS (comp.risks)

Hong Kong computer horse betting

George Moore <georgem@microso.UUCP>
Sun, 29 Jan 89 06:16:26 -0500
Tonight's "Beyond Tomorrow" program on Fox television did a short article about
a device that is currently under test in Hong Kong.  It is a portable (slightly
larger than a calculator) terminal which allows a user to place bets on horse
races from anywhere that has a modular phone connection.  It has 6
touch-sensitive LCD windows which present various menus allowing the person to
place up to 100 bets per race.  Once all of the bets are entered, you just
connect it to the phone line and it dials up the computer at the race track.
Your account number is stored in the (presumably) EEPROM of the device; all you
have to enter is a 6 digit PIN number to identify yourself.  Money won or lost
is automatically reflected in your bank account.

The RISKS implications are enormous.  People are currently grumbling on how
unsecure an ATM is.  That's nothing compared to this! At least with an ATM you
have leased lines that are slightly harder to tap, with this wonderful device
all someone has to do would be to tap a phone extension in your house or office
and grab your PIN number.  Even if it's encrypted, the thief will have plenty
of time to break the code offline.  After that he's free to deplete your bank
account.  With the proper fake ID, he could freely collect his winnings at the
race track.  Why gamble with your own money?  Use someone else's!

The American Horse Racing Association is looking heavily into using this device
in the U.S. to relieve overburdened telephone operators at most race tracks.

I for one, even if I *did* frequent the tracks, would never trust such a
device over ordinary phone lines.
                                          -George Moore

Keycard badges vs. anti-shoplift systems

28 Jan 89 17:00:10 PST (Saturday)
Here's a new one.  In Xerox/El Segundo we use these big heavy blue keycard
badges that you slap against (or hold near) a reader to open various doors.
Today I went shopping in the local Target store and as I tried to exit, all
sorts of lights and bells went off.  You guessed it -- the badge was
responsible.  The guard apologized and gave me a little piece of cardboard
labeled "SCHLAGE SHIELD" to put next to my badge.  Of course, when I got to
work, I had to remove the cardboard to get the badge to work.

   [Interesting.  The same mechanism is used for entry control at Xerox
   and exit control (anti-theft) at Target.  The moral unfortunately is that
   the SCHLAGE SHIELD works fine to circumvent the anti-theft control.  
   Here is another supposedly high-tech solution with a trivial bypass.
   Ho-hum.  PGN]

Bank Fraud

Peter Golde <ST501432@BROWNVM.BITNET>
Sat, 28 Jan 89 22:47:49 EST
A few days ago I saw a program on TV dealing with bank fraud and
mismanagement.  One of the reports went somewhat as follows:

    An employee in the computer division, who had been working at the bank less
    than a year, one day sent a computer message to the Brinks depository which
    stores and handles gold bullion for the bank.  The message simply asked for
    Brinks to send 44 kilos of gold to such and such P.O. Box in a town in
    California.  As per normal procedure, Brinks sent the money to the address,
    where the employee (or a confederate) picked it up.  The employee then
    disappeared and still remains at large.  Subsequent investigation revealed
    that the bank had never even checked his (phony) previous employment
    references when he was hired.

Boggles the mind, eh?  One simple email message!               --Peter Golde

Crashing a PDP-11/40 (Computer Folklore)

Jeff Makey <Makey@LOGICON.ARPA>
30 Jan 1989 0132-PST (Monday)
In 1979 or so I heard a story that was already a couple of years old
about a DEC PDP-11/40.  It seems that one could walk across the room,
kick the console terminal, and crash the computer.

After a certain amount of wailing and gnashing of teeth, they determined
that walking across the room generated a static charge, which was
transferred to the console terminal by kicking it.  The (now dynamic) charge
traveled down the communication wire to the terminal interface board and
jumped across a narrow air gap to a neighboring circuit board, thereby
disrupting things enough to crash the system.  The problem was solved by
moving one of the circuit boards to a different slot, which created too
large an air gap for the charge to jump.
                                                      :: Jeff Makey 

Sprint to the Finish?

Steve Philipson <>
Mon, 30 Jan 89 14:33:38 PST
   In 8.16 a call went out for documentable stories on computer problems.
I'm having one right now with US Sprint.  Here's the story.

   About a year and a half ago I moved from LA to the SF Bay area.  I followed
the instructions of my long distance carrier, US Sprint, which allowed me to
keep my account while I moved, and to have it transferred to my new address
when I established a new residence.  A problem developed however, as Sprint set
up a second account for me at my new address.  I started to receive two bills
each month, one for my calls placed from home, and another for those placed
with the Sprint credit card.  The two bills were for different account numbers.

   I called Sprint about this, and they said they would consolidate the
accounts, but I should send checks to pay the ammount due on each. I did so.
Here lies the rub.  Each time Sprint receives a check from me, they credit only
account A.  It makes no difference that I place the appropriate account numbers
on both checks, and that they are sent in separately with billing forms for the
appropriate accounts -- checks for account B get credited to account A.  Sprint
now has submitted my account B to a debt collection agency.  I have repeatedly
called customer service and explained the problem, but they have taken no
action, even though their records show two checks being credited to account A
for each billing period.  They have trouble believing that they could be
screwing up their accounts receivables so badly.

   I am now at the point of having my credit history being damaged by
US Sprint, and may soon be contacting an attorney to sue them for same.
Ah, the joys of dealing with a system where the "computer" makes no mistakes.

   Note:  If any readers out there work for Sprint, I'd appreciate your
help in getting this problem fixed.  Anyone know the name/address of the CEO?

Information Security/Computer Crime Statistics

Sun, 22 Jan 89 22:57 EST
The National Center for Computer Crime Data is a non-profit organization
devoted to the collection and dissemination of statistical information
on computer crime, information security technology, and the information
security profession.  The Center is currently gathering statistics for
its second report, "Commitment to Security." The Report is scheduled for
release in May.

People with diverse backgrounds will read "Commitment to Security."
These include information security professionals, including computer
security practitioners, those in the R&D community, and sales and
marketing personnel.  Prosecutors and others responsible for enforcing
computer crime laws will also read the Report.  In addition, based on
our experience with the first Report, the media will use "Commitment to
Security" as a sourcebook on the extent and seriousness of computer
crime.  Consequently, it is important that the Report be as thorough,
valid and meaningful as possible.  Towards that end, we have surveyed
3500 computer security professionals and 2500 prosecutors.

There are, however, methodological questions about how best to measure
and communicate the problems of computer crime and information security
technology.  Therefore, the Center would like to invite RISKS
participants to engage in a conversation on these issues.

We would like to have a discussion in RISKS of questions like the following:

      What statistics would enhance our understanding of the
      scope and seriousness of the computer crime problem?

      What statistics would enhance our understanding of
      information security technology and its potential
      for reducing computer crime?

      How can we best get valid statistics on computer crime and
      computer security technology?

      How can we best present our information so that it is
      understood, both by the professional and the layman?

We will send a free copy of the report to anyone who meaningfully contributes
to the discussion.

If you want to talk to us off-line, please call

  JJ Buck BloomBecker,             Director, NCCCD,             213/874-8233
  Stan Stahl            Research Director, NCCCD,               213/969-0777

Thanks, in advance, for your participation.

                                  [By the way, Dockmaster has been off the 
                                  net since just after this was posted.  PGN] 

Re: ELIZA and Joe Weizenbaum

Bernie Cosell <cosell@WILMA.BBN.COM>
Sat, 28 Jan 89 0:22:59 EST
} > Or, there's the story about the guy who falls asleep in front of his
} > terminal with an ELIZA program running and his boss logs on and thinks he's
} > talking to him but is actually talking to the program, and gets pissed off.
} This may have actually happened. Joseph Weizenbaum (MIT professor, author of
} _Computer Power and Human Reason_) told the anecdote in a class, with himself
} as one of the actors.  It went something like this -- some of this is
} doubtless my own memory inventing things.  The dialogue is partially courtesy
} of GNU Emacs' Eliza program, and the rest is made up.
} .... anecdote follows...

Is that for real, that Joe is telling that story?  He has a lot of
anecdotes, many of which appear in CP&HR, but I didn't know he was
including one like that these days (alhtough such a thing must have
SURELY happened some time or other at MIT).  The REAL first round of
that anecdote dates publicly to a small bit Danny Bobrow wrote in the
first issue of some AI journal he started in something like 1968.  The
thing DID happen, although not quite as the word-of-mouth has
transmitted it down to the present generation.  The program in question
was _DOCTOR_, **NOT** Eliza, and it happened at BBN, not at MIT.

I know all of this, because (Ta DAAH!) **I** wrote the original
Doctor!  Not _Eliza_ --- _doctor_: Weizenbaum's CACM article on Eliza
had just appeared and for a variety of reasons I was looking for a neat
Lisp hack to play with.  The CACM article mostly told me enough, and I
went off and wrote the thing.  I can supply the details of the *real*
"A Turing Test Passed" incident (the title of Danny Bobrow's article
describing the event: it involved my version of doctor that I had left
running for people to play with to help me get it debugged, the
"innocent third party" -- Danny Bobrow, and the Turing Testee, a random
executive (whose name I will not reveal) who thought (for reasons that
it is hard to figure out) that the Mod-33 was connected through to
Danny at home early on a Saturday morning.

I can supply more details if anyone really cares, including (if I can
dig the thing out of my archives) a copy of Bobrow's article about
the incident which included the *real* typescript (danny came in later
that Saturday morning and ripped it off of the terminal).

Bernie Cosell, BBN Sys & Tech, Cambridge, MA 02238

ELIZA and Joe Weizenbaum

Mon, 30 Jan 89 02:26 EST
Bloom's story about Weizenbaum and ELIZA is close, but the person involved was
Daniel Bobrow, not Weizenbaum.  The account was described in the December 1968
issue of the SIGART Newsletter, and was reprinted in the book Machines Who
Think, by Pamela McCorduck (p. 225).

The following is the description of the account:

"One Saturday morning about 9 A.M., a BBN Vice-President in charge of selling
our Telcomp commercial service arrived at our PDP-1 computer room hoping to be
able to use the computer for a demonstration.  He found a note on the PDP-1
PERIOD'.  This note was left there by one of the programming bums who had just
succeeded in making run a Lisp version of the DOCTOR program (based on ELIZA as
developed by Weizenbaum).  However, the VP thought that this note indicated
that this teletype was linked with the one in my [Bobrow's] home, since I often
used the computer all night.  Therefore, he started typing to `me', but in fact
was typing to this version of the DOCTOR program.  The following conversation

  VP:        Do you think that I can use the computer this morning?

  TELETYPE:  Why do you ask?

  VP:        I might be able to make some additional telcomp sales.

  TELETYPE:  Why aren't you sure?

  VP:        My prospective customers have never seen a demonstration
             of the system.

  TELETYPE:  Does this mean very much to you?

  VP:        Of course it does.

  TELETYPE:  You seem very positive of that.

  VP:        This is ridiculous.

  TELETYPE:  What do you mean this is ridiculous?

  VP:        Is there any reason why I can't use the computer now?

  TELETYPE:  Tell me more about your prospective customers.

  VP:        Please dial me up on 491-1850

Note that after that remark the VP did not obey instructions and left out
the period.  Therefore, of course, the computer didn't answer him.  This
so infuriated the VP, who thought I was playing games with him, that he 
called me up, woke me from a deep sleep, and said:

  VP:        Why are you being so snotty with me?

  BOBROW:    What do you mean why am I being snotty to you?

The VP angrily read the dialog that `we' had been having, and couldn't
get any response but laughter from me.  It took me a while to convince
him it really was the computer".

Bob Krovetz or krovetz@umass.bitnet

Virus conference hosts software swap meet

Robert Lee Wilson Jr <bobw@ford-wdl44>
Mon, 30 Jan 89 11:50:48 PST
   I just received an ad from MIS Training Institure for "Micto/89 -- A
Three-Day Conference on Microcomputer technology and its Impact on Security,
Control, and Audit."

   Among its concerns: "Indeed, with the recent front page coverage of the
computer virus that struck universities, research, and government organizations
across the country, one needn't be a security specialist to be aware of the

   So what is the first big benefit offered by the conference?

"                           SPECIAL FEATURE
                            Software Bonanza
o Software Swap        
Bring diskettes with your original spreadsheet templates, BASIC, dBase, or
other applications and swap them for the brainchild of a coregistrant. MIS will
operate a Swap Center throughout the conference where we will maintain a
library and make copies of diskettes for participants.

o Software Giveaway
When you attend the conference you will receive diskettes containing: Lotus 123
macros, utilities, virus detectors, graphics programs, and templates fot data
analysis, statistics, investment analysis, and Lotus macros.

o Software Directory
Along with conference materials, you will receive an invaluable Directory
listing over 1000 public domain and shareware programs you can obtain for
little or no cost.

o MIS Electronic Resource Center
MIS' electronic bulletin board containing software programs, bibliographies,
articles, audit programs, and much more will be available for your use during
the Conference.  "

The ad says the conference will "update you on new technologies and the risks
to which they expose your organization." It sounds as if it might turn out to
be a lab course.
                                        Bob Wilson 

Structured Programs, Project Failures

<<WERTZCJ@SNYBUFVA.BITNET> Charles J. Wertz Buffalo State College>
Sat, 28 Jan 89 15:13 EDT
Over the last several months, there have been a number of articles touching on
the above in Risks.                        Most of my computer career has
involved the development of business systems for commercial enterprises.
I never cease to be amazed by several things. And, I consider them to be
contributing factors to the type of problem noted often noted here. They are -

       . the poor decisions which managers (both business and technical)
         often make for non technical reasons.
       . the haphazard approach many of our colleagues take toward requirements
         determination, requirement verification, and system testing.
       . the near crimes committed in the name of 'meeting the deadline".
       . the belief that following the externals of a methodology (such as
         indenting and naming rules or the format of a deliverable) is the
         same as understanding and following the methodology.
       . the failure of many of our colleagues to understand or try to
         understand the reasoning processes behind the popular methodologies.

I'll resist the temptation to go on. I do believe that the above are primary
explanations for many of the really poor business systems in existence today.

Re: Losing Systems (RISKS-8.12)

Mike Albaugh <albaugh@dms.UUCP>
Mon Jan 23 13:01:30 1989
> I would like to suggest that it would suffice anyway if it were applied.  The
> difficulty is that software is managed by programmers, not engineers.

    Actually, both are, in my experience, managed by managers, who may
not be either, but who owe their primary allegience to other managers.

> Programmers have no tradition of quality of their own and insist that their
> activity is so different from what engineers do, that engineers have nothing 
> to teach them.

    I don't know what the first statement is suppose to mean, but it
looks suspiciously like yet another of the gratuitous slaps that programmers
typically get from engineers. For the record, I am officially a programmer,
but have done a fair amount of hardware design (and been paid well by a
satisfied employer for both). The major problem I have found is perhaps the
name "software". Managers hear that and assume that changes to software are
trivial (and free), while changes in hardware are impossible (or at least
very costly.) The result, intended or not, is that programmers are required
to add all sorts of software bandaids when the hardware fails to meet its
spec. It is seldom actually acknowledged that this is happening, but the
lack of acknowledgement does not mean a lack of happening. Especially in
a project that involves custom LSI, there will be quite a few "enhancements"
snuck into the software spec at the last minute (__way__ past "final"
design review) that are nothing more or less than shoving hardware bug-fixes
over the wall into the programmer's cubical.

> I am hopeful that the use of the term "case" presages the application of more
> discipline in programming.

    I could hope that some sort of documented "requirements control"
would make these games more visible, but I doubt it will. They will, as
usual, be swept under the rug as "clarification".

> I also draw hope from the entreprenurial development of software for the
> market, as opposed to works built for hire for a single organization.  I saw 
> a great deal of quality software at Egghead on Saturday.

    The great advantage an entrepeneurial firm has is that the president,
Chief Engineer, and Chief Programmer have lunch together once in a while
and can often get away with calling a spade a spade.

> William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
> 2000 National City Center Cleveland, Ohio 44114                          
> 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                

Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh)
Atari Games Corp (Arcade Games, no relation to the makers of the ST)
675 Sycamore Dr. Milpitas, CA 95035     voice: (408)434-1709
The opinions expressed are my own (Boy, are they ever)

Please report problems with the web pages to the maintainer