The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 13 Issue 26

Friday 6 March 1992

Contents

o Name this risk... [Primative logic]
Michael Travers via Rex Black
o Mouse restrictions on American Airlines
Bob Frankston
o Exporting Apples
Burt Kaliski
RSA Laboratories
o Bargain Harold finds computers no bargain
Dave Wortman
o Re: Sizewell (and RISKS) on UK TV
Pat Place
o Risks of Automated Phone Operators
Charles Olson
o Speed-droid tickets junked car
Jane Beckman
o Risks of Barcoded money
Mark Gonzales
o Safeway "Frequent Shoppers Club"
Jeremy Epstein
o Re: Musical Risks
Katz
rwk
o Re: Bureau of Centralization -- Phone Taps
Peter Wayner
Steve Dever
o New Legislation on Computer Security
Lance J. Hoffman
o Re: Michelangelo
anonymous
Graham Mainwaring
o Technical terminology -- and viruses
Brian Rice
o Re: A RISK architecture? (DEC's Alpha)
Steve Bellovin
Tom Blinn
o Imprecision not considered harmful
Eric Sosman
o Info on RISKS (comp.risks)

Name this risk... [Primative logic]

Rex Black <rex@devnet.la.locus.com>
Thu, 5 Mar 92 10:37:55 -0800
>From: Michael Travers <mt@media.mit.edu>

Toronto, Canada:

Archbisop George Cram enjoys a banana once in a while, but he's not the kind of
primate that ape researchers had in mind.  The University of Wisconsin's
Regional Primate Research Center sent Cram, primate (senior archbishop) of the
Anglican Church of Canada, a questionnaire while preparing an international
directory of primatology.  The envelope was addressed to "George Cram, Primates
World Relief and Development Fund."

The Reverend Michael Ingham, secretary for the senior archbishop, suggested in
a letter of reply that "primates in your study are perhaps of a different
species.  While it is true that our primate occasionally enjoys bananas, I have
never seen him walk with his knuckles on the ground or scratch himself publicly
under the armpits," Ingham said.  "There are a mere 28 Anglican primates in the
whole world," he said.  "They are all males, of course, but so far we have had
no problems of reproduction."

The research center's director, John Hearn, promised to strike the church from
a computer database and added in a letter to Ingham; "In our zeal to develop a
comprehensive directory, we have strayed on this occasion from the arboreal to
the spiritual."


Mouse restrictions on American Airlines

<Bob_Frankston@frankston.std.com>
Fri 6 Mar 1992 12:52 -0500
Date: 03-03-92 07:59:18 PM
MEMO From: John Bartlett [WITH PERMISSION TO RISKS]

I'm sitting on an American flight to Dallas working on a presentation for
tomorrow and I can't believe what I've just been told. A flight attendant
came over and politely said that it was ok to use my portable (Compaq LTE) on
the plane but that according to a new regulation, I would not be able to use
my mouse (Microsoft ballpoint)!  I of course thought she was joking but
apparently according to a new regulation only portables with a built-in
mouse  are allowed. She actually showed me the regulation which specifically
states that mice with umbilical cords can't be used because of interference
with flight navigation systems.. This basically limits the use of mice to Mac
Powerbooks and a few obscure portables. Using Freelance without a mouse is
just about impossible.  I tried to argue that there wasn't any difference
between a mouse connected with a cord and one that is internal. The flight
attendant spoke to the captain in this instance let it go but all should be
aware of this new American policy when flying.


Exporting Apples

Burt Kaliski, RSA Laboratories <burt@RSA.COM>
Fri, 6 Mar 92 15:33:22 PST
The Wall Street Journal, "Apple Computer Backs Technology of Two Companies,"
by G. Pascal Zachary, March 4, 1992, states:

In connection with its support for data encryption, Apple said it had applied
to the U.S. Commerce Department for the right to export software containing the
technology, which is generally restricted as a sensitive technology.  Apple
said it expects to receive export approval because the National Security
Agency, a leading agency on cryptographic policy, has reviewed the design and
raised no objections to it.
                              [The two companies are Adobe and RSA.
                              The Tail of Two Companies may wag the dog.
                              Apple's InCider?  PGN]


Bargain Harold finds computers no bargain

Dave Wortman <dw@swatter.fly.toronto.edu>
Fri, 6 Mar 92 13:08:35 EST
Bargain Harold's, a local discount retail chain has just been petitioned into
receivership by its creditors.  160 stores across Canada will likely be closed.
There are several RISKS related reasons for this situation:

- new management spent $15M on store refurbishment and on a computerized
  point-of-sale system with centralized inventory management.  This was
  $7M more than was authorized by the companies creditors.

- the companies immediate financial difficulties are being blamed on
  several factors including undetected errors in the new management
  information system.  Apparently this system was incorrectly predicting
  gross margin on sales and profits.  Based on this incorrect information
  management built up excessive inventories and were unable to reliablely
  predict the company's annual profit.  A profit estimate of $500K on
  Oct 2 was changed the next day to a estimated loss of $3-4M.  The
  projected loss grew rapidly over the next few months (currently $20M).

Details on the reasons for the MIS system failure are not yet available.


Re: Sizewell (and RISKS) on UK TV

Pat Place <prp@sei.cmu.edu>
Fri Mar 06 08:56:40 1992
I have not seen the Channel 4 TV program and cannot comment on the angle taken
in that presentation.  However, the impression I am getting from this forum is
that the only protection mechanism for Sizewell B is the 100,000 lines of code
software system, about which we could reasonably be concerned.

I would like to point out that I have been led to believe that a secondary
protection system exists that also has the capability of shutting down the
reactor and that this secondary system is a more traditional hardware based
system.  Further, I have been told that these two systems are independent.  So,
before we raise concerns over the safety of Sizewell B, can we have all the
facts relating to the protection mechanism and not just the worry over the
software?

Pat Place   prp@sei.cmu.edu


Risks of Automated Phone Operators (RE: RISKS-13.24)

<olson@husc.harvard.edu>
Thu, 5 Mar 92 23:16:04 -0500
Our moderator's comments about the potential fraud problems with AT&T's
operatorless collect-call system reminded me of my one experience with it.  I
had to call AAA, for the obvious reason that the car I was traveling in had
decided to fry its clutch, and they tell you to call collect.  The conversation
ran as follows:

Me: [Dial 0 + number]
Pleasant recorded voice: "...If you are making a collect call, please
press `1-1' now." [or some such]
Me: [Key 1-1]
Voice: "Please say your name."
Me: "Charles Olson"
Voice: "Please wait while we determine if your call will be accepted..."
[brrrring...brrrring.....]
[click]
AAA recording: "Thank you for calling | AT&T recording: "You have a collect
AAA Emergency Road Service. We will   | call from [my voice] Charles Olson.
accept your collect call.  If you...  | If you accept this call, please...

Me: "AAARRRGGGHHHH!!!!!!!" [SLAM!]


Speed-droid tickets junked car

Jane Beckman <jane@stratus.swdc.stratus.com>
Thu, 5 Mar 92 18:59:58 PST
I snagged this one from the alt.folklore.urban group, but it doesn't seem to be
a legend, but rather a risks illustration.  There are already lots of cars out
on the road, where the new owner has never bothered to file the change of
ownership (why you should always go with a buyer to re-register the car).  But
a junkyard?  How many states don't have any provision for the owner declaring
the car dead, but rely on a possibly unscrupulous junkyard to send in paperwork
(and/or plates)?  Having sold a junked car myself, once, I wondered about
whether the change of title would actually be sent in, or if there was a black
market for plates.  (My understanding of California law is that sending in the
"I've sold it" slip to the DMV does not actually modify the computer records on
the car.  That must be done by title change.  I have no idea what the procedure
may be in other states.)

Also, it brings up the issue of identity, when a car is "salvaged," and the
only witness who can establish an identity for the driver is a camera.  In a
manned pullover, the cop asks for a driver's license and checks it against the
registration, and if the owner isn't in the car, that person had better have a
good story.  There is no hope of catching a person who is operating a vehicle
illegally if the only enforcement is robotic.
                                             Jane Beckman [jane@swdc.stratus.com]


      Ghost Car Speeding? Photocop Snaps Auto `Retired' 8 Months Ago
      By Stephen Hunt, The Salt Lake Tribune [last month sometime]

Susan Johnson laid to rest her 1984 Toyota Tercel eight months ago.  The car
had 200,000 miles on it.  When it quit running in June, she sold it to a
wrecking yard for $50.  She was sure she'd seen the last of it.

But according to a traffic ticket Ms. Johnson received in the mail last week,
the car has been resurrected and is speeding about the streets of West Valley
City.  The ticket says Photcopy -- a computerized ticketing system that snaps
pictures of speeding carss -- caught the car traveling 47 miles per hour in a
35 mph zone on Jan. 10.

Since the car was not even running last time she saw it, Ms. Johnson is
wondering how it could be breaking speed laws.  "I was so surprised," she said.
She believes someone must be using her old license plates, which were left on
the car when she sold it.

According to Utah law, license plates are to be returned to the state Motor
Vehicle Division when a car is sold.  However, once the title has been signed
and delivered to the new owner, the previous owner is no longer liable,
according to the DMV.

Ms. Johnson was to appear today in West Valley City 5th Circuit Court to deal
with the ticket.  There, she will be allowed to see the photo and, she hopes,
prove her innocence.

Photocop uses radar, a computer and a camera to snap pictures of speeders that
show both the car's license plate and the driver.  "I hope it's not someone who
looks like me," Ms. Johnson said.

Photo radar has become a controversy at the Legislature.  Two bills regarding
the device are before lawmakers.  One would limit the use of photo-radar to
school zones only; another would ban it altogether.

Opponents say Photocop smacks of Big Brother.

Imagine That!

Bert Nelson, Weber State University, bnelson@csulx.weber.edu


Risks of Barcoded money

<markg@ichips.intel.com>
Wed, 4 Mar 92 12:06:52 PST
The Nova show on PBS last night (3 Mar 1992) was about banknote printing
technology, covering the endless battle between the banknote printers and the
forgers.

One interesting item they mentioned in passing was that some new Dutch
banknotes have a barcoded serial number, supposedly as a means of detecting
forged notes, which would have a duplicated, or unused serial number. Whenever
a batch of notes gets back to the central bank all their serial numbers are
checked by computer.

The RISKS of this are pretty obvious. Cash will no longer allow anonymous
transactions. It would be a simple step for ATMs to make a record of the serial
numbers of all notes they issue to each customer.  It would also be simple and
'logical' for stores and supermarkets to use their bar code scanners to check
the serial numbers of notes they receive (in case of forgery).

The Police could also check the numbers of notes they confiscate in connection
with crimes. Then citizens would have to explain why a bank note they were
issued by an ATM at 08:31 on 1/2/99 was found on the person of a drug dealer at
11:20 on 1/2/99, while no stores have records of that note being spent in the
intervening hours: "If you did not spend the money at an authorized retail
outlet, what did you do with it, sir?"

Barcoded bank notes was a pretty obvious step, but it seems to me that the
unpleasant civil liberties consequences to us all far outweigh the benefits of
catching a few forgers.

Mark Gonzales


Safeway "Frequent Shoppers Club"

Jeremy Epstein <epstein%trwacs@uunet.UU.NET>
Thu, 5 Mar 92 10:41:23 EST
Safeway stores in the Washington area (and perhaps other areas) recently
introduced a "Frequent Shoppers Club".  By filling out a form which includes
various demographic and financial information, you get discounts (typically
10%) on a few sale items each week (i.e., 10% below the price offered
non-members).  There's no cost to join the club.

Safeway is obviously trying to build a database of buying habits which can then
be resold to advertisers for targeted advertising.  Many people are up in arms
about "invasion of privacy".  Safeway has a program now where every time you
use your frequent shoppers card, you're automatically entered in a mini-lottery
(to encourage use of the card).

What strikes me as curious is that people don't seem to realize that the RISK
is already there.  With UPC scanners coupled with check cashing cards, there's
already the opportunity to gather and correlate the information for a large
fraction of the population.  Are there any laws which prevent the grocery store
from selling that information?  The check cashing application forms don't
preclude the store from doing whatever it wants with the non-financial
information.  Are there any instances of stores which actually do the
correlation and resell the information?

I'm also curious what reactions have been to these sorts of programs in other
parts of the country/world.

Jeremy Epstein, Trusted X Research Group, TRW Systems Division, Fairfax,
Virginia        +1 703/803-4974 UUCP: uunet!trwacs!epstein


Re: Musical Risks

<katz@merit.edu>
Thu, 5 Mar 92 18:52:26 EST
The obvious solution to the DX-7 dilemma is to sample the patches used in the
performance using a sampling synthesizer.  Of course, something is lost in the
process (especially if the timbre is modified dynamically).  You could always
sample the entire performance, of course, but then you may as well just roll a
tape.

The band Pere Ubu seems to have left its old Moog synth (knobs and patch
cords and all) behind on the last tour, but not before sampling it into
a slightly more modern synth.


Re: Musical Risks (RISKS-13.25 [so-called])

<rwk@crl.dec.com>
Thu, 5 Mar 92 21:24:46 -0500
Geoff Kuenning discusses the risk of not having DX-7s available to classical
music in 20 years time.

(Hmm, mine's about a third of the way there and still going strong).

Anyway, it's really not that hard to do a DX-7 in software if you
have the processing power.  In twenty years, I'll expect my wristwatch
to have that much processing power, if not my athletic shoe!


Re: Bureau of Centralization -- Phone Taps

Peter Wayner <wayner@cs.cornell.edu>
Fri, 6 Mar 1992 18:16:20 GMT
USA Today reports in Friday, March 6th paper that the Dept. of Justice is
floating a proposal that would require phone companies to centralize phone
tapping and make it easier for law enforcement agencies to listen in. They note
that this would raise monthly phone bills for all consumers.

Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:wayner@cs.cornell.edu    Office: 607-255-9202 or 255-1008


Re: Bureau of Centralization -- phone taps

Steve Dever <Steve.Dever@eng.sun.com>
Fri, 6 Mar 92 13:34:48 PST
The 6-Mar-1992 San Jose Mercury News has an article about this on page 5A. The
article is titled: "White House wants consumers to pay bill for better
wiretaps."  According to the article, the Justice Dept. is worried that "the
widespread use of digital transmission, fiber optics and other technologies"
make it difficult for government agencies to intercept transmissions.  The
Justice Dept.  is proposing a bill which would direct the FCC to "devise rules
to give law enforcement agencies access to conversations for court ordered
wiretapping."  Phone companies would then be required to follow the rules.  The
bill would also authorize the FCC to permit the phone companies to increase
rates to cover the cost of implementing the rules.

The proposal has been discussed with Sen. Ernest Hollings, chair of the Senate
Commerce Committee which oversees the FCC.
                                                     Steve Dever


Re: Bureau of Centralization -- phone taps

Peter Wayner <wayner@cs.cornell.edu>
Fri, 06 Mar 92 17:03:12 -0500
I've had a few second-order thoughts about the matter.

0) The Justice department seems to want to ensure that there is some place in
the system where the signal can be easily turned into sound.  It does not seem
to prohibit individual people from encrypting their messages.  It just means
that the phone company needs to provide a tap.

1) Centralized phone tapping doesn't necessarily mean less privacy.  I can
imagine a huge bureaucracy at the local phone companies' tap center filled with
mean clerks who would demand to see the proper forms authorizing the taps.
"No, I'm sorry Officer. You didn't submit 44/22-G that authorizes the recording
of conversations from another state that are forwarded to a third state by a
central routing office without being delivered to the phone in your
juristiction.  A 44/22-F authorizes only cross-county juristiction expansion."

Now each police department probably has its own set of mikes and tape recorders
and can place them as it wishes.

2) I don't necessarily believe that the above will happen.


