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 60

Friday 8 November 1996

Contents

o Re: Why cryptography is harder than it looks
PGN
o Back In Time
Peter Wayner
o Risk of Earthquake Risk
Harold Asmis
o Mobile Phone Mayhem!
Trevor Warwick
o "NetLaw: Your Rights in the Online World" by Lance Rose
Rob Slade
o The final version of the NRC crypto report is now available!
Herb Lin
o Re: -32768 and strong typing
Jerry Leichter
o Re: Arbitrary precision arithmetic
Robert I. Eachus
o Re: Tote Board Crash at Breeder's Cup
Bear Giles
Mark Eichin
o Re: S-Bahn stopped by new switching software
Bob Frankston
o Call for papers: SafeComp'97
Bob Fields
o Info on RISKS (comp.risks)

Re: Why cryptography is harder than it looks (Schneier, RISKS-18.59)

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 8 Nov 96 10:58:21 PST
I must apologize to Bruce for including a version of his thoughtful item in
RISKS-18.59 that he sent to the RISKS address that I mistakenly thought was
his expected final version, but that was actually a draft in progress, sent
for my information.  As a consequence, I will be happy to run his final
version whenever it is ready, and pardon your inconvenience for having to
read two perhaps quite similar versions.  Bruce has also asked me to ask you
all to desist from redistributing copies around the net until the final
version is ready.


Back In Time

Peter Wayner <pcw@access.digex.net>
Fri, 8 Nov 1996 12:51:07 -0500
Do you want to go back in time before the TWA 800 came down?  It's easy.
I've gotten in the habit of using Alta Vista to search the RISKS database
maintained in England on the web.  Today, I was trying to dig up the old
issue containing the story about the missile that took out a garage in
British Columbia. So I sent this string:

+risks +neumann +vancouver +missile

The plus signs force Alta Vista to return documents that contain that word.
I've found that the word Risks and the name of our intrepid moderator is a
great way to cut out the rest of the noise. This may be inefficient, but it
is easier than remembering where a specific RISKS database is kept.

But the article didn't show up on the list. Surprisingly, there were a few
other references. After some experimentation, I've discovered that the Alta
Vista web crawler hasn't visited the UK website archive for some time. So
the issue (18.40) wasn't included in its database.

The RISKS is that there is no easy way to tell how up-to-date
Alta Vista may be. It may have indexed one region of the Net
last night and another three months ago. I predict that this is
another feature for web crawlers to work upon.

  [I noted in an earlier issue (RISKS-18.13) that Alta Vista may still think
  crvax.sri.com is the RISKS archive site rather than the up-to-date archive
  at ftp.sri.com.  I hope someone can finally fix that problem.  The cutover
  took place almost two years ago, but apparently the old crvax archives are
  STILL in place and they include only issues up to RISKS-16.64.  PGN]


Risk of Earthquake Risk

Harold Asmis <harold.w.asmis@hydro.on.ca>
Thu, 07 Nov 1996 14:01:29 -0500
Last week, the new California Earthquake Insurance agency announced that
they would shortly be releasing a billion dollars worth of Earthquake bonds,
which pay diminished returns if there is a major California earthquake.
This step was necessary because most insurers are pulling out of California
earthquake insurance, due to the inadequacy of reserves.  We wonder about
the RISK of a state-run insurance agency locating all its computers and
staff (for payouts and bond administration) in the very state the flattening
of which would trigger these bonds and payouts.

Harold W. Asmis        harold.w.asmis@hydro.on.ca  tel 416.592.7379


Mobile Phone Mayhem!

"Trevor Warwick INF-SP" <twarwick@madge.com>
Thu, 7 Nov 96 17:18:26 -0000
Another twist on the well known "Cleaner buffs computer room floor and takes
down entire site" stories:

We recently had some engineers from AT&T in our computer room for three
days, working on a PABX which also lives in there. During this period, two
of our main Netware servers have been extremely unreliable, crashing several
times a day. The AT&T engineers were working near these servers, and we
initially thought that they might have been causing the crashes by
disturbing some cables.

