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 41

Thursday 10 March 1988

Contents

o Harmless Virus?
Richard S. D'Ippolito
o Have I Missed Something? (Hacking, Trojan horsing, etc.)
Chris McDonald
o Leap Year Madness
John W. Taylor Jr.
o "NOPLATE" and "NONE"
Steve Philipson
o ATM-OS-FEARic pollution
Jim Sims
o Another ATM discrepancy story
Ken Yap
o Re: computer error and learned helplessness
James H. Coombs
o Why don't they learn? (American vs European Date formats)
Gary Friedman
o Computers on Aircraft
Keith Bjorndahl
o Re: Reliance on computers (Inland Steel furnace burnout)
Dan Franklin
o Lousy Lazy UNIX Linkers
Michael I. Bushnell
o Need References to "Environmental Bugs"
Gene Spafford
o Info on RISKS (comp.risks)

Harmless Virus?

<Richard.S.D'Ippolito@sei.cmu.edu>
Wednesday, 9 March 1988 09:31:17 EST
In RISKS 6.39, Chris Borton makes the following statements regarding a virus
on his systems:

    To our knowledge it is non-malicious (yet).
    I don't believe this is any cause for panic -- it hasn't
    done any known harm yet.

Then he finally admits:

    If it's a joke, I don't find it very funny.

C'mon, everyone -- when your "two best programmers spent today tracing...and
haven't found a real solution...", then it HAS done harm. Figure that the
average technical employee requires a company to generate around $80K a year
in sales, so you've spent the equvalent of $640 already. And what about
others who will put the same time in helping Chris or themselves?  It's time
to come down hard on these @#&^#*s and stop treating them like cute
pranksters. An "A-", indeed!
                                        Rich D'Ippolito


Have I Missed Something? (Hacking, Trojan horsing, etc.)

Chris McDonald STEWS-SD 678-2814 <cmcdonal@wsmr10.ARPA>
Tue, 8 Mar 88 14:26:55 MST
The forum recently had a posting of 14 "Dirty" files identified by Eric
Newhouse which had appeared in the 22 Feb 88 edition of InformationWeek.  When
I attempted to verify the accuracy of the data, I found an original article
attributed to Mr. Newhouse and contained in a local computer publication dated
August 1986 which contained the same programs.  

I discovered in reading the article, however, that the 14 programs were not all
Trojan Horse programs, but that some were what Mr. Newhouse labels "hacked"
of an otherwise legitimate freeware or user-supported program.  Since I had
seen no other discussion in the forum, and since apparently the list of
programs must be at least 18 months old, I wonder if I am correct in assuming
that indeed the list published in InformationWeek and the forum includes both
"hacked" and "trojan horse" files?  I note also that in the local publication
Mr. Newhouse identified two other file names for the Trojan Horse identified as
"DISKSCAN.EXE":  SCANBAD.EXE and RADDISK.EXE.  His description of the program
is that this was "a PC-Magazine program to scan a hard disk for bad sectors, 
but then a joker edited it to WRITE bad sectors."

While the passage of time may have allowed someone to take a "hacked" program
and make it a "trojan horse" as well, I would just like to verify the most
current information.


Leap Year Madness

"John W. Taylor Jr." <JWTaylor@DOCKMASTER.ARPA>
Thu, 10 Mar 88 11:47 EST
How long can we drag this one out, claiming that this only happens once every
four years, when in fact we must deal with a similar situation twice a year.

I am reminded of the time I gave my fiancee' (now wife) a call from college
late one Saturday night in October.  As was customary for us, being 300 miles
apart, we spoke for over an hour (61 minutes to be exact).  The phone company
computer, in its infinite wisdom, backed up precisely one hour during our
phone conversation to account for the change between Standard and Daylight
Savings time.  Rather than counting the number of minutes we talked, the
computer stamped a start and stop time for my call, thus the conversation went
from 12:00m to 12:01p.

Some points to ponder:  If we can't get an hour right, how can we expect to
deal with days/years?  How much money does the phone company lose when this
happens?  (Or does it gain when we "spring forward"?)  What would have happened
if my wife and I had spoken for 59 minutes and the computer would have had to
deal with a call from 12:00m to 11:59p the previous day?
                                                              --John