New Legislation on Computer Security

Lance J. Hoffman <hoffman@seas.gwu.edu>
Fri, 6 Mar 92 12:16:38 EST
Recently introduced legislation may be of interest to RISKS readers.  S. 2198,
the Intelligence Reorganization Act of 1992 and HR 4165, the National Security
Act of 1992, essentially give responsibility for all comsec to the National
Security Agency and for all information security to them also.  This, of
course, would completely reverse, existing structure which has just been in
place for a couple of years, and apparently take much responsibility away from
the National Institute of Standards and Technology (NIST) in the Dept. of
Commerce and put it (back) at NSA in the Defense Dept.

If enacted, this would have important implications for export control and
crypto policy, which are of interest to many RISKS readers.
                                                             Lance Hoffman

Department of Electrical Engineering and Computer Science, The George
Washington University, Washington, D. C. 20052 (202) 994-4955


Re: Michelangelo

<[anonymous]>
Thu 5 Mar 1992 19:34 -0500
I spent the day today clearing many viruses.  In the last week xxxx and I have
cleared over 80 Michelangelos from ....  Also, we have cleared many Cascades,
New Zealands, Joshis, and others.  Easily over 120 infections in the last week.

You may have heard that just changing the date is an adequate defense; it is
not.  You may have heard that not using the computer that day is a defense; it
is not.  You may have learned many things; almost all of them untrue.  All
anyone needs to know is that Michelangelo is a very widespread virus.  It is
destructive.  It can be removed only by using proper procedures.  It is
completely manageable and removable.