After a few of these unexplained crashes, one of our MIS group noticed that
every time he went in to the server room to reboot the dead servers, one of
the AT&T engineers was using his mobile phone. So, they were asked to turn
their phones off while working in the server room, and the problem has not
reoccurred.

To test the theory a bit further, the MIS group then took an otherwise
unused server, and experimented with using a mobile phone near it. With the
working phone being used less than a foot away from the machine, they
provoked a crash which corrupted the system disk (and its mirror volume)
beyond repair.

Trevor Warwick, Madge Networks, Sefton Park, Bells Hill, Slough, England
+44 (0)1753 661401  twarwick@madge.com  fax   : +44 (0)1753 661011


"NetLaw: Your Rights in the Online World" by Lance Rose

Rob Slade <roberts@mukluk.hq.decus.ca>
Wed, 06 Nov 1996 14:00:37 EST
BKNETLAW.RVW   950406

"NetLaw:  Your Rights in the Online World", Lance Rose, 1995, 0-07-882077-4,
 U$19.95
%A   Lance Rose
%C   2600 Tenth St., Berkeley, CA   94710
%D   1995
%G   0-07-882077-4
%I   McGraw-Hill
%O   U$19.95 510-548-2805 800-227-0900 lkissing@osborne.mhs.compuserve.com
%O   pmon@osborne.mhs.compuserve.com
%P   372
%T   "NetLaw:  Your Rights in the Online World"

Very similar to his earlier "Syslaw" (cf. BKSYSLAW.RVW), this is a general
guide to various legal aspects of life online.  The major changes are the
broadening of the scope from BBS level systems to include online services
and the Internet, and very handy (and interesting) sidebars, which give a
thumbnail sketch version of the topic under discussion.  These usually
include a reference to some specific case.

Chapters address the issues of censorship, contracts, commerce, and
copyright.  Chapter four, which deals with the responsibility of the system
operator in light of online dangers, does touch on the topic of malicious
software.  I was disappointed that this is limited to a not terribly
accurate defining of terms, and almost no discussion of the admittedly
confused legal situation.  Further chapters cover privacy, crime, search and
seizure, and a rather disappointing chapter on obscenity.  Appendices
include some very useful sample contracts, and various US laws.

Given recent developments which have strongly indicated the international
nature of the net and international legal ramifications, it is discouraging to
see that Rose still presents only a limited and US-centric view.  However, the
general principles he describes are held in common law, and this book should at
least provide guidance for the broader online world.

copyright Robert M. Slade, 1995   BKNETLAW.RVW   950406

Vancouver Institute for Research into User Security Canada V7K 2G6
ROBERTS@decus.ca  Robert_Slade@sfu.ca  rslade@cyberstore.ca  rslade@sfu.ca


The final version of the NRC crypto report is now available!

"CRYPTO" <crypto@nas.edu>
Fri, 08 Nov 96 15:28:00 EST
The Computer Science and Telecommunications Board (CSTB) of the National
Research Council (NRC) is pleased to announce the availability of its
cryptography policy study "Cryptography's Role in Securing the Information
Society".  This report was originally released in pre-publication form on
May 30, 1996.

The final printed version of this report can be obtained from the National
Academy Press, 1-800-624-6242 or Web site http://www.nap.edu/bookstore.  The
pre-publication version and the final printed copy differ in that the
printed copy contains an index and many source documents relevant to the
crypto policy debate; of course, editorial corrections have been made as
well.

An unofficial ASCII version of the prepublication report can be found at
http://pwp.usa.pipeline.com/~jya/nrcindex.htm; the official NRC version
should become available online in ASCII form in December.

In addition, CSTB has been conducting briefings on this report at various
sites around the country; if you would like to arrange a briefing in your
area, please let us know (cstb@nas.edu, 202-334-2605).

[Message from Herb Lin]

  [I note that when we held a briefing on the West Coast, Herb was surprised
  to find that a scanned copy of the original report had already appeared
  on-line, shortly after the draft report had been released.  The final
  version is over 700 pages with all the appendices.  But I suspect that an
  unofficial on-line version of the official report may not be far behind --
  despite its copyright.  Incidentally, the full report is an extraordinary
  source of background material.  PGN]


Re: -32768 and strong typing

