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

Weds 6 November 1996


o 1996 Melbourne Cup off-course betting fiasco
Harley Mackenzie
o Fidelity Brokerage computer problems
George C. Kaplan
o Bug in the network: a real spider
Nick Brown
o Announcement - Warning to Crypto and Banking Communities
Ross Anderson via Bruce Schneider and Monty Solomon
o Differential Fault Analysis: a possible defence?
David R Brooks
o Ping o'Death from Windows 95
Nick Brown
o Re: Office 97, VBA 5.0, and macro viruses
Otto Stolz
o Web search engines find connected components
David Skillicorn
o Re: Tote Board Crash at Breeder's Cup
Larry Kilgallen
Ian Rogers
Henry G. Baker
o Re: -32768
Paul Eggert
Dik Winter
o Info on RISKS (comp.risks)

1996 Melbourne Cup off-course betting fiasco

Wed, 6 Nov 1996 14:10:15 +1100 (EST)
The Melbourne cup is Australia's premier horse race (handicap over 3200
metres with over $AUS 2 million prize money), that even has its own public
holiday in metropolitan Melbourne. The whole nation stops to listen or watch
the race and lots of once a year punters have a dabble on the cup. The TAB
(used to stand for Totaliser Agency Board when government owned and run, but
now a public company) is the ONLY (legal) provider of off-course racing
betting in Victoria.

However, when the punters turned up at their local TAB (or pub TAB located
in hotels) to place their bets on yesterday's race (5 November 1996) there
were queues that stretched out the door for hundreds of meters. The 15 year
old computer system had failed again on Melbourne Cup day and most small
agencies were off-line from about 10:45 am (AESST) to just before or after
the running of the cup at 3:20pm (AESST), whilst the larger agencies were
off and on with reduced numbers of active windows throughout this period.

Irate punters and TAB agency owners were, of course, furious and a lot of
money that would have been wagered was lost as punters gave up waiting to
try to get a bet placed. The TAB chief executive, Ross Wilson (already
controversial due to his seemingly excessive salary package) was quoted as
saying that the system breakdown "could have been worse"; it is hard to
imagine how. The total loss of money wagered has not yet been calculated,
but it will be huge. Ross Wilson also stated that "of course" there will be
a full investigation of the problems and these will be rectified so that it
doesn't happen again.

Breakdowns of the TAB system on Melbourne Cup day have occurred before with
the last major shutdown 4 years ago.  Yesterday's problem was described as
being the result of software modifications made to the TAB software 10
months prior to the Cup, and the excessive demand due to the huge increase
in the number of bets activated a software bug in these modifications that
lead to a shutdown of the system.

It is difficult to understand how the TAB system could not be designed and
tested to accommodate the peak betting activity as the Melbourne Cup ALWAYS
results in this level of high activity, and is therefore predictable and,
you would imagine, able to be simulated. Agency owners, who are still trying
to recover from the loss of income due to a protracted dispute with Sky
Channel who supply direct TV coverage of horse racing, are now investigating
legal action against the TAB.

Dr. Harley Mackenzie, Principal Operations Research Analyst, Yallourn Energy
114 William Street Melbourne 3000, Australia  +61 3 9207 7719

Fidelity Brokerage computer problems

"George C. Kaplan" <gckaplan@cea.Berkeley.EDU>
Tue, 5 Nov 1996 17:00:49 -0800
An article in the *Wall Street Journal* 4 Nov 1996 describes a major problem
for Fidelity Brokerage Services (a discount stock brokerage) in London.
Very few details are given beyond "late bookings of dividends and other
problems", but it's serious enough that more than 50 people are working
14-hour days to sort through and correct three months of records *manually*.
British authorities have forced FBS to stop taking new customers until the
problems are solved.

It appears to be a familiar story to RISKS readers:  A new system was
rushed into operation in April without adequate testing.  FBS seems to be
in denial, claiming that the system wasn't rushed, but that they simply
"ran into some unanticipated glitches."

George C. Kaplan   510-643-5651

Bug in the network: a real spider

