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 10

Friday, 15 January 1988


o Multimillion $ Fraud Failed due to Computer Error
Frans Heeman
o Library Privacy
Michael Wagner
o A reverse Heisenbug: it's there only if you look for it
Dave Platt
o "The Consultant" on TV
Jim Horning
o The timewarps of '88
Rayan Zachariassen
o Info on RISKS (comp.risks)

Multimillion $ Fraud Failed due to Computer Error

Frans Heeman <mcvax!!frans@uunet.UU.NET>
14 Jan 88 09:01:57 GMT
In the Dutch newspaper "De Volkskrant" of Tuesday january 12 and
Wednesday january 13 1988, two articles appeared on a computer fraud
that was discovered by ... an error of that same computer.

    An employee of a bank in Amsterdam (name of the bank not mentioned)
    transferred $15.1 million to a Swiss account, using the computer. To
    make an international money transfer, two persons must give
    permission. Each of them has a secret password. The employee knew
    the password of one of his collegue's, and had a password himself,
    and thus could make the money transfer on his own.

    On december 24, the employee tranferred $8.4 million and
    $6.7 million to a bank in Zurich. Due to a technical malfunctioning,
    the transfer of $6.7 million failed. After Christmas, other
    employees saw on their terminalscreen that the transfer had failed,
    got suspicious, and reported to their superiors.

    According to the Volkskrant, many banks use the same system, and
    this method of fraud "occurs presumably more often, although the
    banks are very quiet about this". The employee is arrested.

This makes me wonder about fail-safe computers: a fail-safe computer would
have failed to save the bank from THIS fraud :-)
                                   Frans Heeman,

Library Privacy (RISKS DIGEST 6.8)

Michael Wagner +49 228 303 245 <WAGNER%DBNGMD21.BITNET@CUNYVM.CUNY.EDU>
Fri, 15 Jan 88 14:02 CET
  In Risks 6.8, Steve Cisler wrote
> This means that no one ... can get a profile of your reading habits
> from checking old records.  There are just not any--except overdue items ...

This comes up from time to time, but it's worth pointing out again.  Don't
forget to think about (and talk about) the backup system.  This system,
designed explicitly for the re-creation of old data in certain, failure
situations, can be (mis)used to recreate the data in other situations unless
the backup system is designed with data protection and selective erasure in
      [The old Contragate so-you-thought-you'd-deleted-it problem...  PGN]

A reverse Heisenbug: it's there only if you look for it

Dave Platt <coherent!>
Fri, 15 Jan 88 10:05:35 PST
I've encountered a marvelous Heisenbug (a bug whose behavior changes when
you look for it) involving TOPS Spool and MultiFinder.  Yesterday, I
installed MultiFinder on one of the Mac SE systems here at work.  After
rebooting, I found that TOPS Spool worked fine when the system was booted in
Finder mode, but behaved erratically when the system was booted in
MultiFinder mode.  The primary symptom I saw was that TOPS Spool would spool
the file to disk, but would not print it.  The status display would
indicated "Waiting; source: AppleTalk", and the printer's yellow status
light would double-blink (indicating that the printer was waiting for data
to be sent over AppleTalk).  This wouldn't always occur, and didn't always
occur at the same point in a file.  I tried spooling one file several times,
and the copies seemed to exhibit different behavior.

Finally, I noticed one critical clue:  if I had turned "Print while I work"
off, and then opened the TOPS Spool d/a and turned it back on, the spooler
would not begin transmitting the file until I closed the desk accessory.
Printing would then begin, and would continue to work properly until I opened
the desk accessory again... at which point the current print job would hang!

So... hmmm... using the TOPS Spool desk accessory under MultiFinder causes the
background printing task to stop working, but using exactly the same desk
accessory, System, drivers, etc. works just fine if the system is booted under
the Finder.  What's the difference?  Well, under MultiFinder, desk accessories
are normally opened by a mini-application called DA Handler, so that they won't
go away if you "Quit" from your current application.  I tried opening TOPS
Spool while holding down the Option key, which forces the desk accessory to run
in the current application's context... and, lo and behold, background printing
kept working! Apparently, the TOPS Spool desk accessory interferes with the
background-printing task if it's run under DA Handler, but not if it's run
under the current application (Finder, in my case).

So... this is really a reverse Heisenbug, of sorts... the software works unless
you look to see whether it's working, at which point it stops working!