Procedures:

Detect the virus (Use any commercial or other package that is up to date)
Cold Clean Boot (Turn off PC, insert DOS Startup notchless diskette,
  turn on PC)
Copy first track into memory
Copy partition table from virus (sector 1) into partition table of original
  (sector 7) in memory
Copy original over virus in memory
Zero the copy of the original in memory
Write the result back to the first track.

As you can see, nothing magic, just plain old careful procedure.

Anyone who leaves a diskette in their boot drive by accident when they boot
should have their wrist slapped.


Re: Michelangelo (RISKS-13.21)

Graham Mainwaring <octogard!graham@duke.cs.duke.edu>
Thu, 05 Mar 92 22:10:45 EST
In RISKS-13.21, jcav@midway.uchicago.edu writes about his local news
station omitting to mention that the Michelangelo virus only affects
MS-DOS machines.  I submit that this really isn't much of a problem, for
the following reasons:

   1. MS-DOS users are actually affected by the virus, so in their case,
the report was correct and useful.

   2. Macintosh users have such a frightening virus problem already that
there are very few left who don't routinely disinfect their machines.

   3. Everyone else is either sophisticated enough to understand the
situation, or has a MIS department to call and get straightened out by.


A more serious problem is the entire area of media handling of
Michelangelo.  Why is this particular virus getting almost
saturation-level coverage in the media?  Is Michelangelo really any
worse than Stoned, 1701, Jerusalem-B, or any of the other MS-DOS
viruses that have been circulating lately?