+33)388412674 <"Nick BROWN " <> (Tel>
18 Oct 1996 16:14:03 +0200
About five years ago we were the first on our block to have an Ethernet
segment implemented by a pair of 20 mW infra-red lasers.  We had been
promised that it was pretty reliable; as long as we could see the other
building, so could the laser.

And so it turned out; even though we spanned a canal in the foggiest town in
France, we managed 98% uptime during the first few months (in the winter).
Only on the foggiest days did we lose the connection, until about 10 each
morning and from 4 each evening, for about 5 days total.

Came the spring, and we started to get breaks in the connection at what
seemed to be random times.  Eventually we worked out that it was happening
half an hour after sunrise and half an hour after sunset.  We thought it
might be the sun in line with the laser, but the layout wasn't right for
that.  We changed every component in the network.  Until...

One day, I noticed a spider's web connecting the laser box to the wall.
Something must have flipped to On in my brain's background processing
section, because about three days later (I run background processing on a
very low priority), it dawned on me.  I went up to the roof at the
appropriate time and watched the laser carefully.  Sure enough... a spider
appeared, walked across the web, climbed into the transmission lens, and sat
there (upside down), apparently eating its dinner, while a voice in my ear
called "the link's down again !".

We got a cloth, a box of Q-tips, and an aerosol of insecticide, put them
in a box marked "Network Hardware Maintenance Kit", and set up a weekly
rota for cleaning the laser, and had no more problems.  I dined out on
the story for several months afterwards.

Nick Brown, Strasbourg, France (

Announcement - Warning to Crypto and Banking Communities

Monty Solomon <monty@roscom.COM>
Wed, 6 Nov 1996 03:51:28 -0500
Begin forwarded message:

Date: Sun, 3 Nov 1996 18:16:37 -0500
From: Ross Anderson <> (by way of Bruce Schneier)
Subject: Announcement - Warning to Crypto and Banking Communities

                       A serious weakness of DES
                       Draft - 2nd November 1996


Eli Biham and Adi Shamir [RISKS-18.56] recently pointed out that if an
attacker can induce unidirectional faults in key memory of cryptographic
devices, then keys could be extracted quickly. Although their attack is very
elegant, it is not practical against many fielded systems. For example,
inducing a single-bit change in a DES key will cause a proper implementation
to return a key parity error.

However, when combined with Peter Gutman's recent work on memory remanence,
there are two very practical attacks. One of them allows smartcard
electronic wallet keys to be extracted with much less expensive equipment
than that currently used by pay-TV pirates; the other yields an effective
attack against fielded banking security modules. These attacks show that a
feature of DES that had long been thought innocuous is actually a serious
design error.


In a research announcement of 30th October, Biham and Shamir [RISKS-18.54]
point out that if a cryptographic hardware module employs EEPROM for key
memory only, an opponent who can turn EEPROM values from `1' to `0' with a
small controlled probability (e.g., by applying UV light) might cause a test
input to be encrypted with a series of keys, each of Hamming distance one
from the next in the series, and ending with the all zero key [1].

There are a number of reasons why their attack is not likely to work against
real systems. For example, the typical smartcard system has several
kilobytes of program code in EEPROM as well as typically two to five DES
keys. An undirected stress applied to such a card is more likely to cause a
program crash or an uninformative error than to yield a ciphertext encrypted
under a key at Hamming distance one from a genuine key. Even if we only had
to cause a hundred cards to fail to get a single input for the Biham-Shamir
attack, if we needed on average 28 inputs to recover a DES key, then the
number of cards required could be O(100^28).

The situation is made still worse by the fact that DES keys have odd parity,
and a proper implementation will reject a key if any of its bytes has even
parity. So one would be reduced to looking for keys at a Hamming distance of
two rather than one. It is this objection that inspired the following work.

A Modified Attack

My idea is to turn the DES key parity problem on its head and enable parity
to help rather than hinder the attack. Let us first consider an opponent who
can perform directed attacks on the chip. Reading the contents of an EEPROM
cell directly is difficult, and people who do it for a living use focused
ion beam workstations to modify the chip [2]. However, it is trivial to set
an EEPROM cell to the value of your choice if you do not have to read it
first; you only need two microprobes. A 10mS 18V pulse from the cell's
source to its control gate will do the trick [3].

My modified attack therefore proceeds as follows. Set the first bit of the
EEPROM containing the target DES key to 1 (or 0, the choice doesn't matter)
and operate the device. If it still works, the keybit was a 1. If you get a
`key parity error' message, then the bit was zero. Move on to the next bit;
set it to 1 and see if this changes the device's response (from encryption
to error or vice versa).

This is a practical attack even on chips whose software we do not know in
detail, as many smartcard software writers seem to have adopted a convention
that the keys are located at the bottom end of the EEPROM memory. It will
also work with protocols that use redundancy which we do not understand: we
just change each key bit back to its original value.

The use of predictable memory addresses for keys is not restricted to
smartcards; many banking security modules also keep keys at low memory. I
will now describe a related attack that extracts master keys from these

An Attack on Fielded Systems

In a brilliant Usenix paper [4], Peter Gutman described the mechanisms that
cause both static and dynamic RAM to `remember' values that they have stored
for a long period of time. A prudent security engineer will ask what the
effect of this is in the real world.

I looked at an instance of a security module used in banking. This security
module has 12 pairs of DES master keys stored in low memory.  The device is
tamper resistant in that power to the key memory is cut when the box is
opened for servicing (this is needed every few years to change the battery).
Keys are loaded into the device afterwards in multiple components by trusted
bank staff.

In this device, which dated from the late 1980's, the key values were
substantially intact on power-up. The number of bits in error was of the
order of 5-10%. I cannot give more accurate figures as I was not permitted
to copy down either the correct master key values, nor the almost-correct
values that had been `burned in' to the static RAM chips. I am also not
permitted to name the bank at which these modules are installed, and it may
not be prudent to name their manufacturer.

Nonetheless the crypto community should consider the consequences.

If each DES key is wrong by five bits, then the effort involved in searching
for the 10 wrong bits in a double DES key might be thought to be
112-choose-10 operations. Each operation would involve (a) doing a 2-key
3DES decryption of a 64 bit PIN key whose enciphered value is widely known
to the bank's programmers (b) in the 2^{-8} of cases where this result has
odd parity, enciphering an account number with this as a DES key to see if
the (decimalised) result is the corresponding PIN. The effort is 4 times
112-choose-10 DES operations - about 2^50. But it would probably be cheaper
to do a hardware keysearch on the PIN key directly than to try to implement
this more complex 2^50 search in either hardware or software.

However, the bytewise nature of the DES key redundancy reduces the effort by
orders of magnitude. If no key byte has a double error, then the effort is
seven tries for each even parity byte observed, or 7^10 - about 2^28, which
is easy. If there is one key byte with a double error, the effort is 2^38,
giving a search of 2^40 DES operations - which is still feasible for an


I have shown that the key parity in DES enables us to slash the cost of real
attacks on both old systems (banking security modules) and new ones
(electronic wallet smartcards).

I had already mentioned in [5] that a common fault in the driver software
for banking security modules was that `key parity error' messages were often
ignored rather than copied to the bank's security manager to give warning of
an attempted attack. This note shows that key parity is even more serious
than that.

The nature of DES key redundancy now appears to be a design error; it would
have been much better to calculate the redundancy on the whole key. The 16
bit MAC used in the Clipper and Capstone chips is preferable (although as
shown in [6], 16 bits may not be enough to prevent some protocol attacks).

The lesson for bankers is that existing security modules (and other
cryptographic devices) should be destroyed carefully at the end of their
working life.

The lesson for security engineers is that we should add key redundancy, and
the question of whether we can rely on a device's eventual destruction, to
the growing list of system parameters that must be (a) explicitly considered
during design and (b) examined carefully when the product is being


[1] ``The Next Stage of Differential Fault Analysis: How to break completely
unknown cryptosystems'', Eli Biham, Adi Shamir, October 30th, 1996

[2] ``Tamper Resistance - A Cautionary Note'', Ross Anderson, Markus Kuhn, to
appear at Usenix Electronic Commerce 96 (19th November)

[3] ``Hardwaresicherheit von Mikrochips in Chipkarten'', Osman Kocar,
Datenschutz und Datensicherheit v 20 no 7 (July 96) pp 421--424

[4] ``Secure Deletion of Data from Magnetic and Solid-State Memory'', Peter
Gutmann, Usenix Security 96 pp 77--89

[5] ``Why Cryptosystems Fail'', Ross Anderson, in Communications of the ACM v
7 no 11 (Nov 94) pp 32--40

[6] ``Protocol Failure in the Escrowed Encryption Standard'', Matt Blaze, in
Proceedings of the 2nd ACM Conference on Computer and Communications Security
(2-4 November 1994), ACM Press, pp 59--67

Differential Fault Analysis: a possible defence?

David R Brooks <>
Wed, 06 Nov 1996 07:03:54 +0800
There has been much discussion lately, of the DFA attack on various
cryptosystems. Defence strategies appear to be based on replication, either
in space (dual-redundant crypto units, which check each other), or in time
(do the crypto twice, and compare the results). Both techniques suffer from
the same drawback: cost.

It occurs to me that a defence could be based on the use of RAM, rather than
ROM or hardwired logic, to embody the crypto algorithm. In practical terms,
this would mean a hardware embodiment using (say) a RAM-based FPGA, or a
software system which would copy the code to RAM before execution.  The
point here is that there would be typically far more RAM bits used to
specify the algorithm than are used to hold data-in-process. The odds are
that an induced error will corrupt the operating code, rather than a data
bit. The result will be either total garbage output, or the result of a
"different" algorithm (the original, plus errors).  Does this idea have any

Dave Brooks <>

Ping o'Death from Windows 95

+33)388412674 <"Nick BROWN" <> (Tel>
6 Nov 1996 17:18:18 +0000
Anybody with an Internet site, especially those without firewalls, should
check out  It details how anybody with
Windows 95 and an IP address (hmmm, there might be one or two out there...)
can crash a large range of network equipment (HP 3000, DEC Alpha, IBM
RS/6000, LaserJet printers, Netware servers, Windows PCs, routers, etc),
apparently across the entire Internet.

Nick Brown, Strasbourg, France

Re: Office 97, VBA 5.0, and macro viruses (Slade, RISKS-18.57)

Otto Stolz <>
Wed, 6 Nov 1996 17:26:40 +0000
Re: Slade in RISKS-18.57 and VIRUS-L 9#208

Visual Basic is not the sole reason for these viruses to spread.
A virus needs three preconditions to spread:
- a platform that will execute its instructions,
- a vehicle in which it will be passed between users,
- a mechanism by which it will be executed unnoticed by the user.

For the Word macro viruses, the platform is the Word macro language. VBA 5
will indeed make an upwards-compatible platform more widely available.
However, Visual Basic is only sort of a syntactical framework: most standard
functions and statements are only valid for a particular application. (I do
not know VBA 5.0 yet, but I have coded a few macros both for Word 6.0 and
Excel 5.0 and found that the major part of the language were
application-specific, in both cases.) Hence, most VBA programs probably will
only work with a particular application. So I think, we will not see a much
more widely available platform for viruses to spread on, but rather a couple
of similar, yet mutually almost incompatible platforms.

A platform in itself is no particular thread, virus-wise. Platforms are
useful (after all, they are the sole purpose computers are built for).  We
should not worry about the proliferation of platforms, but rather on the
other two preconditions for viruses to spread.

The vehicle for the Word macro viruses is Word templates disguised as
documents. It was Microsofts greatest sin to allow Word templates (which
contain the macros) to come disguised as documents. Word documents are
widely, and frequently, exchanged amongst users. Now, if any document
(according to the user's perception - even if it is, technically speaking,
some other beast) can contain macros, this will constitute an ideal vector
for macro viruses.

This is one of the two main reasons for Word macros to spread so rapidly. If
the macros would be confined to separate files (as with most other
applications), users would most probably leave the macros behind when giving
away documents.

Word has two clandestine-execution mechanisms: macros with particular names
(such as AutoOpen) are executed without explicit user action (e.g. when a
document is opened) -- before the user even sees the document to be opened;
macros with other particular names are bound to explicit user actions, such
as hitting a button, or selecting a menu item. (If you think this is only
one mechanism, you are probably right. No discussion on this triviality,

In particular, the AutoOpen macro mechanism is the other main reason for
Word macros to spread so rapidly: with this mechanism in place, a user needs
only to *view* a Word document (e.g. an attachment of an e-mail message, of
a news item, or of a WWW page) to contract a virus!

Conclusion: VBA 5.0 is not a particular threat, as long as the applications
using it do not repeat Word's mistakes.  Most important is to keep macros
apart from application data (such as documents or spread-sheets); second
most important is to avoid executing macros without the user's consent.

Otto Stolz

Web search engines find connected components

David Skillicorn <>
Wed, 6 Nov 96 12:32:35 EST
The altavista search engine at least finds files that do not have URLs
pointing to them, as long as they are in directories that it visits for
other reasons. I discovered this when a search of a well-known CS repository
turned up files containing all sorts of administrative information, not
intended for public consumption.

It seems sensible to keep only things you want seen in directories that web
servers can access. Having permissions set properly will prevent web servers
seeing other files, but fouling up permissions is an easy error.

Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57)

"Larry Kilgallen, LJK Software" <KILGALLEN@Eisner.DECUS.Org>
Tue, 05 Nov 1996 19:20:34 -0500 (EST)
I think there is a Risk in attempting to add the more robust features at the
more shaky end of the language spectrum.  Ada syntax (but not necessarily
every implementation) supports unlimited programmer-specified ranges.  That
would seem a better starting place for programmer-unspecified ranges.

Anyone for zero-terminated integers ? :-)

Larry Kilgallen

Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57)

Ian Rogers <>
Wed, 6 Nov 96 14:32 GMT
Perhaps you should check out Poplog Pop11. It is used mostly at research
institutes, but also at some major process control sites where its
garbage collection and wide range of number formats is highly valued.

Among its number formats are: fixed int, small float, double float, ratio
(i.e. 10/3 is *not* approximated), imaginary (sqrt(-1) returns a sensible
answer), and big ints (integers as big as the size of your VM -- one of the
standard pop11 benchmarks is to calculate factorial(1000) :-) Conversion
between number formats is automatic in all the arithmetic functions.

Contact or comp.lang.pop
Ian Rogers, Sussex University

Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57)

