Subject: RISKS DIGEST 18.60

Subject: RISKS DIGEST 18.60

RISKS-LIST: Risks-Forum Digest Friday 8 November 1996 Volume 18 : Issue 60

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

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

----------------------------------------------------------------------

Date: Fri, 8 Nov 96 10:58:21 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Re: Why cryptography is harder than it looks (Schneier, RISKS-18.59)

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.

------------------------------

Date: Fri, 8 Nov 1996 12:51:07 -0500
From: [email protected] (Peter Wayner)
Subject: Back In Time

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]

------------------------------

Date: Thu, 07 Nov 1996 14:01:29 -0500
From: [email protected] (Harold Asmis)
Subject: Risk of Earthquake Risk

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 [email protected] tel 416.592.7379

------------------------------

Date: Thu, 7 Nov 96 17:18:26 -0000
From: "Trevor Warwick INF-SP" <[email protected]>
Subject: Mobile Phone Mayhem!

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 [email protected] fax : +44 (0)1753 661011

------------------------------

Date: Wed, 06 Nov 1996 14:00:37 EST
From: Rob Slade <[email protected]>
Subject: "NetLaw: Your Rights in the Online World" by Lance Rose

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 [email protected]
%O [email protected]
%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
[email protected] [email protected] [email protected] [email protected]

------------------------------

Date: Fri, 08 Nov 96 15:28:00 EST
From: "CRYPTO" <[email protected]>
Subject: The final version of the NRC crypto report is now available!

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 ([email protected], 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]

------------------------------

Date: Thu, 7 Nov 96 00:33:42 EDT
From: Jerry Leichter <[email protected]>
Subject: Re: -32768 and strong typing

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

------------------------------

Date: Thu, 7 Nov 1996 21:38:31 -0500
From: "Robert I. Eachus" <[email protected]>
Subject: Re: Arbitrary precision arithmetic (Kilgallen, RISKS-18.58)

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...)

------------------------------

Date: Thu, 7 Nov 1996 10:29:16 -0700
From: Bear Giles <[email protected]>
Subject: Re: Tote Board Crash at Breeder's Cup (RISKS-18.56,57)

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 [email protected]

------------------------------

Date: 06 Nov 1996 14:58:05 -0500
From: Mark Eichin <[email protected]>
Subject: Re: Tote Board Crash at Breeder's Cup (Morphett, RISKS-18.57)

> 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.)

------------------------------

Date: Fri, 8 Nov 1996 14:02 -0500
From: [email protected]
Subject: Re: S-Bahn stopped by new switching software (Weber-Wulff, RISKS-18.55)

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, [email protected]. PGN]

------------------------------
Date: Fri, 8 Nov 96 14:38:55
From: [email protected]
Subject: Call for papers: SafeComp'97

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: [email protected]

------------------------------

Date: 15 Aug 1996 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 18.60
************************