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 8 Issue 52

Sunday 9 April 1989

Contents

o Valdez follow-up...
Dean Riddlebarger
o Phobos
Bob Morris
o Presumption of innocence -- for computers
Peter da Silva
o 1988 Toronto election
Mark Brader
o California's anti-fax-ad bill
David M. Gursky
o Man bytes dog
Charles Youman
o Re: Elevator accident kills 13-year-old (John Luce via John
J.G.) Mainwaring
o Need DRAMs?
Mike Raffety
o Cellular telephones
Steven C. Den Beste
o CDC operating system has passwords in batch files
Gerard Stafleu
o Cornell Chronicle coverage of Robert T. Morris
Manny Farber via Dave Farber
o Info on RISKS (comp.risks)

Valdez follow-up... (Re: RISKS-8.51)

Dean Riddlebarger <rdr@killer.dallas.tx.us>
7 Apr 89 13:05:25 GMT
> [notes on autopilot connection to tanker spill.....]

Another newsgroup has an article today in which the author claims to have
seen the following Valdez-related tale:  The installation of Coast Guard
radar equipment which could have been sophisticated enough to track the
errant vessel before it was too late had been deferred in order to provide
more budget money for our ersatz war on drugs.  Risks Digest is not the
place for major social discussion on this subject, but I do find it
interesting that the ebb and flow of socially-oriented politics may have
ultimately had an impact on the ability of accident prevention systems to
function at maximum effectiveness...

[Heated discussion on budget priorities, social effects, and morality
should probably be directed to misc.headlines, alt.drugs, alt.flame,
or some other social newsgroup.......:-)]

Dean Riddlebarger, Systems Consultant - AT&T, [216] 348-6863

Disclaimer:  Any opinions expressed are mine.  I'm sometimes quite proud of
them, so I won't try to give credit to my employer or anyone else...


Phobos

<RMorris@DOCKMASTER.NCSC.MIL>
Sun, 9 Apr 89 19:21 EDT
Forget computer risks - it should be clear by now that Phobos is inhabited and
that they are willing and able to neutralize large threatening objects that are
aimed at them.  Just wait till they send something in return - that's when
we'll really need SDI.


Presumption of innocence -- for computers

<ficc!peter@uunet.UU.NET>
Fri, 7 Apr 89 12:54:14 -0400
There have been many messages in RISKS about people believing computers
before people. They generally end with something like the following (taken
from a recent message):

> This says volumes about
> the propensity to believe the computer at all costs: the customer "couldn't
> be right - the computer says so."

One thing to bear in mind is that the computer can be mistaken, but it
can't be malicious. The computer program won't deliberately try to defraud
a (bank/travel agency/government department/whatever). I would certainly
hope that the bank would believe the computer over a customer with no
documentation, at least until they can perform an audit.

On the other hand, of course, if you CAN document your case and they still
stand by the computer... that's a whole different kettle of fiche.

Peter da Silva, Xenix Support, Ferranti International Controls Corporation.


1988 Toronto election

Mark Brader <msb@sq.sq.com>
Thu, 6 Apr 89 22:31:24 EDT
I don't think there's been any more in Risks about Toronto's first foray into
machine-counted votes.  To recap the earlier items: many ballots were silently
rejected by the (optical-recognition) machines because they were not cut
accurately, and a demand for a manual recount was blocked because the election
law required any recount to use the same methods as the original count.

The courts must have given this some precedence, because we have already had an
appellate court ruling.  The ruling was that it was not reasonable to enforce
that provision of the law when the method itself was clearly defective.
Consequently, manual recounts were held where necessary, and in one district
the result actually did change.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com


California's anti-fax-ad bill...

