Text File

RISKS-LIST: RISKS-FORUM Digest Thursday 10 March 1988 Volume 6 : Issue 41

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

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = [WARNING: THIS IS ISSUE IS SOMEWHAT LOW ON CONTENT. I'M TOO TOLERANT TONIGHT. BUT TOMORROW I RESET THE RELEVANT...NONREPETITIOUS MEASURES. SHAPE UP. PGN] = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Contents: Harmless Virus? (Richard S. D'Ippolito) Have I Missed Something? (Hacking, Trojan horsing, etc.) (Chris McDonald) Leap Year Madness (John W. Taylor Jr.) [... and Daylight Savings] "NOPLATE" and "NONE" (Steve Philipson) [... and SEE RISKS-3.12!] ATM-OS-FEARic pollution (Jim Sims) Another ATM discrepancy story (Ken Yap) Re: computer error and learned helplessness (James H. Coombs) Why don't they learn? (American vs European Date formats) (Gary Friedman) Computers on Aircraft (Keith Bjorndahl) Re: Reliance on computers (Inland Steel furnace burnout) (Dan Franklin) Lousy Lazy UNIX Linkers (Michael I. Bushnell) Need References to "Environmental Bugs" (Gene Spafford)

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:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

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

Date: Wednesday, 9 March 1988 09:31:17 EST From: Richard.S.D'Ippolito@sei.cmu.edu Subject: Harmless Virus?

In RISKS 6.39, Chris Borton makes the following statements regarding a virus on his systems:

To our knowledge it is non-malicious (yet). I don't believe this is any cause for panic -- it hasn't done any known harm yet.

Then he finally admits:

If it's a joke, I don't find it very funny.

C'mon, everyone -- when your "two best programmers spent today tracing...and haven't found a real solution...", then it HAS done harm. Figure that the average technical employee requires a company to generate around $80K a year in sales, so you've spent the equvalent of $640 already. And what about others who will put the same time in helping Chris or themselves? It's time to come down hard on these @#&^#*s and stop treating them like cute pranksters. An "A-", indeed! Rich D'Ippolito

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

Date: Tue, 8 Mar 88 14:26:55 MST From: Chris McDonald STEWS-SD 678-2814 <cmcdonal@wsmr10.ARPA> Subject: Have I Missed Something? (Hacking, Trojan horsing, etc.) Cc: leonard@wsmr08.arpa

The forum recently had a posting of 14 "Dirty" files identified by Eric Newhouse which had appeared in the 22 Feb 88 edition of InformationWeek. When I attempted to verify the accuracy of the data, I found an original article attributed to Mr. Newhouse and contained in a local computer publication dated August 1986 which contained the same programs.

I discovered in reading the article, however, that the 14 programs were not all Trojan Horse programs, but that some were what Mr. Newhouse labels "hacked" of an otherwise legitimate freeware or user-supported program. Since I had seen no other discussion in the forum, and since apparently the list of programs must be at least 18 months old, I wonder if I am correct in assuming that indeed the list published in InformationWeek and the forum includes both "hacked" and "trojan horse" files? I note also that in the local publication Mr. Newhouse identified two other file names for the Trojan Horse identified as "DISKSCAN.EXE": SCANBAD.EXE and RADDISK.EXE. His description of the program is that this was "a PC-Magazine program to scan a hard disk for bad sectors, but then a joker edited it to WRITE bad sectors."

While the passage of time may have allowed someone to take a "hacked" program and make it a "trojan horse" as well, I would just like to verify the most current information.

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

Date: Thu, 10 Mar 88 11:47 EST From: "John W. Taylor Jr." <JWTaylor@DOCKMASTER.ARPA> Subject: Leap Year Madness

How long can we drag this one out, claiming that this only happens once every four years, when in fact we must deal with a similar situation twice a year.