Even worse, will people assume that once they have scanned their disks
for Michelangelo, that the threat is over?  After all, the fuss has
quieted down.  Why should it be necessary to do it again?

Internet: octogard!graham@deepthot.cary.nc.us   BBS: +1 919 876 7213
UUCP:     ...!duke!wolves!deepthot!octogard!graham   WWIVnet: 1@9970


Technical terminology -- and viruses

Brian Rice <rice@dg-rtp.dg.com>
Fri, 6 Mar 1992 14:16:41 -0500
Here's another one for the "risks of posting to RISKS" file.

In RISKS-12.30, 11 Sep 1991, I wrote, concerning so-called beneficial viruses:

   "...the idea of code roaming around in a network looking for
   opportunities to do good is what we technical types call `way cool.'"

In _Newsweek_, 20 Jan 1992, John Schwartz writes, concerning virtual-
reality video games:

   "When you shoot, your nemesis is blown to colorful smithereens--
   a sight that is, to use a technical term, way cool."

It's just like William S. Burroughs said: "Language is a virus."

Brian Rice, DG/UX Software Quality Assurance, Data General Corp., Research
            Triangle Park, N.C.  rice@dg-rtp.dg.com +1 919 248-6328


Re: A RISK architecture? (DEC's Alpha)

Steve Bellovin <smb@ulysses.att.com>
Thu, 05 Mar 92 19:30:01 EST
Brian Randell describes how the Alpha uses imprecise arithmetic traps, and
speculates that it's a risk to program correctness.  With all due respect, I
disagree.  Based on my experience with imprecise interrupts on the 360/91, lo
these many years ago, I would classify imprecise interrupts as more of a hassle
when localizing faults, rather than any risk to the program's correct behavior.
That is, the interrupts -- which typically signified erroneous program behavior
-- still happened, and still caused the program to abort.  But it took rather
more debugging effort to figure out which instruction caused the trap.  Unless
one is relying the interrupt handler to perform the appropriate fix-up -- a
technique that I regard as far more risky and non-portable than imprecise
interrupts -- correct programs should not behave any differently.

He also describes the barrier instruction as a ``sop to DEC's technical
conscience''.  Not so.  Its purpose is to help the programmer identify the
offending instruction.  And compilers can (and were able to) generate such
instructions on appropriate boundaries.  I recall vividly, 20+ years later,
finding that a zero- divide fault took place 11 instructions after the
offending divide, and after the divisor register had been overwritten with a
non-zero value.  But it had to be that instruction; there were only two divide
instructions in the entire program, and the other referenced a still-intact
constant.

If there is a danger here, it's from the hardware design itself.  Pipelined
architectures imply parallelism, of course, and that's harder to get right.
But the hardware designers seem to do a better job which such things than do
the software designers...
                                        --Steve Bellovin


Alpha's "imprecise arithmetic traps" are nothing new..

"Dr. Tom @MKO, CMG S/W Mktg, DTN 264-4865 05-Mar-1992 1834" <blinn@dr.enet.dec.com>
Thu, 5 Mar 92 15:46:23 PST
In RISKS-13.25 (Thursday 5 March 1992) Brian Randell writes about the new Alpha
RISC architecture and comments on its imprecise arithmetic traps.

Those of us who ever programmed the IBM System/360 Model 91 under OS/MVT (or,
I'd imagine, other OSes) will recall that it, too, had imprecise interrupts, in
large part because it provided (limited) pipelining and multiple issue of
arithmetic instructions.  I don't recall the details -- it has been a long time
-- but as I recall it could overlap integer and floating point compute
operations, and perhaps did multiple floating multiplies in parallel.  In any
case, the careless programmer could easily get the dreaded 0C5 ABEND, along
with a generally useless dump, when one of the parallel operations failed.

IBM, in their infinite wisdom, did not provide a Trapb instruction to allow the
programmer to force precise interrupts -- at least, I don't recall any such
instruction.  Instead, if you couldn't guess what was wrong by looking at the
code, you could carry it to a different System/360 model (like the Model 75)
that didn't provide the parallelism and get a precise interrupt.

What's neat about the Alpha design is, of course, that you can get precise
traps when you need or want them, at some performance penalty, but you can go
blazingly fast when you don't need that precision.  Compared to other ways of
addressing the problems implied by a pipelined multi-issue architecture, the
Alpha approach seems rather clean and clever to me.  But then, I may be biased,
and I'm not an experienced computer architect.

Dr. Thomas P. Blinn, Digital Equipment Corporation, Digital Drive -- MKO2-2/F10
Merrimack, New Hampshire 03054 ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865


Imprecision not considered harmful

Eric Sosman x4425 <eric@tardis.hq.ileaf.com>
Fri, 6 Mar 92 09:49:45 EST
In RISKS-13.25 (so-called), Brian.Randell@newcastle.ac.uk seems alarmed at the
notion of imprecise delivery of instruction exceptions.  I was similarly
alarmed when I first heard of them ...  twenty-plus years ago, with the IBM
System/360 model 91.  (I'm not claiming the 91 was the first such
implementation, simply that is was the first in my personal experience.)

It is only sometimes useful to identify "the" instruction which blew
up; usually a coarser localization will do.  The imprecise-exception
architectures I know of all provide an instruction which acts as a
barrier, with the promise that no exception delivered after the
barrier can be due to any instruction fetched before the barrier.  The
360-91 used "BR 0,0": a "no-op" in the form of a pipeline-draining
conditional branch.  Compilers inserted this instruction at strategic
locations like subroutine prologues and epilogues, or (if requested)
between segments of code generated for different source statements.

Imprecise exceptions make it difficult to write trap handlers which
fix up the results of failing instructions.  I have written such
handlers, but have never found them satisfactory -- the "correct" fix
is too context-dependent to be dealt with by such a low-level
approach.  Error detection and correction work much better in the
higher levels, and imprecise instructions don't make the superior
approach impossible or even difficult.

Eric Sosman                                         eric@hq.ileaf.com
Interleaf, Inc. / Prospect Place, 9 Hillside Ave. / Waltham, MA 02154

Please report problems with the web pages to the maintainer

Top