<dmg@mitre.mitre.org>
Thu, 06 Apr 89 16:49:02 EST
In RISKS 8.50, Brian Kanto (via Skip Montanaro) writes about California's
attempt to make sending junk mail by facsimile illegal.  I wonder how legal
this is.  Suppose someone here in Washington sends a junk fax to someone else
in California (I know, I'm assuming negligible costs for the phone call).  How
does California expect to prosecute someone in the District of Columbia for
violating a California law while the person is in the District of Columbia?

If the law says that "a person WITHIN THE BORDERS OF THE STATE OF CALIFORNIA
who uses..." it should be alright, but otherwise, there are some serious
questions about infringement of interstate commerce (which is properly under
the jurisdiction of the Federal Government) that need to be addressed.

Of course, this whole message begs the question "How is this a risk to society?"

David M. Gursky, Member of the Technical Staff, W-143, Special Projects Dept.
The MITRE Corporation


Man bytes dog

Charles Youman (youman@mdf.mitre.org) <m14817@mitre.mitre.org>
Wed, 05 Apr 89 14:55:54 EST
This week's issue of Computerworld contains an article on page 10 that
may be of interest to RISKS readers.  The article is titled "Humane
Society collars a chip off the old hound dog."  Beginning the first
week in May, the Marin (CA) County Humane Society will begin injecting
microchips the size of a grain of rice into animals up for adoption.
The chip can be activated by waving a scanner over the animal's back
and it results in a unique 10-digit number being displayed.  The number
is used to query a database that contains the owner's name.  The purpose
of the system is returning lost pets to their owners.

These implants have been available for a fee in clinics throughout
Canada since last July.  They have been used by some shelters and
veterinarians on an optional basis in the U.S. since the last quarter
of 1988.

The vendor of this system is International Infopet System of Agoura
Hills, CA.

The relevance for RISKS?  What if someone wants to use this technology
as the basis for a national identity card for people.


re: re: Elevator accident kills 13-year-old (RISKS-8.50)

J.G. <John>
7 Apr 89 13:06:00 EDT
FORWARDING OF A MESSAGE FROM JOHN LUCE:

I was a Software Engineer on the Elevonic 401 project (but not on the
cab software that controls the features discussed).

Item 1: The sensors that are malfunctioning on the doors were viewed as
unsafe by the engineers involved. However, mgt. felt the risk was small
compared to the COST savings obtained by using them. 1 problem was that they
needed adjustment often, but not replacement, while the older versions
had to be replaced more often but were vastly more reliable while in service.

Item 2: The doors are forced close to prevent the tie-up of the elevator.
Poor maintenance will cause the door bumpers to not retract the door. This
is an easy upkeep and will fail only if the building has decided against
a periodic maintenance plan and just calls when something breaks down.
The holding open of the doors causes the car to go into 'Delayed Car' mode
which takes the car out of service. When the doors are finally allowed to
close, the car has to intialize itself. If it is in the lower half of the
building, it will run up to initialize, and run down if in the upper half
regardless of buttons pushed.

Item 3: The length of door open time is decided by the building owner and
is put in to a Contract Table. The only thing for sure is that a door that
opens answering a Hall Call will stay open longer than a door that opens
for a Car Button.

Item 4: The number of floor buttons pushed doesn't cause the confusion of
the elevator, it's the number of buttons tempered by the weight inside
the car. If the weight sensors do not show enough weight (arbitrary, but
effective) for the number of buttons pushed, it cancels the buttons. To
understand the implementation, the name of the module that does that is
called 'KIDS'. It prevents the floor to floor runs kids like to have occur
by pushing buttons and getting out of the car before the doors close.

Item 5: Design intent. If someone can't read the arrow to know which way
the car is running, he shouldn't be allowed to put in a car call away from
the direction it's moving.

Item 6: Unless this is OLD software, i.e. the building has not upgraded
it, this is impossible to do. The scan and latch of buttons was placed
in a 96 millisecond task.

Item 7: All the engineers agree with you on this, but since Otis sells
to many foreign countries (including the oriental ones), this was the
only recourse left open. I'm sure better icons could have been devised.

Finally, displays and voice are customer designated and maintained by
the customer. If he fails to read the manual, these items will appear
to malfunction.

I hope this clears it up. I firmly believe, even though I no longer work
there, that Otis Elevator North America R&D had the best set of s/w
people I've seen overall.

Any opinions expressed above are my own and not to be attributed to
my present or previous employer.

John Luce


Need DRAMs?

Mike Raffety <miker@porsche.UUCP>
Sat, 8 Apr 89 21:02:27 CDT
From "Electronics", April 1989, page 18, news briefs:

NEED DRAMS?  HERE'S ONE WAY TO GET THEM

If the shortage of dynamic random-access memories is abating, a band of armed
robbers in California's Orange County hasn't heard about it.  Over the past six
months, at least five companies have been hit in late-night robberies, with the
memory chips as the main target.  The biggest haul was at Western Digital Corp.
in Irvine, where two bandits forced an unarmed security guard to open a storage
area and took some $100,000 worth of DRAMs, according to authorities.  The
armed robberies are a new development in the DRAM shortage, they say, with
previous thefts largely being inside jobs.


Cellular telephones

<denbeste@BBN.COM>
Fri, 07 Apr 89 20:27:24 -0400
From the 4/7/89 Boston Globe:

"Some Bostonians are having the time of their lives eavesdropping onNynex Mobile
Communications cellular phones. With the help of their trusty Radio Shack
Portavision 55s, designed to pick up the audio portion of UHF television
signals, these naughty people claim to have heard Secretary of Finance and
Administration Edward Lashman discussing a press conference with his wife and
Boston Mayor Ray Flynn checking in with his office. "It makes for a great day,"
says one listener who calls in sick at his job to spend the day with his ear
pressed against the radio. "At 7 a.m. you hear the construction people
complaining that their suppliers delivered the wrong stuff. At 9, it's the
lawyers telling their clients how to lie in court. After noon the risque stuff
starts..."

The article goes on to say that Radio Shack no longer sells that model, and
that the FCC says such eavesdropping is illegal.

Steven C. Den Beste,   BBN Communications Corp., Cambridge MA


CDC operating system has passwords in batch files

Gerard Stafleu <gerard@uwovax.uwo.ca>
Fri, 7 Apr 89 12:10:57 edt
CDC has a (relatively) new operating system for its Cybers, called NOS/VE (it
has been around for a few years).  While browsing through the tutorial manual,
I came upon the section on batch jobs.  It contains the following paragraphs:

  To submit a batch job from your terminal, you first create a file that
  contains the job and then specify the name of the file in the SUBMIT_JOB
  command.

  The first line of the file must contain the LOGIN command.  This command
  specifies the user name, password and family name to be used for the job,
  as in the following example:

      login login_user=pat password=secret login_family=nve

So the user name and password will be sitting there together in a disk file, in
plain text.  I don't think I need to elaborate on the RISKs of this.

Note that the keeping of user name and password is not necessary, as the
file is submitted from a terminal, where the user is already logged in.

CDC apparently noticed this at some point, and in a footnote they state:
"If, for security reasons, you do not want to include your password in a
file, you can use [some other command]."  Nevertheless, this is just a
footnote, and the first thing the users are taught about batch jobs is
to put their user name and password in a file!

Gerard Stafleu, (519) 661 - 2151 Extension 6043
General E-mail address: gerard@uwovax.uwo.ca

    [Of course this should not surprise you.  It is unfortunately still quite
    common. to find embedded passwords.  In many IBM mainframe systems, for
    example, FILE passwords are routinely stored, shared, and multiply used --
    for different files.  PGN]


Cornell Chronicle coverage of Morris

"David J. Farber" <farber@dsl.cis.upenn.edu>
Sun, 9 Apr 89 6:31:17 EDT
The Cornell Chronicle is the Administration's propaganda organ.  As such, their
coverage of the [Robert] Morris report is relatively one-sided, but since they
got the report in advance, they summarized it.  I'll put the last paragraph
right here:  Copies of the report are available from the Office of the Vice
President for Information Technologies, 308 Day Hall, [area code 607] 255-3324.

CORNELL PANEL CONCLUDES MORRIS RESPONSIBLE FOR COMPUTER WORM
(By Dennis Meredith, Cornell Chronicle, 4/6/89)

  Graduate student Robert Tappan Morris Jr., working alone, created and spread
the "worm" computer program that infected computers nationwide last November,
concluded an internal investigative commission appointed by Provost Robert
Barker.
  The commission said the program was not technically a "virus"--a program that
inserts itself into a host program to propagate--as it has been referred to in
popular reports.  The commission described the program as a "worm," an
independent program that propagates itself throughout a computer system.
  In its report, "The Computer Worm," the commission termed Morris's behavior
"a juvenile act that ignored the clear potential consequences."  This failure
constituted "reckless disregard of those probable consequences," the commission
stated.
  Barker, who had delayed release of the report for six weeks at the request of
both federal prosecutors and Morris's defense attorney, said, "We feel an
overriding obligation to our colleagues and to the public to reveal what we
know about this profoundly distrubing incident."
  The commission had sought to determine the involvement of Morris or
other members of the Cornell community in the worm attack.  It also studied
the motivation and ethical issues underlying the release of the worm.
  Evidence was gathered by interviewing Cornell faculty, staff, and
graduate students and staff and former students at Harvard University, where
Morris had done undergraduate work.
  Morris declined to be interviewed on advice of counsel.  Morris had requested
and has received a leave of absence from Cornell, and the university is
prohibited by federal law from commenting further on his status as a student.
  The commission also was unable to reach Paul Graham, a Harvard graduate
student who knew Morris well.  Morris repotedly contacted Graham on Nov. 2.,
the day the worm was released, and several times before and after that.
  Relying on files from Morris's computer account, Cornell Computer Science
Department documents, telephone records, media reports, and technical reports
from other universities, the commission found that:
  - Morris violated the Computer Sciences Department's expressed policies
against computer abuse.  Although he apparently chose not to attend
orientation meetings at which the policies were explained, Morris had been
given a copy of them.  Also, Cornell's policies are similar to those at
Harvard, with which he should have been familiar.
  - No member of the Cornell community knew Morris was working on the worm.
Although he had discussed computer security with fellow graduate students, he
did not confide his plans to them.  Cornell first became aware of Morris's
involvement through a telephone call from the Washington Post to the science
editor at Cornell's News Service.
  - Morris made only minimal efforts to halt the worm once it had propagated,
and did not inform any person in a position of responsibility about the
existence or content of the worm.
  - Morris probably did not indent for the worm to destroy data or files, but
he probably did intend for it to spread widely.  There is no evidence that he
intended for the worm to replicate uncontrollably.
  - Media reports that 6,000 computers had been infected were based on an
initial rough estimate that could not be confirmed.  "The total number of
affected computers was surely in the thousands," the commission concluded.
  - A computer security industry association's estimate that the worm
caused about $96 million in damage is "grossly exaggerated" and "self-serving."
  - Although it was technically sophisticated, "the worm could have been
created by many students, graduate or undergraduate ... particularly if
forearmed with knowledge of the security flaws exploited or of similar flaws."
  The commission was led by Cornell's vice president for information
technologies, M. Stuart Lynn.  Other members were law professor Theodore
Eisenberg, computer science Professor David Gries, engineering and computer
science Professor Juris Hartmanis, physics professor Donald Holcomb, and
Associate University Counsel Thomas Santoro.
  Release of the worm was not "an heroic event that pointed up the weaknesses
of operating systems," the report said.  "The fact that UNIX ... has many
security flaws has been generally well known, as indeed are the potential
dangers of viruses and worms."
 The worm attacked only computers that were attatched to Internet, a national
research computer network and that used certain versions of the UNIX operating
system.  An operating system is the basic program that controls the operation
of a computer.
  "It is no act of genius or heroism to exploit such weaknesses," the
commission said.
  The commission also did not accept arguments that one intended benefit of the
worm was a heightened public awareness of computer security.
  "This was an accidental byproduct of the evant and the resulting display
of media interest," the report asserted.  "Society does not condone
burglary on the grounds that it heightens concern about safety and security."
  In characterizing the action, the commission said, "It may simply have been
the unfocused intellectual meanderings of a hacker completely absorbed with his
creation and unharnessed by considerations of explicit purpose or potential
effect."
  Because the commission was unable to contact Graham, it could not determine
whether Graham discussed the worm with Morris when Morris visited Harvard about
two weeks before the worm was launched.  "It would be interesting to know, for
example, to what Graham was referring to in an Oct. 26 electronic mail message
to Morris when he inquired as to whether there was 'Any news on the brilliant
progject?'" said the report.
  Many in the computer science community seem to favor disciplinary
measures for Morris, the commission reported.
  "However, the general sentiment also seems to be prevalent that such
disciplinary measures should allow for redemption and as such not be so harsh
as to permanently damage the perpetrator's career," the report said.
  The commission emphasized, that this conclusion was only an impression from
its investigations and not the result of a systematic poll of computer
scientists.
  "Although the act was reckless and impetuous, it appears to have been an
uncharacteristic act for Morris" because of his past efforts at Harvard and
elsewhere to improve computer security, the commission report said.
  Of the need for increased security on research computers, the commission
wrote, "A community of scholars should not have to build walls as high as the
sky to protect a reasonable expectation of privacy, particularly when
such walls will equally impede the free flow of information."
  The trust between scholars has yielded benefits to computer science
and to the world at large, the commission report pointed out.
  "Violations of that trust cannot be condoned.  Even if there are unintended
side benefits, which is arguable, there is a greater loss to the community
as a whole."
  The commission did not suggest any specific changes in the policies of
the Cornell Department of Computer Science and noted that policies against
computer abuse are in place for centralized computer facilities.  However,
the commission urged the appointment of a committee to develop a university-
wide policy on computer abuse that would recognize the pervasive use of
computers distributed throughout the campus.
  The commission also noted the "ambivalent attitude towards reporting
UNIX security flaws" among universities and commercial vendors.  While
some computer users advocate reporting flaws, others worry that such
information might highlight the vulernatiblity of the system.
  "Morris explored UNIX security amid this atmosphere of uncertainty, where
there were no clear ground rules and where his peers and mentors gave no clear
guidance," the report said.
  "It is hard to fault him for not reporting flaws that he discovered.  From
his viewpoint, that may have been the most responsible course of action,
and one that was supported by his colleagues."
  The commission report also included a brief account of the worm's course
through Internet.  After its release shortly after 7:26 p.m. on Nov 2, the worm
spread to computers at the Massachusetts Institute of Technology, the Rand
Corporation, the University of California at Berkeley and others, the
commission report said.
  The worm consisted of two parts--a short "probe" and a much larger "corpus."
The problem would attempt to penetrate a computer, and if successful, send for
the corpus.
  The program had four main methods of attack and several methods of defense to
avoid discovery and elimination.  The attack methods exploited various flaws
and features int he UNIX operating systems of the target computers.  The worm
also attempted entry by "guessing" at passwords by such techniques as
exploiting computer users' predilections for using common words as passwords.
  The study's authors acknowledged computer scientists at the University
of California at Berkeley for providing a "decompiled" version of the worm
and other technical information.  The Cornell commission also drew on
analyses of the worm by Eugene H. Spafford of Purdue University and
Donn Seeley of the University of Utah.

   [This item also was sent to RISKS by Spaf and by Geoff Goodfellow.]

Please report problems with the web pages to the maintainer

Top