I am reminded of the time I gave my fiancee' (now wife) a call from college late one Saturday night in October. As was customary for us, being 300 miles apart, we spoke for over an hour (61 minutes to be exact). The phone company computer, in its infinite wisdom, backed up precisely one hour during our phone conversation to account for the change between Standard and Daylight Savings time. Rather than counting the number of minutes we talked, the computer stamped a start and stop time for my call, thus the conversation went from 12:00m to 12:01p.

Some points to ponder: If we can't get an hour right, how can we expect to deal with days/years? How much money does the phone company lose when this happens? (Or does it gain when we "spring forward"?) What would have happened if my wife and I had spoken for 59 minutes and the computer would have had to deal with a call from 12:00m to 11:59p the previous day? --John

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

Date: Thu, 10 Mar 88 10:04:37 PST From: Steve Philipson <steve@ames-aurora.arpa> Subject: "NOPLATE" and "NONE" (Re: RISKS-6.40)

The old "warhorse" about the license plate "NOPLATE" probably repeats itself in the real world on a regular basis. I read about such a story within the last year or two. If memory serves correctly, this one occurred in New York. The plate was "NONE"; the newspaper article contained a photo of the car and the plate.

The real issue here is of a system design failure. The designers did not include a way to indicate that there was missing information (plate absent), so the users used some descriptive text that turned out to be a valid entry. (Of course, a missing data code might have been designed in but not given to / forgotten by the officers in the field).

This is a frequent problem in database and interactive systems -- either the designer has an incomplete understanding of the real world environment in which the software will run, or the end users develop a new requirement and use for the software. Users tend to kluge their inputs to get the desired results rather than request a change in the system. This may come from a perception that the system can handle the change without going through a formal modification. People can adapt to things that seem intuitive, so it shouldn't be any big deal for the machine, either. Perhaps the user's perspective is not that the machine can adapt, but that the meaning is so intuitively obvious that no adaptation is necessary.

Those of us who write interactive software have learned (sometimes through painful experience) that no input can be taken for granted. Ingenious users can always come up with things that will screw up a program, or use it in ways that corrupt the system. We have learned how to guard against many types of invalid input, but the quest for the "idiot proof system" goes on. The problem may grow worse with time. As our systems gain more "expert" capability, they will have the appearance of having real-world knowledge and some common sense. When users depend on that human quality in their systems failures abound. Increasing capability will bring yet more RISKS in computer systems.

[Guess what? I found the "NONE" case in RISKS-3.12, 24 June 1986, contributed by Chuck Price, and augmented by yours truly. It was supposedly CALIFORNIA, which now instructs officers to always write "NONE" in the case of unknown plate. I suppose "N.A." (not available) or "UNKNOWN" might also cause trouble. Having 7 characters adds more fun, but there are plenty of plates in any case that would be reminiscent of Abbott and Costello: Officer: "Please give me your license plate number." Driver: "NEVER" or "WHY" or "WHY NOT" or "DON'T ASK". But, if you really want to confuse the computer matching programs, you might opt for something like 1OI0O01, which on California plates would be quite hard to read accurately as it flies by. PGN]

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

Date: Thu, 10 Mar 88 12:33:19 EST From: Jim Sims <sims@stsci.arpa> Subject: ATM-OS-FEARic pollution (Re: RISKS-6.39)

I also have an ATM related horror - that the bank didn't catch.

I recently moved to a new city and didn't get around to balancing my chackbook for a couple of months. When I did I noticed something rather odd. There were two ATM withdrawals for $50 spaced one minute apart at an ATM machine about 5 miles from my house, on the evening of the day our furniture arrived. Now, any other day/combination I wouldn't have caught, but I knew I didn't go to an ATM that day (certainly NOT one 6 miles away when there are several closer), we had both cards at home, we ate at home that night, and I have NEVER withdrawn $50 twice when I wanted $100, I withdraw $100 (too lazy? too smart? to push those buttons twice).

I notified the bank, and spent several months hassling the bank about it, and after explaining that I deal with computers for a living, they finally decided:

"We did not make an error, but out of courtesy to you, since you are so convinced, we are restoring the $100 to your account."

I thanked them and advised them to notify "whoever handles computer security" in their institution.