"NOPLATE" and "NONE" (Re: RISKS-6.40)

Steve Philipson <steve@ames-aurora.arpa>
Thu, 10 Mar 88 10:04:37 PST
The old "warhorse" about the license plate "NOPLATE" probably repeats itself in
the real world on a regular basis.  I read about such a story within the last
year or two.  If memory serves correctly, this one occurred in New York.  The
plate was "NONE"; the newspaper article contained a photo of the car and the
plate.

The real issue here is of a system design failure.  The designers did not
include a way to indicate that there was missing information (plate absent), so
the users used some descriptive text that turned out to be a valid entry.  (Of
course, a missing data code might have been designed in but not given to /
forgotten by the officers in the field).

This is a frequent problem in database and interactive systems -- either the
designer has an incomplete understanding of the real world environment in which
the software will run, or the end users develop a new requirement and use for
the software.  Users tend to kluge their inputs to get the desired results
rather than request a change in the system.  This may come from a perception
that the system can handle the change without going through a formal
modification.  People can adapt to things that seem intuitive, so it shouldn't
be any big deal for the machine, either.  Perhaps the user's perspective is not
that the machine can adapt, but that the meaning is so intuitively obvious that
no adaptation is necessary.

Those of us who write interactive software have learned (sometimes through
painful experience) that no input can be taken for granted.  Ingenious users
can always come up with things that will screw up a program, or use it in ways
that corrupt the system.  We have learned how to guard against many types of
invalid input, but the quest for the "idiot proof system" goes on.  The problem
may grow worse with time.  As our systems gain more "expert" capability, they
will have the appearance of having real-world knowledge and some common sense.
When users depend on that human quality in their systems failures abound.
Increasing capability will bring yet more RISKS in computer systems.

      [Guess what?  I found the "NONE" case in RISKS-3.12, 24 June 1986, 
      contributed by Chuck Price, and augmented by yours truly.  It was
      supposedly CALIFORNIA, which now instructs officers to always write
      "NONE" in the case of unknown plate.  I suppose "N.A." (not available) or
      "UNKNOWN" might also cause trouble.  Having 7 characters adds more fun,
      but there are plenty of plates in any case that would be reminiscent of
      Abbott and Costello:
         Officer: "Please give me your license plate number."  
         Driver:  "NEVER" or "WHY" or "WHY NOT" or "DON'T ASK".
      But, if you really want to confuse the computer matching programs, you
      might opt for something like 1OI0O01, which on California plates would
      be quite hard to read accurately as it flies by.  PGN]


ATM-OS-FEARic pollution (Re: RISKS-6.39)

Jim Sims <sims@stsci.arpa>
Thu, 10 Mar 88 12:33:19 EST
I also have an ATM related horror - that the bank didn't catch.

I recently moved to a new city and didn't get around to balancing my chackbook
for a couple of months. When I did I noticed something rather odd.  There were
two ATM withdrawals for $50 spaced one minute apart at an ATM machine about 5
miles from my house, on the evening of the day our furniture arrived. Now, any
other day/combination I wouldn't have caught, but I knew I didn't go to an ATM
that day (certainly NOT one 6 miles away when there are several closer), we had
both cards at home, we ate at home that night, and I have NEVER withdrawn $50
twice when I wanted $100, I withdraw $100 (too lazy? too smart? to push those
buttons twice).

I notified the bank, and spent several months hassling the bank about it, and
after explaining that I deal with computers for a living, they finally decided:

        "We did not make an error, but out of courtesy to you, since you 
        are so convinced, we are restoring the $100 to your account."

