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 39

Tuesday 8 March 1988

Contents

o Computer error and learned helplessness
Bruce Sesnovich
o Garbage In, Gospel Out
Ephraim Vishniac
o Re: Checking Statements & Disappearing Skills
Darin McGrew
o Disappearing skills
Al Stangenberger
o Lousy Lazy UNIX Linkers
David Collier-Brown
Henry Spencer
Andrew Klossner
o Another Mac virus on the loose?
Chris Borton via Dave Platt
o The last word (words, words and more words) on viruses
Robert Slade
o BEWARE of PC-LOCK
James Ford
o Moving time backwards
Paul Smee
o Leap Year
Harold E. Russell
o SDI related sources
Dan Jones
o Electronic Privacy Act Info Request
Eliot Lear
o Info on RISKS (comp.risks)

 

<suneast!norbert!bruces@Sun.COM>
Tue, 8 Mar 88 14:11:02 EST
     (Bruce Sesnovich - Sun ECD Information Architecture)
Subject: computer error and learned helplessness

In RISKS 6.38, Eric Herrmann relates his experience with a spurious electronic 
debit. Fortunately, the bank discovered its error and Eric eventually got his 
$60 back without having to raise a fuss.  However, I believe that in general 
such erroneous debits ought to be contested.  Unless I am mistaken, the burden 
of proof then falls on the banks to prove the cardholder has in fact withdrawn 
the money.

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.

Though I've not had the pleasure of contesting a debit to my account, I believe
my bank requires a nominal (~$5) service charge to investigate a transaction. 
The fee is a hedge against slews of fraudulent appeals and is refunded if your 
claim is borne out.

Eric's decision to "eat the $60 loss" seems to me an example of a pervasive 
computer RISK:  the learned helplessness that afflicts many people when 
confronted with computer-related bureaucratic injustices.  

I do not intend this message as a put-down of Eric.  I believe many people 
would have made the same choice he made.  But who among us would have 
complacently accepted being short-changed $60 by a human teller or a store 
cashier?

Eric's statement: "but...I couldn't prove anything," reflects a common
attitude that, where computers are concerned, "you can't win, so why even
bother trying?"  Isn't this attitude the flip side of overreliance and
unquestioning trust?  In both cases there is the unwillingness to challenge
the myth of the computer's monolithic infallibility.  Debunking this myth, it
seems to me, ought to be a goal of every concerned computer professional.

Bruce A. Sesnovich, Sun Microsystems, East Coast Division, Billerica MA


Garbage In, Gospel Out

<ephraim@Think.COM>
Tue, 08 Mar 88 09:16:24 EST
In Risks volume 6, issue 38, Paul Smee (Smee@AUCC.AC.UK) writes:

  "I recently objected to a sales assistant trying to charge me an
   amount I knew was wrong.  'The till [US cash register] says it's 12
   pounds', she insisted.  'Why don't you believe it?'"

I was interested to find recently that ill-founded faith in the output
of calculating machinery has been with us as long as possible.
Consider the following (whose attribution should be obvious):

    On two occasions I have been asked [by members of
    Parliament!], "Pray, Mr. Babbage, if you put into
    the machine wrong figures, will the right answers
    come out?"

    I am not able rightly to apprehend the kind of con-
    fusion of ideas that could provoke such a question.

Sad to say, the modern public is no more wary of GIGO than were 19th
century MPs.

Ephraim Vishniac                      ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214


Re: Checking Statements & Disappearing Skills

Darin McGrew <ibmuupa!mcgrew@ucbvax.Berkeley.EDU>
Mon, 7 Mar 88 14:00:50 PST
In RISKS 6.36 David Andrew Segal (dasegal@brokaw.LCS.MIT.EDU) relates an
incident involving an ATM deposit that wasn't registered by the bank's
computer.

I am often amazed at the number of people who trust banks, stores,
restaurants, etc, to never make mistakes.  Apparently it is too much bother
(or simply too difficult) to ever reconcile statements or verify receipts.
Add to this the ability of computers to replicate human errors a thousand
times a second, and we have a real RISK, for which there can be no technical
solutions.  This is a real               [Sorry.  The last word got lost!  PGN]

Darin                                I speak for myself, not for my employer.


Disappearing skills

<forags@violet.Berkeley.EDU>
Tue, 8 Mar 88 09:11:23 PST
Several years ago, I was using a calculator to add a series of numbers.  The
result "felt" wrong, so I did it by hand and found that the calculator had
malfunctioned -- for every digit on the display, 8's looked like 6's because
one of the LED segments failed to light up.  If I had been doing something
more complicated than addition, I probably would never have spotted the
problem.