[The "SUBJECT:" line refers to the negative effects of developing a phobia against ATM systems, in case you hadn't guessed. PGN]

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

Date: Thu, 10 Mar 88 15:01:46 -0500 From: Ken Yap <ken@cs.rochester.edu> Subject: another ATM discrepancy story Organization: CS Dept., U of Roch., NY 14627.

Years ago I used the ATM service of a bank in my home country. One day I requested a withdrawal. The machine went through the motions of verifying me, but just before I got the money, the machine shut down. Cursing my luck I went into the bank and got the money via a teller.

A few days later I received a phone call from the bank. Did I try to withdraw on a certain day? We have a discrepancy between the amount of money in the ATM and the log. In the end I got my money back.

Since I only got a statement once a month, I don't know what would have happened if the discrepancy had showed up in my statement a month later. Risk: The teller makes you sign a receipt before giving you the money. If the ATM screws up without a trace, how does one even begin to dispute with the system? Ken

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

Date: Wed, 09 Mar 88 16:49:28 EST From: "James H. Coombs" <JAZBO%BROWNVM.BITNET@MITVMA.MIT.EDU> Subject: Re: computer error and learned helplessness

Bruce Sesnovich writes:

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

I have always wondered about those cameras. What happens if you step back out of view? wear a mask? Wear a hat pulled down over your face? I doubt very much that those cameras have sophisticated pattern recognition (let's hold the transaction until we get a good shot of a real human face). So what will banks do if the picture for a transaction doesn't enable us to identify who the agent was or wasn't? --Jim

Dr. James H. Coombs, Software Engineer, Research jazbo@brownvm.bitnet Institute for Research in Information and Scholarship (IRIS), Brown University

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

Date: Wed, 9 Mar 88 17:18:44 PST From: garyf@devvax.Jpl.Nasa.Gov (Gary Friedman) Subject: Why don't they learn? (American vs European Date formats)

This is hardly a technology-related RISK, but it certainly falls within the categories of low-level, people-not-thinking errors that have flooded recent digests.

A friend of mine, who is backpacking (is there a RISK in verbing nouns?) throughout Europe, possesses an extra AMEXCO card on my account displaying his name. (This is to assure instant cash in case of emergencies.)

One day I got a call from someone claiming to be from American Express, stating that one of my checks that was cashed in one of the American offices had bounced, and that if I didn't cover the ~$400 debt in three days my account would be attacked by corporate white blood cells. To my recollection, I had written no such checks, although I did cash a check with them while in London three months earlier for a similar amount.

Although quite courteous, she refused to reveal crucial information such as my account number or exactly where and when the check was cashed. ("We're not allowed to give that information over the phone.") Lacking proof, I treated the call as if it was a prank and informed her that I would take no action unless I saw physical evidence, like perhaps the bounced check.

Two days later the check came in the mail. It was written and cashed by my friend overseas. Three days worth of investigations revealed the following:

- The "American Office" that AMEXCO had mentioned was located in London.

- My friend's account had plenty of funds to cover the check.

- The bank rejected the check as being 'stale' (more than 6 months old.) The check was written only two weeks earlier.

The problem was traced back to the discrepancy between the European and North American date formats. Since the check was written on December 4, 1987, the teller in London wrote

4.12.87

which the bank in the US quickly deciphered as April 12, 1987 and pronounced the check stale!

Issues:

1) Why does AMEXCO call their outlets in London "American Offices"? Does it communicate to anyone the office's location?

2) I can't believe this hasn't happened before. A company policy of spelling out the months, even in abbreviated form, will prevent this type of error (which AMEXCO *must* be prone to) from happening again.

