RISKS-LIST: RISKS-FORUM Digest Tuesday 8 March 1988 Volume 6 : Issue 39 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Computer error and learned helplessness (Bruce Sesnovich) Garbage In, Gospel Out (Ephraim Vishniac) Re: Checking Statements & Disappearing Skills (Darin McGrew) Disappearing skills (Al Stangenberger) Lousy Lazy UNIX Linkers (David Collier-Brown, Henry Spencer, Andrew Klossner) Another Mac virus on the loose? (Chris Borton via Dave Platt) The last word (words, words and more words) on viruses (Robert Slade) BEWARE of PC-LOCK (James Ford) Moving time backwards (Paul Smee) Leap Year (Harold E. Russell) SDI related sources (Dan Jones) Electronic Privacy Act Info Request (Eliot Lear) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: Tue, 8 Mar 88 14:11:02 EST From: suneast!norbert!bruces@Sun.COM (Bruce Sesnovich - Sun ECD Information Architecture) Subject: computer error and learned helplessness In RISKS 6.38, Eric Herrmann relates his experience with a spurious electronic debit. Fortunately, the bank discovered its error and Eric eventually got his $60 back without having to raise a fuss. However, I believe that in general such erroneous debits ought to be contested. Unless I am mistaken, the burden of proof then falls on the banks to prove the cardholder has in fact withdrawn the money. The ATMs I'm familiar with here in Massachusetts are monitored by hidden cameras, and I imagine the same is true of ATMs in other states. The banks have recourse to the photographs taken by these cameras when a transaction is contested. Though I've not had the pleasure of contesting a debit to my account, I believe my bank requires a nominal (~$5) service charge to investigate a transaction. The fee is a hedge against slews of fraudulent appeals and is refunded if your claim is borne out. Eric's decision to "eat the $60 loss" seems to me an example of a pervasive computer RISK: the learned helplessness that afflicts many people when confronted with computer-related bureaucratic injustices. I do not intend this message as a put-down of Eric. I believe many people would have made the same choice he made. But who among us would have complacently accepted being short-changed $60 by a human teller or a store cashier? Eric's statement: "but...I couldn't prove anything," reflects a common attitude that, where computers are concerned, "you can't win, so why even bother trying?" Isn't this attitude the flip side of overreliance and unquestioning trust? In both cases there is the unwillingness to challenge the myth of the computer's monolithic infallibility. Debunking this myth, it seems to me, ought to be a goal of every concerned computer professional. Bruce A. Sesnovich, Sun Microsystems, East Coast Division, Billerica MA ------------------------------ Date: Tue, 08 Mar 88 09:16:24 EST From: ephraim@Think.COM Subject: Garbage In, Gospel Out In Risks volume 6, issue 38, Paul Smee (Smee@AUCC.AC.UK) writes: "I recently objected to a sales assistant trying to charge me an amount I knew was wrong. 'The till [US cash register] says it's 12 pounds', she insisted. 'Why don't you believe it?'" I was interested to find recently that ill-founded faith in the output of calculating machinery has been with us as long as possible. Consider the following (whose attribution should be obvious): On two occasions I have been asked [by members of Parliament!], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" I am not able rightly to apprehend the kind of con- fusion of ideas that could provoke such a question. Sad to say, the modern public is no more wary of GIGO than were 19th century MPs. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 ------------------------------ Date: Mon, 7 Mar 88 14:00:50 PST From: ibmuupa!mcgrew@ucbvax.Berkeley.EDU (Darin McGrew) Subject: Re: Checking Statements & Disappearing Skills Organization: IBM ACIS, PALO ALTO In RISKS 6.36 David Andrew Segal (dasegal@brokaw.LCS.MIT.EDU) relates an incident involving an ATM deposit that wasn't registered by the bank's computer. I am often amazed at the number of people who trust banks, stores, restaurants, etc, to never make mistakes. Apparently it is too much bother (or simply too difficult) to ever reconcile statements or verify receipts. Add to this the ability of computers to replicate human errors a thousand times a second, and we have a real RISK, for which there can be no technical solutions. This is a real [Sorry. The last word got lost! PGN] Darin I speak for myself, not for my employer. ------------------------------ Date: Tue, 8 Mar 88 09:11:23 PST From: forags@violet.Berkeley.EDU Subject: Disappearing skills Several years ago, I was using a calculator to add a series of numbers. The result "felt" wrong, so I did it by hand and found that the calculator had malfunctioned -- for every digit on the display, 8's looked like 6's because one of the LED segments failed to light up. If I had been doing something more complicated than addition, I probably would never have spotted the problem. Maybe calculators should have some sort of "self-test" program built in which would be automatically invoked when the unit is powered up? Al Stangenberger Dept. of Forestry & Resource Mgt. forags@violet.berkeley.edu 145 Mulford Hall - Univ. of Calif. uucp: ucbvax!ucbviolet!forags Berkeley, CA 94720 BITNET: FORAGS AT UCBVIOLE (415) 642-4424 ------------------------------ Date: 7 Mar 88 13:59:34 GMT From: geac!daveb@uunet.UU.NET (David Collier-Brown) Subject: Re: Lousy Lazy UNIX Linkers (Joe Dellinger) [RISKS-6.34] In RISKS-6.34 Joe Dellinger comments: [discussion about linking and having variables change mysteriously] > ... And if you don't happen to have the source code for one >of the libraries that gets linked in, such as the FORTRAN runtime library, >THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might >get overlayed in this way... Well, it's a known, long standing problem. In the natural environment of Unix V6 (cooperative software development, all sources available) it was a reasonable implementer's choice. In some other environments, not so. The ANSI committee is aware of it, and has made a well-known work-around (reserved leading underscore) part of their proposal. If the only-available-in-binary library is part of the C language run-time system, it is blatantly illegal. This doesn't help much if it is a bought-in product: the general solution to this requires a fair bit more work, equivalent to specifying an Ada[tm]-quality linker as part of the language definition. I claim that _that_ is easy. Others disagree. It remains a risk. David Collier-Brown, Geac Computers International Inc., 350 Steelcase Road,Markham, Ontario, CANADA, L3R 1B3 (416) 475-0525 x3279 {mnetor yunexus utgpu}!geac!daveb ------------------------------ Date: Mon, 7 Mar 88 13:50:53 EST From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: Lousy Lazy UNIX Linkers > ... if you don't happen to have the source code... > THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might > get overlayed in this way... Actually it's not QUITE that bad. You can find out, but the procedure is obscure and painful and nobody does it. (See the "nm" command, which can be convinced to give you a list of all the global names in a library.) The real problem here is not Unix-specific: name-space pollution. Smart library writers are careful to use systematic naming conventions that a user is unlikely to duplicate. The ANSI X3J11 C-standardization effort is in fact trying to require this for the standard libraries. Even less-permissive linkers can cause trouble when the internal name spaces of libraries overlap. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Tue, 8 Mar 88 12:46:45 PST From: Andrew Klossner To: joe%hanauma.stanford.edu@RELAY.CS.NET Subject: Lousy Lazy UNIX Linkers aren't at fault Organization: Tektronix, Wilsonville, Oregon The described problem is not the fault of the linker, but of the design of the Fortran language. If two programs each contain the line COMMON /PC/PC and they are compiled separately, then there is no mechanism by which the compiler can declare that one program defines PC and the other program uses PC. Subsequently, the loader must accept one or many COMMON declarations to mean that a single object should be established and all the declarations connected to it. The risk, then, is in writing software in a thirty-year-old language whose design preceded much of our understanding of software risks. The C language definition rode on this convention to some extent; the declaration "int pc;" outside a function is equivalent to "extern int pc;". To declare a variable in a way that ensures ownership, initialize the variable, e.g., "int pc=0;". (Of course, this will still silently match the Fortran COMMON statement above.) -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (andrew%tekecs.tek.com@relay.cs.net) [ARPA] ------------------------------ Date: Mon, 7 Mar 88 21:09:37 PST From: dplatt@coherent.com (Dave Platt) [Chris Borton] Subject: Another Mac virus on the loose? The following posting appeared in comp.sys.mac this evening. If you have any information about the virus reported in this posting, please speak up! From: borton@net1.ucsd.edu (Chris Borton) Subject: I've got a virus and I don't like it Date: 8 Mar 88 02:04:12 GMT Organization: UCSD Network Operations Group This is a warning and plea for more information, if anyone has any. We just discovered a virus in some of our systems (not all) at work today, and it has permeated my system at home as well. The symptoms are simple: INIT 32 in System File nVIR resources in various applications and the System File. This sucker is tricky -- it is getting itself loaded before any INITs do (we believe the INIT 32 is just a teaser), like PTCHs do, but it isn't in PTCH. Our two best programmers spent today tracing through it and still haven't found a real solution other than offloading and re-initializing. To our knowledge it is non-malicious (yet). The nVIR resources are usually small, sometimes 8 bytes, sometimes ~360. If you remove them from both System and ResEdit, the virus won't let you run ResEdit because it is looking for those resources and can't find them. It occasionally beeps when running a program. We have no idea what installed this. We are fairly certain it originated from one of the many small programs that come over the net. Many of these would be perfect 'carriers' -- little demo program that's an "aww, that cute, now let's trash it." I'm not putting down these programs, just pointing out what I feel is obvious. I don't believe this is any cause for panic -- it hasn't done any known harm yet. I would, however, like to get to the bottom of this! If it's a joke, I don't find it very funny. (unless it de-installs itself completely after April Fool's Day :-)). If it is someone's graduate thesis, you get an A-. But enough is enough! Chris "Johann" Borton, UC San Diego ...!sdcsvax!borton borton@ucsd.edu BORTON@UCSD.BITNET ------------------------------ Date: Tue, 8 Mar 88 07:42:24 PST From: Robert_Slade@mtsg.ubc.ca Subject: The last word (words, words and more words) on viruses For anyone interested, I have compiled all the virus messages I could find on virus, trojan horse and related topics from RISKS, Computers and Society, INFO-IBMPC and INFO-MAC. The uneditted file runs to 70 pages. (Anyone wanna publish a book?) For those in Canada, The Globe and Mail for Monday, March 7, 1988, page C15, under the title "Devilishly clever viruses may be lurking to devour your data" is telling everyone that you can recover from a Trojan attack through a warm boot. (And how many nanoseconds is your reaction time?) [And James Ford has the DIRTY DOZEN listing from Eric Newhouse on hacked/trojan/virus programs... Much too much for posting. But there are no LAST words on this one. PGN] ------------------------------ Date: Tue, 08 Mar 88 09:00:57 CST From: James Ford Subject: BEWARE (J. Greely) >A quick warning about PC-LOCK (shareware). If.........version 1.0..... I didn't know that one could consider PC-LOCK shareware.... :-) Just as a note......the version of PC-LOCK that we're using here is Version 3.0 on IBM PC/XTs. Also, the included text (reprinted without permission) states the latest enhancements available on Version 3.0.... (quote) Thank you for buying PC-Lock version 3.0. We believe you will find it to be an effective and convenient security system for your IBM-PC/XT/AT or compatible. Version 1.1 was reviewed in the June 23, 1987 issue of PC-Magazine and listed among "The Best of the Best Utilities." Version 3.0 provides enhanced security and several new features including: Simplified multi-system installation, An administrator password, Multiple user passwords, Support for large hard disks, Support for multiple hard disks, Works with the EGA controller/display, Ability to prevent user's from breaking out of AUTOEXEC, and others described below. (unquote) ------------------------------ Date: Tue, 8 Mar 88 10:47 GMT From: Paul Smee Subject: Moving time backwards The recent talk about setting time backwards reminds me of something that happened on the MIT Multics about 10 years ago. The Multics system clock counts time as number of microseconds since midnight, Jan 1, 1901 (well, maybe 1900, not sure). The microsecond clock value at the time when a file is created is used as unique identifier for the file; there is suitable gating to ensure that on a multi-processor machine, two processors don't get an identical clock value. In order to ensure that file unique IDs really are unique within a system, the Bootstrap system would not allow the ops to bring the Multics O/S up if the clock (set manually within BOS) was before the recorded time of the last shutdown. (Why HIS didn't put in a permanent battery backed up clock was always a source of wonder, but is another question.) One day, after a shutdown, the Ops mistakenly (finger trouble) input a date which was something like 2 days in advance of the real date -- e.g. 14 March rather than 12 March -- and started the Multics service. On realizing their error, they shut down Multics (back to BOS) to change the date to the correct one. The system would then not let them restart Multics. In that case (and after a couple of hours of poking thru microfiche) the system programmers decided it would be quicker just to leave the machine down for two days, than it would be to try to hack the system code to let them boot, and to ensure that there were no bad side-effects. (And, they thanked the gods that the Op had only missed by a couple of days, rather than getting the month, or worse, the year, wrong.) Ultimately, a 'fix' arrived, which consisted merely of having BOS query the Ops for confirmation if they tried to bring up Multics with a date-time more than a set interval after the previous shutdown. [I tried to GREP this one out of the RISKS archive, but did not find it. However, it is my vague recollection that this tale might have been related here somewhen in the distant past. Excuse me if you saw it before. PGN] ------------------------------ Date: Tue, 08 Mar 88 09:42:36 EST From: Harold E. Russell Subject: Leap Year Organization: The MITRE Corp., Washington, D.C. We seem to have had a flurry of problems with Feb 29. Please don't forget to watchout for Day 366 on Dec 31. ------------------------------ Date: Thu, 3 Mar 88 19:36 EDT From: DMJ%Vms.Cis.Pittsburgh.Edu@VB.CC.CMU.EDU Subject: SDI related sources Here is the list of sources relating computers and SDI that I compiled. Thanks to the people who sent me sources. Dan Jones Adam, John A. and Paul Wallich, "Part 1- Mind-boggling complexity" IEEE Spectrum, September, 1985. Bellin, David and Gary Chapman, Eds. "Computers in Battle". Harcourt Brace Jovanovich 1987. in particular: "Computers in the Strategic Defense Initiative" by Steve Berlin and Eric Roberts. "The Strategic Computing Program" by Jon Jacky, (which includes discussion of SCP's relationship to SDI). Benson, David B., "The Second Labor of Hercules: An essay on software engineering and the Strategic Defense Initiative". Washington State University Computer Science Department, 1986. Boffey, Philip: "Software seen as obstacle in developing 'Star Wars'.", The New York Times, Sept. 16, 1985. Buchsbaum, S.: "SDI software: the telephone analogy. Path I: the software will be reliable.", Physics & Society, 16:2, April, 1987, p. 6. Dahlke, K.: "SDI software, Part II: the software will not be reliable.", Physics & Society, 16:2, April, 1987, p. 8. Eastport Study Group: "A report to the director, Strategic Defense Initiative Office.", December, 1985. Eastport Study Group, "Summer Study 1985", Department of Defense (SDIO). Fletcher J.C. et al, "Report of the Study on Eliminating the Threat Posed by Strategic Nuclear Missiles, Vol 5: Battle Management, Communications and Data Processing" (Unclassified) Department of Defense. Govet Printing Office, 1984. Jacky, Jonathan: "The 'Star Wars' defense won't compute.", The Atlantic, June, 1985. Lin, Herbert, "Software and Star Wars: An Achilles Heel?" Technology Review. Lin, Herbert, _Arms and Artificial Intelligence: Applications of Advanced Computing_, "Software and Systems in Strategic Defense", book editor is Allan Din, publisher Oxford, January 1988. Lin, Herbert: "Software for ballistic missile defense.", MIT Center for International Studies, Report C/85-2, 1985. Lin, Herbert, "The development of software for ballistic-missile defense.", Scientific American, December, 1985, p. 46. Myers, Ware, "Can Software for the Strategic Defense Initiative ever be error free?" IEEE Computer, November 1986. Myers, W., "The Star Wars Software Debate" Bulletin of the Atomic Scientists, February 1986. Nelson, Greg, and David Redell, "The Star Wars Computer System" 25 June 1985. (Available from CPSR) Nelson, Greg and David Redell, "The Star Wars Computer System" Abacus, Winter 1986. Nelson, Greg and David Redell, "Could We Trust the SDI Software?" Chapter 5 of "Empty Promise" by the Union of Concerned Scientists, Beacon Press, 1986. ISBN 0-8070-0413-8. Office of Technology Assessment, "Strategic Defenses" Princeton University, Press 1986. ISBN 0-691-02252-6. Ornstein, Severo M. "Loose Coupling : Does it Make the SDI Software Trustworthy?" October 1986. (Available from CPSR) Parnas, David L., "Why Communication Systems are Not Like SDI" 8 December 1985. (Available from CPSR) Parnas, David L., "Software and SDI" 3 December 1985. (Available from CPSR) Parnas, David L., "Software Aspects of Strategic Defense" American Scientist, Sept/Oct 1985. (Also published in CACM, December 1985., and a Univ. of Victoria, Dept. of Computer Science Report DCS-47-IR, July 1985). Zracker, Charles A., "Strategic Defense: A Systems Perspective" Daedalus, Spring 1985. Zracket, Charles A., "Uncertainties in Building a Strategic Defense", Science, 27 March 1987. ------------------------------ Date: Tue, 8 Mar 88 20:33:29 EST From: lear@aramis.rutgers.edu (eliot lear) [...!{backbone}!rutgers!lear] Subject: Electronic Privacy Act Info Request I am researching the history and progress of the Electronic Privacy Act. If you have an educated opinion on the law and wish to express it, please contact me via E-Mail. Thanks in advance, Eliot Lear ------------------------------ End of RISKS-FORUM Digest ************************