Jerry Leichter <leichter@lrw.com>
Thu, 7 Nov 96 00:33:42 EDT
Just when you thought everything there was to be said about this issue had
already been said, our esteemed moderator commented that "Strong typing is the
answer to a lot of questions, but it also helps to understand the questions".

Unfortunately, strong typing is *not* the answer to this particular question!

Niklaus Wirth probably deserves to be considered the inventor of strong typing
with his development of Pascal.  (The idea was probably around earlier, but
no one talked about it much until Pascal's advantages and faults were under
discussion.)  Pascal had no unsigned type, so the question at hand didn't
arise.

Wirth next designed the Modula and Modula-2 languages.  I don't know much
about Modula, but Modula-2 has both INTEGER (C int) and CARDINAL (C unsigned)
types.  Modula-2 is strongly typed, and has no implicit conversions.  It
isn't possible to mix INTEGER's and CARDINAL's in an expression.  (You can,
of course, include explicit type conversions.)  This avoids all the complexi-
ties and ambiguities that occur in C when signed and unsigned types "meet
across an operator".  So, indeed, our moderator is correct:  Strong typing
helps.

However, the problem of constants remains.  Modula-2 does not have an explicit
"unsigned constant" marker; integral constants are just strings of digits.
(By the way, Modula-2, like C, considers -1234 to be the unary minus operator
applied to the constant 1234.)  What type should be assigned to integral
constants?  Choosing either INTEGER or CARDINAL causes problems since then
it becomes impossible to, say, compare a CARDINAL or INTEGER to a constant
value without an explicit conversion.  The *intent* all along has been that
integer constants should take on "the right" type; but getting that defined
right turned out to be unexpectedly difficult.  (-1234 ought to be INTEGER,
never a CARDINAL - but it's not a constant, it's an expression.  If we say
that the result of negation is always an INTEGER, then --1234 and 1234 have
different types - rather annoying.  And how about -0?  Do we have to assume
constant folding as part of the language definition?  And so on, and so on.)

Modula-2 was officially defined by Wirth's book, "Programming in Modula-2",
which went through four editions.  Each edition contained changes to the
language definition.  I believe that the details of the treatment of constants
changed with each edition.  There is currently an ISO draft standard for
Modula-2; it uses an entirely different approach for defining the semantics of
integral constants, in yet another attempt to get at the "obvious" meaning.
(The standard, as I understand it, assigns an abstract "NUMBER" type to
constants.  Unlike actual types, this abstract type *can* be automatically
coerced - to INTEGER or CARDINAL, as the case may be.  The details of this
abstract type then need to be worked out....)

So strong typing didn't help quite enough.

It's instructive to consider yet another language, Modula-3.  Modula-3 was
developed at DEC SRC by a number of people, with consultation and review
from Wirth.  Like Modula-2, Modula-3 has types called INTEGER and CARDINAL.
Like Modula-2, Modula-2 is strongly typed.  However, Modula-3 chose to avoid
the entire issue of the typing of integral constants, and all other
questions about how signed and unsigned values interact, by defining
CARDINAL differently: In Modula-3, CARDINAL is simply the non-negative
members of the INTEGER type.

Now, one reason Modula-3 was able to do this is that it pretty much assumes
32-bit integers.  With 16-bit integers, there was often good reason to want
to use unsigned values simply to expand the range of counters and such.
With 32-bit integers, that's hardly ever worth the effort.

By the way, for those who might object that there are legitimate uses for
true unsigned arithmetic: Modula-3 actually provides that, in the form of a
required interface that defines a WORD type and various operations on it.
WORD is in fact a synonym for integer, but the operations treat WORDS as
unsigned values.

Sometimes the right solution is not to trim the leaves but to pull the weed
out by its roots.  To those of us who programmed on 16-bit machines -
including, it seems, Niklaus Wirth - it takes a bit of effort to realize
that the tricks we had to use to get enough range out of our integers simply
are no longer needed, and there's no longer a need to distort our languages
to try to support them.  But that's clearly the way to sanity.

-- Jerry


Re: Arbitrary precision arithmetic (Kilgallen, RISKS-18.58)

