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" 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: pcw@access.digex.net (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: harold.w.asmis@hydro.on.ca (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 harold.w.asmis@hydro.on.ca tel 416.592.7379 ------------------------------ Date: Thu, 7 Nov 96 17:18:26 -0000 From: "Trevor Warwick INF-SP" 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 twarwick@madge.com fax : +44 (0)1753 661011 ------------------------------ Date: Wed, 06 Nov 1996 14:00:37 EST From: Rob Slade 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 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 ------------------------------ Date: Fri, 08 Nov 96 15:28:00 EST From: "CRYPTO" 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 (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] ------------------------------ Date: Thu, 7 Nov 96 00:33:42 EDT From: Jerry Leichter 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" 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 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 bear@indra.com ------------------------------ Date: 06 Nov 1996 14:58:05 -0500 From: Mark Eichin 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: Bob_Frankston@frankston.com 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, mas@acm.org. PGN] ------------------------------ Date: Fri, 8 Nov 96 14:38:55 From: bob@minster.cs.york.ac.uk 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: safecomp-97@minster.york.ac.uk ------------------------------ Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com 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 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 risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]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 ************************