3) Their security measures are so good that they render their phone queries unauthenticatable. (Pretend it's a real word.) There are simple systems available to let customers know that AMEXCO's calls are legitimate without compromising confidentiality.

I'm hardly disgusted, as I related to AMEXCO simple procedural changes to prevent future occurrences and they seemed to regard the suggestions as being valuable.

Gary Friedman, Jet Propulsion Laboratory - NASA, 4800 Oak Grove Drive, Pasadena, CA 91109. (818) 354-0410 Uucp: {cit-vax,elroy,psivax}!jplpro!garyf Arpa: jplpro!garyf@cit-vax.ARPA -or- garyf@jplpro.JPL.NASA.GOV

[The problem of wrong or incompatible data formats has been the source of a variety of incidents reported here... But this one is a little like trying to get the others to drive on the right (or left, depending upon which is right) side of the road. PGN]

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

Date: Thu, 10 Mar 88 16:58:25 CST From: Keith Bjorndahl <BJORNDKG%UREGINA1.BITNET@CUNYVM.CUNY.EDU> Subject: Computers on Aircraft

>In most cases, the (computer) user is not told to believe absolutely the >evidence of a machine over the evidence of his senses. But in the case of >aircraft he is explicitly trained to do so. This behooves us (as >programmers, etc.) to make sure that the machine is telling the truth! > Hugh

I don't believe that pilots are expected to believe computers over indications given by other sources. It was not long ago that there was a near miss on an overseas flight in the Gander control area which was caused in part by the entry of wrong data into the flight computer. The flight went 60 miles off course because the computer was being used as the sole source of navigation information. Other more conventional methods of navigation were not used to cross check the information given by the flight computer. We must remember the garbage-in/garbage-out rule, but we must be aware that we can always anticipate that from time to time there will be some garbage in. Every system must be designed to reduce the chance of this garbage producing catastrophic results. Now, most airlines require that more than one method of navigation be used to cross check the values produced by the flight computer. Now and then, we just have to use our eyes and our minds and ALL of the instruments together to narrow the RISK of one failure leading to another. Keith

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

Date: Thu, 10 Mar 88 11:23:45 -0500 From: dan@WILMA.BBN.COM Subject: Re: Reliance on computers (Inland Steel furnace burnout)

Wow, a huge, expensive steel furnace that doesn't have a control system as smart as the one on most home furnaces! If my oil furnace turns the pump and the igniter on, but doesn't get a rise in temperature after a minute or so, it shuts off automatically. And it doesn't even have a PDP-11 in it.

No doubt Inland Steel originally relied on workers to do the job, and neglected to think about the problems inherent in replacing people with computers. Fortunately home furnaces are designed by people who know that they will be operated unattended (and used by people who know nothing about them), and so have lots of safety devices. Dan Franklin

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

Date: Wed, 9 Mar 88 11:33:46 MST From: gatech!turing!mike@rutgers.edu (Michael I. Bushnell) Subject: Lousy Lazy UNIX Linkers

Actually, there is a way. If you think about it, you will realize that a program of your design can find out all the symbols in the library, after all, ld finds out. And, there is such a tool: nm. Just say "nm libfoo.a" and it will print all the symbols used or defined in the library.

Michael I. Bushnell, mike@turing.unm.edu, {ucbvax,gatech}!unmvax!turing!mike

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

From: spaf@purdue.edu (Gene Spafford) Subject: Need References to "Environmental Bugs" Date: 10 Mar 88 17:32:07 GMT Organization: Department of Computer Science, Purdue University

I need to develop a body of references to published descriptions of bugs resulting from changes in environment. That is, programs which worked fine on one machine, but failed to work when ported to another machine or had the current system upgraded, either due to a change in data type precision, change in memory size, timing differences, etc. Also appropriate are references to programs that failed to work simply because the machine involved didn't have the precision or range or memory that the programmer assumed, even though the code itself was "correct."

I'm *not* interested in hearing anecdotal references; I want examples (compilations and theoretical studies would be best) that have appeared in the literature in the past 10 years. Note that I'm not asking about portability problems, per se, but about failures of the actual machine to match the programmer's virtual machine -- "environmental errors."

If there is sufficent interest and PGN allows, I'll summarize for RISKS what I get back.

Thanks in advance!

Gene Spafford, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 spaf@cs.purdue.edu uucp ...!{decwrl,gatech,ucbvax}!purdue!spaf

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

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