I thanked them and advised them to notify "whoever handles computer security"
in their institution.

        [The "SUBJECT:" line refers to the negative effects of developing
        a phobia against ATM systems, in case you hadn't guessed.  PGN]


another ATM discrepancy story

Ken Yap <ken@cs.rochester.edu>
Thu, 10 Mar 88 15:01:46 -0500
Years ago I used the ATM service of a bank in my home country. One day
I requested a withdrawal. The machine went through the motions of
verifying me, but just before I got the money, the machine shut down.
Cursing my luck I went into the bank and got the money via a teller.

A few days later I received a phone call from the bank. Did I try to
withdraw $X on a certain day? We have a discrepancy between the amount
of money in the ATM and the log. In the end I got my money back.

Since I only got a statement once a month, I don't know what would have
happened if the discrepancy had showed up in my statement a month later.
Risk: The teller makes you sign a receipt before giving you the money. If
the ATM screws up without a trace, how does one even begin to dispute with
the system?
                                     Ken


Re: computer error and learned helplessness

"James H. Coombs" <JAZBO%BROWNVM.BITNET@MITVMA.MIT.EDU>
Wed, 09 Mar 88 16:49:28 EST
Bruce Sesnovich writes:

> The ATMs I'm familiar with here in Massachusetts are monitored by hidden
> cameras, and I imagine the same is true of ATMs in other states.  The
> banks have recourse to the photographs taken by these cameras when a
> transaction is contested.

I have always wondered about those cameras.  What happens if you step back
out of view? wear a mask?  Wear a hat pulled down over your face?  I doubt
very much that those cameras have sophisticated pattern recognition (let's
hold the transaction until we get a good shot of a real human face).  So
what will banks do if the picture for a transaction doesn't enable us to
identify who the agent was or wasn't?
                                                  --Jim

Dr. James H. Coombs, Software Engineer, Research          jazbo@brownvm.bitnet
Institute for Research in Information and Scholarship (IRIS), Brown University


Why don't they learn? (American vs European Date formats)

Gary Friedman <garyf@devvax.Jpl.Nasa.Gov>
Wed, 9 Mar 88 17:18:44 PST
This is hardly a technology-related RISK, but it certainly falls within the
categories of low-level, people-not-thinking errors that have flooded recent
digests.

A friend of mine, who is backpacking (is there a RISK in verbing nouns?)
throughout Europe, possesses an extra AMEXCO card on my account displaying his
name.  (This is to assure instant cash in case of emergencies.)

One day I got a call from someone claiming to be from American Express,
stating that one of my checks that was cashed in one of the American offices
had bounced, and that if I didn't cover the ~$400 debt in three days my
account would be attacked by corporate white blood cells.  To my recollection,
I had written no such checks, although I did cash a check with them while in
London three months earlier for a similar amount.

Although quite courteous, she refused to reveal crucial information such as my
account number or exactly where and when the check was cashed.  ("We're not
allowed to give that information over the phone.")  Lacking proof, I treated
the call as if it was a prank and informed her that I would take no action
unless I saw physical evidence, like perhaps the bounced check.

Two days later the check came in the mail.  It was written and cashed by my
friend overseas.  Three days worth of investigations revealed the following:

- The "American Office" that AMEXCO had mentioned was located in London.

- My friend's account had plenty of funds to cover the check.

- The bank rejected the check as being 'stale' (more than 6 months old.)  The
  check was written only two weeks earlier.

The problem was traced back to the discrepancy between the European and North
American date formats.  Since the check was written on December 4, 1987, the
teller in London wrote

    4.12.87

which the bank in the US quickly deciphered as April 12, 1987 and pronounced
the check stale!

Issues:

1) Why does AMEXCO call their outlets in London "American Offices"?  Does it
   communicate to anyone the office's location?

2) I can't believe this hasn't happened before.  A company policy of spelling
   out the months, even in abbreviated form, will prevent this type of error
   (which AMEXCO *must* be prone to) from happening again.