Dave Platt
  UUCP: ...!{ames,sun,uunet}!coherent!dplatt
  Internet: coherent!,,

     [For those of you who weren't in on the original flurry of Heisenbugs,
     see RISKS-4.30 through 36, and a few subsequent issues.   PGN] 

"The Consultant" on TV

Jim Horning <>
15 Jan 1988 1447-PST (Friday)
I got many responses to my question.  Here are some relevant excerpts:

From: (Cliff Olling)

I caught 2 or 3 episodes of it quite by accident about 6 months to
1 yr ago.  It was showing on one of the PBS stations on our cable
here in Ithaca.  I think the PBS stations are in Scranton, PA, and
Binghamton & Syracuse, NY.

As for the content, I found it interesting from the theatrical as
well as the technical sense.  The consultant didn't seem to be blatantly
"bat", and I don't remember actually took any money.  He seemed more
like an adult version of the typical teenage hacker stereotype.  The
technical parts (actually typing on terminals, using modems, etc.),
actually seemed fairly realistic.  There were no whirling tape drives
or modems going Beep-Boop-Beep-Boop a'la War Games.  All in all, very
little suspension of disbelief was required.

From: (Dave Curry)

"The Consultant" BBC television series was aired on the Arts &
Entertainment Network (a cable channel) on Monday evenings about two
years ago.  If I remember right, they broke it into five or six episodes
instead of four, each was an hour long.

The series wasn't too bad... they actually used "computer words", and
didn't do anything silly like make the terminal beep for each character
it printed, etc.  Some stuff was simplified for the general public, but
overall I found it an enjoyable series.

The A&E Network tends to re-air most of their more popular shows every
year or two.

From: (Don Watrous)

I've seen it play on A&E (cable) a couple of times within the last
year or two.  ...  I remember the characters and the premise, but
don't recall being very impressed.

From: Lee Barford <barford%hplabsb@hplabs.HP.COM>

The Arts & Entertainment Network played it twice, about 18 months
ago and again about a year ago.

    [Some of this covered by comments from Brian Kantor, Scott C Crumpton, 
    Dave Curry, Dwight D McKay, Alan Wexelblat, ... PGN]

The timewarps of '88 [More Leap Year details -- SEE RISKS-6.4 to 7]

Rayan Zachariassen <>
Thu, 14 Jan 88 22:16:10 -0500
Not having anything better to do last New Year's evening, it seemed like
a good opportunity to synchronize our computer clocks with reality.  So,
as the leap second approached, my finger was poised on the RETURN key.
Poof, the New Year arrived and the clock was back in sync.  Ten minutes
later, the computer was half an hour into '88.  Hmmm, didn't look right.
For the next couple of hours, I was chasing the system clock the way a
cat stalks its evasive prey.

A day or so later, the first reports appeared of other people having the
same problem (by this time I was used to frequent timewarps on the system).
The problem turned out to be caused by a classical programming error:

    Macro arguments with side effects are Bad Style.

The problem was in the clock maintenance software in the kernel, where
a C macro defined as:

#define MONTHSEC(mon, yr)   \
    (((((yr) % 4) == 0) && ((mon) == 2))? 29*SECDAY : monthsec[(mon) - 1])

was called using:

    ... MONTHSEC(--mon, year);

instead of:

    ... MONTHSEC(mon, year);

The code was written after the previous leap year, and the double-evaluation
of the first argument would not occur until another leap year.  Some knee-jerk
analysis of the problem wrongly blamed the leap second (what with all the
publicity).  Since most clocks and software don't know about leap seconds,
this was not plausible.

Considering the 40000-odd (my estimate) computers that were affected by
this problem, many many people were thinking of the careless programmer
with warm, sizzling, thoughts.  It didn't reflect well on the employer/vendor
either, both in letting this problem slip by them, and in letting an apparent
novice write such a critical section of code.  I realize my criticism may
be harsh, but it is coloured by the severity of the problem, having
experienced it, and knowing the cause.

On a vaguely related matter, the latest issue of The Economist (9-15 Jan 88)
has an article titled "Something Rotten in the State of Software".  It is
a 3-page overview of computer bugs, what causes them, and what to do about it.
Several Risks issues, and people (Neuman, Parnas, Leveson), are mentioned.

Never trust computers.

Please report problems with the web pages to the maintainer