Maybe calculators should have some sort of "self-test" program built in which
would be automatically  invoked when the unit is powered up?

Al Stangenberger                    Dept. of Forestry & Resource Mgt.
forags@violet.berkeley.edu          145 Mulford Hall - Univ. of Calif.
uucp:  ucbvax!ucbviolet!forags      Berkeley, CA  94720
BITNET: FORAGS AT UCBVIOLE          (415) 642-4424                      


Re: Lousy Lazy UNIX Linkers (Joe Dellinger) [RISKS-6.34]

David Collier-Brown <geac!daveb@uunet.UU.NET>
7 Mar 88 13:59:34 GMT
In RISKS-6.34 Joe Dellinger comments:
[discussion about linking and having variables change mysteriously]
> ...           And if you don't happen to have the source code for one
>of the libraries that gets linked in, such as the FORTRAN runtime library,
>THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might
>get overlayed in this way...

  Well, it's a known, long standing problem.  In the natural environment of
Unix V6 (cooperative software development, all sources available) it was a
reasonable implementer's choice.  In some other environments, not so.
  The ANSI committee is aware of it, and has made a well-known work-around
(reserved leading underscore) part of their proposal.  If the
only-available-in-binary library is part of the C language run-time system,
it is blatantly illegal.
  This doesn't help much if it is a bought-in product: the general solution
to this requires a fair bit more work, equivalent to specifying an
Ada[tm]-quality linker as part of the language definition.  I claim that
_that_ is easy.  Others disagree.
  It remains a risk.

David Collier-Brown, Geac Computers International Inc., 350 Steelcase
Road,Markham, Ontario, CANADA, L3R 1B3 (416) 475-0525 x3279
                 {mnetor yunexus utgpu}!geac!daveb 


Re: Lousy Lazy UNIX Linkers

<mnetor!utzoo!henry@uunet.UU.NET>
Mon, 7 Mar 88 13:50:53 EST
> ... if you don't happen to have the source code...
> THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might
> get overlayed in this way...

Actually it's not QUITE that bad.  You can find out, but the procedure is
obscure and painful and nobody does it.  (See the "nm" command, which can
be convinced to give you a list of all the global names in a library.)

The real problem here is not Unix-specific:  name-space pollution.  Smart
library writers are careful to use systematic naming conventions that a
user is unlikely to duplicate.  The ANSI X3J11 C-standardization effort is
in fact trying to require this for the standard libraries.

Even less-permissive linkers can cause trouble when the internal name
spaces of libraries overlap.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry


Lousy Lazy UNIX Linkers aren't at fault

Andrew Klossner <andrew%frip.gwd.tek.com@RELAY.CS.NET>
Tue, 8 Mar 88 12:46:45 PST
The described problem is not the fault of the linker, but of the design
of the Fortran language.  If two programs each contain the line

    COMMON /PC/PC

and they are compiled separately, then there is no mechanism by which
the compiler can declare that one program defines PC and the other
program uses PC.  Subsequently, the loader must accept one or many
COMMON declarations to mean that a single object should be established
and all the declarations connected to it.

The risk, then, is in writing software in a thirty-year-old language
whose design preceded much of our understanding of software risks.

The C language definition rode on this convention to some extent; the
declaration "int pc;" outside a function is equivalent to "extern int
pc;".  To declare a variable in a way that ensures ownership, initialize
the variable, e.g., "int pc=0;".  (Of course, this will still silently
match the Fortran COMMON statement above.)

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]


Another Mac virus on the loose?

Dave Platt <dplatt@coherent.com>
Mon, 7 Mar 88 21:09:37 PST
The following posting appeared in comp.sys.mac this evening.  If you have
any information about the virus reported in this posting, please speak up!

From: borton@net1.ucsd.edu (Chris Borton)
Subject: I've got a virus and I don't like it
Date: 8 Mar 88 02:04:12 GMT
Organization: UCSD Network Operations Group

This is a warning and plea for more information, if anyone has any. We just
discovered a virus in some of our systems (not all) at work today, and it has
permeated my system at home as well.  The symptoms are simple:

INIT 32 in System File

nVIR resources in various applications and the System File.

This sucker is tricky -- it is getting itself loaded before any INITs do (we
believe the INIT 32 is just a teaser), like PTCHs do, but it isn't in PTCH.
Our two best programmers spent today tracing through it and still haven't found
a real solution other than offloading and re-initializing.

To our knowledge it is non-malicious (yet).  The nVIR resources are usually
small, sometimes 8 bytes, sometimes ~360.  If you remove them from both 
System and ResEdit, the virus won't let you run ResEdit because it is looking
for those resources and can't find them.  It occasionally beeps when running a
program.