3) Their security measures are so good that they render their phone queries
   unauthenticatable.  (Pretend it's a real word.)  There are simple systems
   available to let customers know that AMEXCO's calls are legitimate without
   compromising confidentiality.

I'm hardly disgusted, as I related to AMEXCO simple procedural changes to
prevent future occurrences and they seemed to regard the suggestions as being
valuable.

Gary Friedman, Jet Propulsion Laboratory - NASA, 4800 Oak Grove Drive, 
Pasadena, CA 91109.   (818) 354-0410  Uucp: {cit-vax,elroy,psivax}!jplpro!garyf
Arpa: jplpro!garyf@cit-vax.ARPA -or- garyf@jplpro.JPL.NASA.GOV

             [The problem of wrong or incompatible data formats has 
             been the source of a variety of incidents reported here... 
             But this one is a little like trying to get the others to 
             drive on the right (or left, depending upon which is right) 
             side of the road.  PGN]


Computers on Aircraft

Keith Bjorndahl <BJORNDKG%UREGINA1.BITNET@CUNYVM.CUNY.EDU>
Thu, 10 Mar 88 16:58:25 CST
  >In most cases, the (computer) user is not told to believe absolutely the
  >evidence of a machine over the evidence of his senses. But in the case of
  >aircraft he is explicitly trained to do so. This behooves us (as 
  >programmers, etc.) to make sure that the machine is telling the truth!
  >                                                               Hugh

   I don't believe that pilots are expected to believe computers over
indications given by other sources.  It was not long ago that there was a near
miss on an overseas flight in the Gander control area which was caused in part
by the entry of wrong data into the flight computer.  The flight went 60 miles
off course because the computer was being used as the sole source of navigation
information.  Other more conventional methods of navigation were not used to
cross check the information given by the flight computer.  We must remember the
garbage-in/garbage-out rule, but we must be aware that we can always anticipate
that from time to time there will be some garbage in.  Every system must be
designed to reduce the chance of this garbage producing catastrophic results.
Now, most airlines require that more than one method of navigation be used to
cross check the values produced by the flight computer.  Now and then, we just
have to use our eyes and our minds and ALL of the instruments together to
narrow the RISK of one failure leading to another.
                                                              Keith


Re: Reliance on computers (Inland Steel furnace burnout)

<dan@WILMA.BBN.COM>
Thu, 10 Mar 88 11:23:45 -0500
Wow, a huge, expensive steel furnace that doesn't have a control
system as smart as the one on most home furnaces!  If my oil furnace
turns the pump and the igniter on, but doesn't get a rise in temperature
after a minute or so, it shuts off automatically.  And it doesn't even
have a PDP-11 in it.

No doubt Inland Steel originally relied on workers to do the job, and
neglected to think about the problems inherent in replacing people with
computers.  Fortunately home furnaces are designed by people who know that
they will be operated unattended (and used by people who know nothing about
them), and so have lots of safety devices.
                                                     Dan Franklin


Lousy Lazy UNIX Linkers

Michael I. Bushnell <gatech!turing!mike@rutgers.edu>
Wed, 9 Mar 88 11:33:46 MST
Actually, there is a way.  If you think about it, you will realize that a
program of your design can find out all the symbols in the library, after
all, ld finds out.  And, there is such a tool: nm.  Just say "nm libfoo.a"
and it will print all the symbols used or defined in the library.

Michael I. Bushnell, mike@turing.unm.edu, {ucbvax,gatech}!unmvax!turing!mike


Need References to "Environmental Bugs"

Gene Spafford <spaf@purdue.edu>
10 Mar 88 17:32:07 GMT
I need to develop a body of references to published descriptions of bugs
resulting from changes in environment.  That is, programs which worked fine on
one machine, but failed to work when ported to another machine or had the
current system upgraded, either due to a change in data type precision, change
in memory size, timing differences, etc.  Also appropriate are references to
programs that failed to work simply because the machine involved didn't have
the precision or range or memory that the programmer assumed, even though the
code itself was "correct."

I'm *not* interested in hearing anecdotal references; I want examples
(compilations and theoretical studies would be best) that have appeared in the
literature in the past 10 years.  Note that I'm not asking about portability
problems, per se, but about failures of the actual machine to match the
programmer's virtual machine -- "environmental errors."

If there is sufficent interest and PGN allows, I'll summarize for RISKS what
I get back.

Thanks in advance!

Gene Spafford, Dept. of Computer Sciences, Purdue University, W. Lafayette 
IN 47907-2004  spaf@cs.purdue.edu  uucp ...!{decwrl,gatech,ucbvax}!purdue!spaf

Please report problems with the web pages to the maintainer

Top