"Robert I. Eachus" <eachus@spectre.mitre.org>
Thu, 7 Nov 1996 21:38:31 -0500
Actually every Ada compiler supports arbitrary precision arithmetic--at
compile time.  Static integer constants are required to be evaluated without
overflow, and the easiest way to guarantee this is to evaluate them using an
arbitrary precision arithmetic package.

Most compiler vendors use a package written over a decade ago by Gerry
Fisher, and almost all of them make it available to users as well.  Of
course this requirement has its disadvantages, a early "bug" in many Ada
compilers was that type declarations like:

  type My_Int is range 0..2**Integer'Last - 1;

Took a VERY long time to be rejected.  (Dave Emery discovered this problem
by accident.  He intended to write 2**Integer'Length...)


Re: Tote Board Crash at Breeder's Cup (RISKS-18.56,57)

Bear Giles <bear@indra.com>
Thu, 7 Nov 1996 10:29:16 -0700
There are numerous implementations of indefinite-precision arithmetic in C
(e.g., the Gnu "mp" package); several of these have been encapsulated into
strong C++ classes.  Implementations include both a (very large) fixed-sized
array and a malloc'd array.

Unfortunately, there are several problems with these packages:

 - speed (compared to "regular" integers),

 - file I/O is _much_ more difficult when you don't know how long
   your integers can be, and

 - ITAR restrictions on export of munitions.

The last point isn't a mistype -- I'm not an unbiased observer,
but every implementation I've seen has been part of a cryptographic
package... and once you have a good indefinite-precision arithmetic
package it's trivial to implement many cryptographic protocols.

Bear Giles bear@indra.com


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

Mark Eichin <eichin@cygnus.com>
06 Nov 1996 14:58:05 -0500
> To my mind they are as silly as bugs which arise in programmes because of
> fixed length strings, such as the famous one in sendmail where it didn't
> check the size of a string it was strcpy'ing into a fixed length buffer.

Point of information: the fixed length buffer was in "fingerd", not
sendmail.  sendmail had a much more obvious problem (a "DEBUG"
function that was not removed in production.) It was noted that the
problem (using the unsafe "gets" function) was tiresome even then...

(See http://www.mit.edu/people/eichin/virus/main.html for more details
than most people would ever want, or CACM 6/89, or IEE S&P 5/1/89.)


Re: S-Bahn stopped by new switching software (Weber-Wulff, RISKS-18.55)

<Bob_Frankston@frankston.com>
Fri, 8 Nov 1996 14:02 -0500
We have ways of assuring that software won't fail?  Please enlighten me. We
have ways of reducing the likelihood.  But assuring?

I too am happy that no one got killed, the rest is a detail.

OK, to be fair, the getting the same naive error in a second implementation
does sound inexcusable but we should confuse the inability to simulate the
complete real-time operation (or even, the failure to do so) with the gross
error of ignoring a known critical bug. This is not about assurance but, if
true, about incompetence.

  [Also commented on by Mark Stalzer, mas@acm.org.  PGN]


Call for papers: SafeComp'97

<bob@minster.cs.york.ac.uk>
               Call for Papers
                 SAFECOMP'97
         The 16th International Conference on
          Computer Safety, Reliability and Security
            University of York, UK
               September 8th-10th, 1997
                   Sponsored by EWICS TC 7
     European Workshop on Industrial Computer Systems Technical Committee 7

SAFECOMP is an annual event reviewing the state of the art, experiences and
new trends in the areas of computer safety, reliability and security. The
conference focuses on critical computer applications. It is intended to form
a platform for technology transfer between academia, industry and research
institutions.

Papers are invited on all aspects of computer systems in which safety,
reliability and security are important. Industrial sectors include, but are
not restricted to, avionics, space industry, railway and road
transportation, process industry, automotive industry, and research.

Papers due by 1 Feb 1997.

For more information on the conference, the full call for papers, and
submission instructions visit our world wide web site at:

    http://www.cs.york.ac.uk/safecomp-97

or contact:

Ginny Wilson, SAFECOMP'97, Department of Computer Science, University of York
York, Y01 5DD, UK    Tel: + 44 1904 432782    Fax: + 44 1904 432708
Email: safecomp-97@minster.york.ac.uk

Please report problems with the web pages to the maintainer

Top