Henry G. Baker <>
Wed, 6 Nov 1996 08:07:34 -0800 (PST)
The Symbolics Lisp machine defaulted to 'infinite' (indefinite)
precision integers.  In fact, this property was inherited by other
languages which ran on this machine, e.g., Fortran-77.  'Integers'
in Symbolics Fortran would happily take on values like


Quoting from "User's Guide to FORTRAN 77 Tool Kit", August 1986:

"The Tool Kit supports arbitrary-precision integers, called _bignums_;
as a result, all integers are immune from overflow..."

"The only operation for which arbitrary-precision integers are _not_ valid
is _unformatted_ input/output.  In this case, integers must be between -2^31
and 2^31-1."

"The Tool Kit detects uninitialized data (other than character data), so
that an error condition results if a variable is used before it is assigned
a value."

"The Symbolics Lisp Machine provides strong hardware data-type checking
among logical, integer, and real data.  Thus, the hardware prevents a
program error due to equivalencing of the data, for example, in the case
where the exponent and mantissa of a real number might be interpreted as an

(I might point out that many of the standard Internet attacks which depend
upon poor type or array bounds checking are worthless against such machines;
I understand that they remained up and happily running, after many of their
Unix brethren had been hopelessly compromised by Internet worms and other

These significant advances in the quality of Fortran software was _not_
appreciated by Fortran programmers, and the porting of existing Fortran
programs -- which use such equivalencing very heavily -- became a nightmare.

However, the market was not kind to Symbolics, proving that software quality
is not a particularly important feature in a computer system, as judged by
paying customers.

Re: -32768 (Brader, RISKS-18.55)

Paul Eggert <>
Wed, 6 Nov 1996 11:32:37 -0800
Mark Brader's discussion of -32768 is correct as far as it goes, but it
omits some of the more entertaining aspects of C expression evaluation.
Here's a table that may help RISKS readers appreciate some of the finer

This table uses the usual C notation: an `0x' prefix means hexadecimal; an
`L' suffix means the type is `long'; `U' means `unsigned'.  2's complement
arithmetic is assumed, so none of the expressions overflow.  [SEE NOTE
BELOW.]  `*' marks disagreements with the usual mathematical meanings of

  C expression         value of C expression, assuming:
                      16-bit `int'           32-bit `int'

     32768              32768L                 32768
    0x8000              32768U                 32768

    -32767 - 1         -32768                 -32768
    -32768             -32768L                -32768
   -0x8000              32768U *              -32768

 -0x8000 == -32768          0  *                   1

   0U < -32767 - 1          1  *                   1  *
   0U < -32768              0                      1  *
   0  < -0x8000             1  *                   0

Is everything clear now?

  [NOTE added, at Mark Brader's suggestion: Paul's assumption is one that
  is assumed for this posting only; it is not guaranteed by the language.
  In particular, C can be legally implemented on 1's complement hardware,
  where the value -32,768 is not permissible in a 16-bit int (or short)
  at all.  MB via PGN]

Re: -32768 (Fredriksson, RISKS-18.57)

Wed, 6 Nov 1996 14:39:35 GMT
What you are missing is that "-32768" in C is not a constant but an
expression.  The type of a C expression depends on the type of the operands
and the operator.  In this case the operand is "32768", the operator is "-".
The type of 32768 is "long" if the type "int" is only 16 bits, and so the
type of "-32768" is "long" in that case.  But in the context of the
definition of INT_MAX the type should be "int".  On the other hand, when we
write "-32767 - 1" the type is "int" because all constituent parts are of
that type.

  [This item is included to close the discussion off.  Bear Giles had it
  exactly right in his followup in RISKS-18.49, and it might have been
  better for me to have pointed that out privately to Kurt Fredriksson.
  But the error is a common one, so perhaps it was worth flogging it once
  more.  Strong typing is the answer to a lot of questions, but it also
  helps to understand the questions.  PGN]

Please report problems with the web pages to the maintainer