We have no idea what installed this.  We are fairly certain it originated from
one of the many small programs that come over the net.  Many of these would be
perfect 'carriers' -- little demo program that's an "aww, that cute, now let's 
trash it."  I'm not putting down these programs, just pointing out what I feel
is obvious.

I don't believe this is any cause for panic -- it hasn't done any known harm
yet.  I would, however, like to get to the bottom of this!  If it's a joke, I
don't find it very funny.  (unless it de-installs itself completely after April
Fool's Day :-)). If it is someone's graduate thesis, you get an A-.  But enough
is enough!

Chris "Johann" Borton, UC San Diego
...!sdcsvax!borton    borton@ucsd.edu     BORTON@UCSD.BITNET


The last word (words, words and more words) on viruses

<Robert_Slade@mtsg.ubc.ca>
Tue, 8 Mar 88 07:42:24 PST
     For anyone interested, I have compiled all the virus messages I could
find on virus, trojan horse and related topics from RISKS, Computers and
Society, INFO-IBMPC and INFO-MAC.  The uneditted file runs to 70 pages.
(Anyone wanna publish a book?)  For those in Canada, The Globe and Mail for
Monday, March 7, 1988, page C15, under the title "Devilishly clever viruses
may be lurking to devour your data" is telling everyone that you can recover
from a Trojan attack through a warm boot.

(And how many nanoseconds is your reaction time?)

    [And James Ford <JFORD1%UA1VM.BITNET@CUNYVM.CUNY.EDU> has the
    DIRTY DOZEN listing from Eric Newhouse on hacked/trojan/virus programs...
    Much too much for posting.  But there are no LAST words on this one.  PGN]


BEWARE (J. Greely)

James Ford <JFORD1%UA1VM.BITNET@CUNYVM.CUNY.EDU>
Tue, 08 Mar 88 09:00:57 CST
>A quick warning about PC-LOCK (shareware).  If.........version 1.0.....

I didn't know that one could consider PC-LOCK shareware....  :-)

Just as a note......the version of PC-LOCK that we're using here is
Version 3.0 on IBM PC/XTs.  Also, the included text (reprinted without
permission) states the latest enhancements available on Version 3.0....

    (quote)
          Thank you  for buying  PC-Lock version  3.0.  We believe you will
          find it  to be  an effective  and convenient  security system for
          your IBM-PC/XT/AT or compatible.  Version 1.1 was reviewed in the
          June 23, 1987 issue of PC-Magazine and listed among "The  Best of
          the Best  Utilities."  Version 3.0 provides enhanced security and
          several new features including:

               Simplified multi-system installation,
               An administrator password,
               Multiple user passwords,
               Support for large hard disks,
               Support for multiple hard disks,
               Works with the EGA controller/display,
               Ability to prevent user's from breaking out of AUTOEXEC,
               and others described below.
      (unquote)


Moving time backwards

Paul Smee <Smee@AUCC.AC.UK>
Tue, 8 Mar 88 10:47 GMT
The recent talk about setting time backwards reminds me of something that
happened on the MIT Multics about 10 years ago.  The Multics system clock
counts time as number of microseconds since midnight, Jan 1, 1901 (well, maybe
1900, not sure).  The microsecond clock value at the time when a file is
created is used as unique identifier for the file; there is suitable gating to
ensure that on a multi-processor machine, two processors don't get an identical
clock value.  In order to ensure that file unique IDs really are unique within
a system, the Bootstrap system would not allow the ops to bring the Multics O/S
up if the clock (set manually within BOS) was before the recorded time of the
last shutdown.  (Why HIS didn't put in a permanent battery backed up clock was
always a source of wonder, but is another question.)

One day, after a shutdown, the Ops mistakenly (finger trouble) input a date
which was something like 2 days in advance of the real date -- e.g.  14 March
rather than 12 March -- and started the Multics service.  On realizing their
error, they shut down Multics (back to BOS) to change the date to the correct
one.  The system would then not let them restart Multics.  In that case (and
after a couple of hours of poking thru microfiche) the system programmers
decided it would be quicker just to leave the machine down for two days, than
it would be to try to hack the system code to let them boot, and to ensure that
there were no bad side-effects.  (And, they thanked the gods that the Op had
only missed by a couple of days, rather than getting the month, or worse, the
year, wrong.)  Ultimately, a 'fix' arrived, which consisted merely of having
BOS query the Ops for confirmation if they tried to bring up Multics with a
date-time more than a set interval after the previous shutdown.

   [I tried to GREP this one out of the RISKS archive, but did not find it.
   However, it is my vague recollection that this tale might have been related
   here somewhen in the distant past.  Excuse me if you saw it before.  PGN]


