Text File

RISKS-LIST: RISKS-FORUM Digest Thursday 17 March 1988 Volume 6 : Issue 45

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

Contents: Tax penalty (Bob Larson) Arete': Risks in Names -- RX for Confusion (PGN) Trusting aircraft instruments (Spencer Garrett, Steve Philipson) Hidden bugs from language extensions (William Smith) Date formats (Cormac O'Reilly) MacMag virus a SubGenius plot? (Prentiss Riddle) Re: Dangers of Wyse Terminals (Douglas Jones, Jim Frost) Virus file requests (Robert Slade) "NOPLATE" and "NONE" (Eric Norman, lee) High-Tech Trucking (Michael Wagner) Architecting Telephone Systems (Graham Wilkinson) Risks of using computers for Architectural Engineering (Steven Koinm)

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: Mon, 14 Mar 88 18:39:57 PST From: blarson%skat.usc.edu@oberon.usc.edu (Bob Larson) Subject: Tax penalty Organization: USC AIS, Los Angeles

[Appogies on the quality of this, I'm doing it from memory. Transcripts are available.]

From "The Nightly Business Report" (a PBS program) 3/14/88:

A penalty of over $400 was assessed on a tax underpayment of $0.02. One IRS spokesman blamed the computerization of the process of computing penalties, then another blamed the add-hoc way the penalties were designed.

Bob Larson Blarson@Ecla.Usc.Edu {sdcrdcf,cit-vax}!oberon!skat!blarson Prime: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request

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

Date: Wed 16 Mar 88 09:28:27-PST From: Peter G. Neumann <NEUMANN@csl.sri.com> Subject: Arete': Risks in Names -- RX for Confusion

On 21 March Arete' Systems Corp will be renamed to ARIX, which is closer to UNIX, and which is also the name of their UNIX-based operating system. Arete' had been named after the Greek word for excellence. But "arete" also means "earring" in Spanish, and "arrete'" means "stopped" in French ("not a very good name for a computer company", says Caroline Carnefix, marketng communications manager). The difficulties in pronounciation and other meanings apparently confused people. Says Mike Lambert, marketing vice president, "We decided to change our name for the benefit of financial analysts and potential investors." [So they could pronounce it!]

(This was noted by Vlae Kershner and Kathleen Pender in the "Business Insider" column of today's S.F. Chronicle. I presume they did not know of the computer science and mathematical usage of "-arity" to indicate whether the radix is binary, ternary, or whatever. [One good ternary deserves an adder.] PGN)

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

Date: Tue, 15 Mar 88 00:01:24 PST From: srg@quick.com (Spencer Garrett) Subject: Trusting aircraft instruments

There are two issues at work here. Pilots are indeed taught to cross-check instruments and to look out the windows whenever conditions would permit seeing something. (Except pilots of big jets, but that's another issue.) What they MUST NOT do, however, is trust their own sense of balance when they cannot see the horizon. Our bodies are not adapted to accelerated motions in three-dimensional space, and one's perception of up and down when flying in instrument conditions (eg - in the clouds) will NOT be correct. It takes a great deal of training to learn to ignore the feeling that you're rolling to the left when the instruments say otherwise, but that's what you have to do.

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

Date: Mon, 14 Mar 88 11:13:54 PST From: Steve Philipson <steve@ames-aurora.arpa> Subject: Trusting aircraft instruments (Re: RISKS-6.42)

In RISKS DIGEST 6.42, Robert Dorsett writes:

> On the 747-400, Airbus A320 (and the forthcoming A340), MD-11 (the DC-10 > derivative) and, to a lesser degree, the Boeing 757 and 767, the pretense of > electromechanical instruments has been done away with altogether, and > replaced with CRT displays, under the assumption that the CRT displays are > less prone to failures...

Many new display formats are being evaluated and tested. Trend information is being displayed in some formats by dedicated trend indicators.

First generation EFIS (CRT) displays were simply electronic representations of mechanical instruments. While these displays were sometimes criticized for being unimaginative and archaic, they preserved a large body of experience on display design. Our old instrument formats were derived through a long series of trials and sometimes painful errors.

> ... The Boeing philosophy thus far has been to > simplify overall design and efficiency by introducing automation; the Airbus > philosophy has been to redefine the role of the pilot in the cockpit while > simultaneously changing the way information is displayed. ...

What we are trying to do now is redesign the entire information link between aircraft systems and the pilot, while also changing the nature of the pilot's task. We don't have much experience in designing visual languages, particularly for critical, high technology applications. We also are not mature in design of human-monitored complex systems. We are likely to re-learn some lessons and undoubtedly learn some new ones. With new systems come new failure modes -- the answers to our old problems bring new problems. This is what RISKS is all about.

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

Date: Tue, 15 Mar 88 00:07:24 CST From: wsmith@b.cs.uiuc.edu (William Smith) Subject: Hidden bugs from language extensions

I just stumbled on a bug that was difficult for me to locate because it was unfamiliar to me and had no obvious symptoms except that the output was (inexplicably) wrong.

In C I had a printf statement that printed a string and a number. The string was found by indexing an array. I could not understand why the number was always wrong. I debugged the rest of the code and still could not find where the variable was being set wrong. It wasn't. The array was not an array of strings, but instead an array of structures with the first element of each structure being a string. I passed the structure so its second field was used as the number. C now allows structures to be passed as arguments. Printf has no type checking on its arguments with lint, so I received no diagnostics suggesting that I was using printf incorrectly.

The factors that contributed to the difficulty of finding this bug were that there were no diagnostics from the error-checking that C provides and also that this was an unfamiliar bug category. I kept looking over the problem because I assumed that a simple printf statement could not be the problem. By adding the useful feature of passing structures as parameters to C, a new class of bugs has been created. In this case, the class is small enough to slip through the type checking system. As other languages are changed or created, the designers may miss subtly erroneous programs that are an interaction of several (seemingly) unrelated features in the language. Are there any other examples of this idea?

Bill Smith [{pur-ee|ihnp4}!uiucdcs!wsmith] [wsmith@a.cs.uiuc.edu]

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

Date: Tue, 15 Mar 88 16:16 EDT From: Cormac O'Reilly - 713-240-3670 <OREILLY%aslvx6.sdr.slb.com@RELAY.CS.NET> Subject: Date formats (RE: RISKS-6.43)

A suggestion on date formats. When I was at school in England we were always told to write dates with the month as a Roman numeral. Today, there are a few people left who do this in England. It is a good way of avoiding the international confusion. Mind you, I get some funny looks at my US bank when I cash checks -- Cormac O'Reilly 15/III/1988

[Beware the I-des of March. That is nice unless you don't CROSS YOUR EYES carefully, in which case 11 III 88 would also cause grief. When in Rome, do as the Romans do. Europeans still use that scheme. PGN]

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

From: ut-sally!im4u!woton!riddle@uunet.uu.net (Prentiss Riddle) Subject: MacMag virus a SubGenius plot? Date: 12 Mar 88 23:58:47 GMT Organization: Shriners Burns Institute, Galveston

The following appeared in a Houston paper on February 14th this year. I'm surprised no one has reported seeing anything like it. I've edited out the information in the article already familiar to RISKS readers.

'ARTISTIC VIRUS' INSINUATES ITSELF INTO MAC WORLD by John Markoff (Hearst News Service)

A computer program designed by adherents to a loose-knit philosophy called the Church of the SubGenius is creating an uproar on the nation's largest computer-information system, whose managers fear the program may cause widespread destruction. [...]

The programmers, who publish a magazine called MacMag in Montreal, said they had launched the "virus" in December. [...]

The Church of the SubGenius is an ill-defined group of sometime pranksters that began in Texas as, in the words of one writer, a "monotheistic new UFO cult in the 1950s" and has become a "polytheistic grab-bag in the 1980s."

In other words, said David Spector, a New York University programmer whose computer was infected by the virus, "they're a bunch of high-tech looney-tunes." [...]

Kevin Kelley, an editor of the Whole Earth Review, a Sausalito, Calif., magazine, said the Church of the SubGenius had begun as a spoof on fundamentalist religions but later had taken on aspects of a religious cult in its own right. Its founder, a shadowy Texan named J.R. "Bob" Dobbs, died in 1985.

Nowhere does the article explain the supposed connection between MacMag and the Church of the SubGenius. Are Peter Lount and Richard Brandow (named in the article as the resposible persons at MacMag) really SubGenii? If so, why have no other accounts mentioned that? The whole article reeks to me of a clever press release by a SubG somewhere -- as far as I know, the Church began in the late 70s or early 80s, not in the 50s, and "Bob" Dobbs is entirely imaginary. If the author of the article fell for the Church's myths about its origins, I wonder what else he fell for.

The RISKS? First, that not everything you hear about viruses should be believed. Second, if the SubGenii *have* decided to get into the virus business, then hang onto your hats -- there are some wild and crazy chaos-mongers running around out there.

-- Prentiss Riddle -- Opinions expressed are not necessarily those of my employer. -- riddle%woton.uucp@cs.utexas.edu {ihnp4,uunet}!ut-sally!im4u!woton!riddle

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

Date: Mon, 14 Mar 88 09:55:11 CST From: Douglas Jones <jones%cs.uiowa.edu@RELAY.CS.NET> Subject: Re: Dangers of Wyse Terminals

A. Cunningham asked: Why do terminals have remote modes to lock the keyboard?

In these days of full-duplex communication, it is easy to forget that once upon a time, all of the available fast modems were half-duplex, and were required to use a line-turnaround protocol to change from one direction of data travel to another. Many terminals were built with provisions to lock and unlock the keyboard to simplify line-turnaround (from the user's view). The first character in any transmission from the mainframe would be "lock keyboard", and the last character after typing a prompt would be "unlock keyboard".

Protecting yourself from "letter bombs" which lock your keyboard or do other nasty things is not hard. Just make your mail reader filter all output through a filter that removes all control characters from the mail (I'm pretty sure that the UNIX more filter can be made to do this. Of course, this doesn't protect you from other sources of nasty output to the terminal. A specific threat in a teaching institution is student assignments that, when run by the instructor, send nasty control sequences to the terminal.

It is sad that the solution to all of these problems is quite old but hardly ever used: Put the filter in the device driver, not in the application program. On the SIMPLER system built by the Medical Computing Lab at the University of Illinois at Urbana, between 1973 and 1980, we did this, putting much of the functionality usually associated with the UNIX curses package in the device driver, so that all applications programs dealt with a single virtual terminal protocol, and all device specific control sequence translation was done by the system. It worked beautifully, and the cost was quite acceptable in a timesharing environment. (This solution is outlined in some detail in my 1976 MS Thesis, "Run-Time Support for the Tutor Language on a Small Computer System" (University of Illinois Computer Science Technical Report UIUCDCS-R-77-868, May 1977) Section 6.5 and Appendix E.) Douglas W. Jones

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

Date: 16 Mar 88 03:49:09 GMT From: madd@bu-cs.BU.EDU (Jim Frost) Subject: Dangers of Intelligent Terminals (A. Cunningham, RISKS Volume 6.42) Organization: Boston University Distributed Systems Group

The described effects are extremely easy to do on a variety of common terminals (eg VT220 terminals). There are codes that the terminal recognizes to set particular modes in the terminal (such as "local only" instead of "transmit") and many terminals also have a form of "answer back" which allows a sequence to be automatically dumped by the terminal. I suspect the latter was used to accomplish the file permission changes and process killings.

> 1). Why are the features in the terminal in the first place? I can > only assume that Wyse put them in as security features. A hacker > accesses your system you lock out the terminal.

They are there as features to programmers. I can see where it might be nice to be able to lock up the terminal so that a user cannot do anything while my program does something delicate.

> 2). Has anyone had similar experiences? I've only been reading this > group for a year while we've know of the possiblities of the Wyse > for at least two. At first it was limited to changing a friend's > screen to inverse mode. We never envisaged it being used so > destructively.

Sure. It happens here all the time. Usually it starts out with students finding out that it's possible to send control sequences to others' terminals and then doing research to find out just how nasty they can be. Enclosing them in mail and dumping them directly are two common methods of doing this. Turning off write permission to your terminal will stop direct writing in a UNIX environment, and it's quite simple to write a utility that looks for escape sequences in mail files before actually displaying the file.

About the only way to prevent this sort of thing is to disallow communications between users or to screen communication for obvious control sequences. Screening comes with risk, but the risk is very low. Alternatively, make it known to the users that such activities are frowned upon and severely punished; this proved extremely effective in our case. jim frost

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

Date: Wed, 16 Mar 88 08:13:06 PST From: Robert_Slade@mtsg.ubc.ca Return-Path: <@um.cc.umich.edu:Robert_Slade@mtsg.ubc.ca> Subject: Virus file requests

My panic (compounded by a messaging system that is in the throes of who-knows- what just now) having subsided somewhat, the only workable solution to the flood of requests in the immediate future is going to be the mails. For those who need the stuff *now*, (and much of it is only what has appeared here already) send a PC formatted 5 1/4 floppy with a self addressed stamped *mailer* to:

Rob Slade 3118 Baird Road North Vancouver, B. C. CANADA V7K 2G6

Americans need not worry about Canadian postage, I can send the stuff to be mailed in Bellingham. For those with other than standard MS-DOS machines, I have Media Master (an early version) and so can read other formats such as Kaypro. Sorry, I can't give a full list. If your disk is not readable by the program, I'll reformat as MS-DOS and you can try at your end.

Remember, the file is in excess of 200K.

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

Date: Sun, 13 Mar 88 22:29:23 CST From: Eric Norman <ejnorman%dogie@unix2.macc.wisc.edu> Subject: "NOPLATE" and "NONE"

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

Hah! it's actually happened. Quite a while ago I had a personal license plate of "0 HERO" (that's zero-hero; it means something to road ralliers). I had to fight off the University parking folks charge that I had failed to register my plate with them.

Eric Norman <ejnorman@unix2.macc.wisc.edu>

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

Date: Mon, 14 Mar 88 17:11:41 pst From: uw-beaver!ssc-vax!ssc-bee!lee@ames.arc.nasa.gov Subject: NOPLATE vs NO PLATES (Re: RISKS-6.41)

Regarding the NOPLATE references, I keep this article pinned up on my bulletin board. Helps remind me of what Mr. Spencer calls "name space pollution".

Seattle Post-Intelligencer, 14 October 1987, pg. C1, abstracted without permission (obviously a re-print from other sources)

... When a policeman pulled Robert Barbour over while he was driving his 1970 Datsun a few months ago, a computer check of his license plate got the officer excited.

[So, we have Mr. X's name and vehicle now. Details on how it came to be, similar to Niels Jensen's note. Additional juicy anecdotes... ]

"At first, I called them up and told them to look on the car in the citation. Then I started writing some individual letters as the totals ran into the dozens. But by the time I started getting hundreds a month, I had a form letter."

... his postage bills surpassed $300 ...

He liked it because the plate provoked some dialogue with officers that rivalled Abbott and Costello's "Who's On First?" routine.

At first, Barbour was embarrassed to put the plates on his Datsun and was cited for -- you guessed it.

He finally bolted them on and went to a Los Angeles court to get that ticket excused. An inspector duly noted that he had his plates on, and Barbour took the notation to a clerk. The clerk took one look at the paper, which noted that "NOPLATE" indeed was bolted to the car.

Clerk: You need to take care of that first before I can sign you off.

Barbour: The officer has inspected it, and the plates are on the car.

Clerk: According to this, there are no plates on the car.

Barbour: There are plates and they say 'NOPLATE'.

Clerk: But if your vehicle has no plate, you need to put them on before I can sign off this ticket.

Barbour: I have put on the plates!

Clerk: Not accourding to this. It says 'No plates'.

Barbour: It says 'NOPLATE'! Not 'no plates'! Because that's what the plates say.

[ Other strange stories, ending with ... ]

While the mistaken-identity parking tickets have slowed to a trickle, Barbour still dreams of new challenges.

Can he get a vanity plate that reads "NONE".

--- end ---

Strikingly, this article reveals "blind reliance of technology by skilled workers", "name space pollution", and "challenging the myth of ... computer infallibility", all hot RISKS topics.

[Perhaps they'll cool off. This is getting silly. PGN]

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

Date: Tue, 15 Mar 88 15:01 CET From: Michael Wagner +49 228 303 245 <WAGNER%DBNGMD21.BITNET@CUNYVM.CUNY.EDU> Subject: High-Tech Trucking (Rick Sidwell, RISKS 6.42) Cc: Rick Sidwell <sidwell@commerce.UCI.EDU>

> " The 'black box' ... automatically records drive time, speed, > distance traveled as well as other important functions that > reveal how a driver handles his rig.

There may be problems with this scheme, but I'm not sure that invasion of privacy is one of them. The idea that a recorder in the vehicle should report on vehicle handling, and that the driver can potentially be reprimanded or punished for transgressions so recorded, is well established in airplanes and somewhat also for trains. Notice that, for the specific case of speeding, the entry/exit time stamps on a toll ticket could also be evidence of speeding. Likewise, properly synchronized clocks and 2 unambiguous pictures, or in fact radar. The difference is only whether the observing device is inside or outside the vehicle. I don't see a privacy issue in that difference (there is a tampering issue, however!).

There is, of course, a civil liberties problem with stopping a vehicle for no good reason and then hunting for transgressions to '(post)-justify' stopping the vehicle. Is that perhaps what was meant? The 'black box' then is not the threat, any more than the toll ticket was. It is improper exercise of power.

Michael

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

From: Graham Wilkinson <mcvax!gec-mi-at.co.uk!gpw@uunet.UU.NET> Date: Wed, 16 Mar 88 07:59:31 GMT Subject: Architecting Telephone Systems Organization: Computing Lab, University of Kent at Canterbury, UK.

In the Times (London, 15 March 1988) today there was an article about an architect in south London who for the past month has been troubled with strange noises in his telephone at all times of day (and night).

It started one Sunday morning when his phone clicked, then started making pinging noises. Since that time this has continued at the rate of several calls a day. After initial puzzlement he realised that it was a computer which had called up his number by mistake.

He went to British Telecom, who offered to intercept his calls for a fortnight, but after this time the calls continued. They said they were not able to trace the source of the call, as this could only be done by special request of the police, i.e., they could but they wouldn't.

The only solution offered was to give him a new number, at a cost of 21 pounds. He queried this, complaining that it wasn't his fault, but their reply was 'It isn't our fault either'! When pointed out that they were the ones offering the service, silence reigned. Obviously he wants to keep his old number, as all his friends know it - so why can't BT trace this call - and why doesn't the computer realise that nothing is coming back up the line it is transmitting down? (Apart from a couple of times the poor fellow whistled back to it - causing it to drop an octave).

The Times concluded by saying that this wasn't an unknown occurance, and that, given the unhelpfulness of BT, it would be pretty bad luck if this were to happen to you!

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

Date: Tue, 15 Mar 88 15:03:11 CST From: Steven Koinm <goog%a.cs.okstate.edu@RELAY.CS.NET> To: RISKS@csl.sri.com Subject: Risks of using computers for Architectural Engineering

I am presently working on a paper on the risks of using computers for Architectural Engineering. If anyone can suggest some good articles or books or just drop me a note with their opinion or suggestions on this topic, I would be extremely grateful.

And in addition, could you send me an opinionated reply to this statement: "Because computers are inherently error-prone, we should not use them for Architectural Engineering."

Thanks for your time.

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

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