Leap Year

Harold E. Russell <russell@mitre.arpa>
Tue, 08 Mar 88 09:42:36 EST
We seem to have had a flurry of problems with Feb 29.  Please don't 
forget to watchout for Day 366 on Dec 31.


SDI related sources

<DMJ%Vms.Cis.Pittsburgh.Edu@VB.CC.CMU.EDU>
Thu, 3 Mar 88 19:36 EDT
Here is the list of sources relating computers and SDI that I compiled.
Thanks to the people who sent me sources.  
                                Dan Jones

Adam, John A. and Paul Wallich, "Part 1- Mind-boggling
complexity" IEEE Spectrum, September, 1985.

Bellin, David and Gary Chapman, Eds. "Computers in Battle".
Harcourt Brace Jovanovich 1987. in particular: "Computers in the
Strategic Defense Initiative" by Steve Berlin and Eric Roberts.
"The Strategic Computing Program" by Jon Jacky, (which includes
discussion of SCP's relationship to SDI).

Benson, David B., "The Second Labor of Hercules: An essay on
software engineering and the Strategic Defense Initiative".
Washington State University Computer Science Department, 1986.

Boffey, Philip: "Software seen as obstacle in developing 'Star
Wars'.", The New York Times, Sept. 16, 1985.

Buchsbaum, S.: "SDI software: the telephone analogy. Path I: the
software will be reliable.", Physics & Society, 16:2, April,
1987, p. 6.

Dahlke, K.: "SDI software, Part II: the software will not be
reliable.", Physics & Society, 16:2, April, 1987, p. 8.

Eastport Study Group: "A report to the director, Strategic
Defense Initiative Office.", December, 1985.

Eastport Study Group, "Summer Study 1985", Department of Defense
(SDIO).

Fletcher J.C. et al, "Report of the Study on Eliminating the
Threat Posed by Strategic Nuclear Missiles, Vol 5: Battle
Management, Communications and Data Processing" (Unclassified)
Department of Defense. Govet Printing Office, 1984.

Jacky, Jonathan: "The 'Star Wars' defense won't compute.", The
Atlantic, June, 1985.

Lin, Herbert, "Software and Star Wars: An Achilles Heel?"
Technology Review.

Lin, Herbert, _Arms and Artificial Intelligence: Applications of
Advanced Computing_, "Software and Systems in Strategic Defense",
book editor is Allan Din, publisher Oxford, January 1988.

Lin, Herbert: "Software for ballistic missile defense.", MIT
Center for International Studies, Report C/85-2, 1985.

Lin, Herbert, "The development of software for ballistic-missile
defense.", Scientific American, December, 1985, p. 46.

Myers, Ware, "Can Software for the Strategic Defense Initiative
ever be error free?" IEEE Computer, November 1986.

Myers, W., "The Star Wars Software Debate" Bulletin of the Atomic
Scientists, February 1986.

Nelson, Greg, and David Redell, "The Star Wars Computer System"
25 June 1985. (Available from CPSR)

Nelson, Greg and David Redell, "The Star Wars Computer System"
Abacus, Winter 1986.

Nelson, Greg and David Redell, "Could We Trust the SDI Software?"
Chapter 5 of "Empty Promise" by the Union of Concerned
Scientists, Beacon Press, 1986. ISBN 0-8070-0413-8.

Office of Technology Assessment, "Strategic Defenses" Princeton
University, Press 1986. ISBN 0-691-02252-6.

Ornstein, Severo M. "Loose Coupling : Does it Make the SDI
Software Trustworthy?"  October 1986. (Available from CPSR)

Parnas, David L., "Why Communication Systems are Not Like SDI" 8
December 1985. (Available from CPSR)

Parnas, David L., "Software and SDI"  3 December 1985. 
(Available from CPSR)

Parnas, David L., "Software Aspects of Strategic Defense"
American Scientist, Sept/Oct 1985. (Also published in CACM,
December 1985., and a Univ. of Victoria, Dept. of Computer
Science Report DCS-47-IR, July 1985).

Zracker, Charles A., "Strategic Defense: A Systems Perspective"
Daedalus, Spring 1985.

Zracket, Charles A., "Uncertainties in Building a Strategic
Defense", Science, 27 March 1987.


Electronic Privacy Act Info Request

eliot lear <lear@aramis.rutgers.edu>
Tue, 8 Mar 88 20:33:29 EST
I am researching the history and progress of the Electronic Privacy Act.
If you have an educated opinion on the law and wish to express it, please
contact me via E-Mail.         Thanks in advance,            Eliot Lear

Please report problems with the web pages to the maintainer

Top