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 5 Issue 4

Wednesday, 24 June 1987

Contents

o Immoderation and Nonmoderation
PGN
o A Passive-Aggressive User Interface -- U.Iowa telephone tidbits
Ray Ford
o Bogus ROOT domain server on ARPAnet
Paul Richards via Robert Lenoil
o Printer raises utility false alarm
A. Harry Williams
o New VAX UNIX file system disk purge runs amok
Mike Accetta via Chris Koenigsberg
o Info on RISKS (comp.risks)

Immoderation and Nonmoderation

Peter G. Neumann <Neumann@csl.sri.com>
Tue 23 Jun 87 16:53:12-PDT
A few of you have received a UUCP message through "cbosgd" that intended to
demonstrate that systems are not really very secure and that it is easy to
bypass moderation on supposedly moderated news groups.  (The message in
question was written as a response to someone who thought that this might be
difficult!) The existence of that message should not surprise any readers of
RISKS, who by now have no trouble grasping the fact that there is no such
thing as complete security.  However, the message was sent not through
RISKS@CSL but through one of our innumerable redistribution points (and thus
was received by only a very small fraction of all RISKS readers).  The
possibility of doing that should not be a surprise, particularly in that
most local redistribution centers have been explicitly set up to be
automatic forwarders rather than requiring manual intervention.

A long time ago Dave Parnas objected to having his position papers on Star
Wars serialized in Soft-Eng@MIT-XX and circulated via netmail, partly
because there are no guarantees that the received message was actually
authentic.  (Crypto checksums could be used, although they create a new set
of vulnerabilities.)  Sooner or later someone will indeed post a bogus
message to the entire RISKS group, with fake authorship and bypassing my
moderation; I will then have to point out that I stated in RISKS-5.4 (and
earlier, as well) that it can of course be done.  (I have tried to use
TOPS-20 as sensibly as possible to make such immoderation nontrivial, but I
cannot seal off that possibility altogether.)  Besides, I would like to
believe that the RISKS community consists mostly of socially conscious and
thoughtful individuals, interested in learning and growing in awareness.

Careful RISKS readers must by now realize that I am probably the last person
in the world who would say that something is really secure -- I know that
NOTHING is, including the interposition (or imposition?) of RISKS moderation.  
I simply must rely on your sensitivity not to mount attacks.  We will soon
have to switch to a UNIX system on a Sun workstation as the RISKS source,
and at that point I would otherwise have to abandon all hope of moderation.

     PGN


A Passive-Aggressive User Interface -- U.Iowa telephone tidbits

<Peter G. Neumann <Neumann@csl.sri.com> [Really-From Ray Ford]>
Wed 24 Jun 87 00:17:17-PDT
(From the University of Iowa "fyi", 12 June 1987, p.2, in its entirety.
Contributed by Ray Ford, whose interspersals are in square brackets.)

Telephone tidbits

[The Passive Aspect:]

No answer

University telephone users should be advised that when a University
telephone has been programmed for call forward busy/no answer, the caller
will hear three rings before the unanswered phone switches to its forwarded
number.  If that number is busy, however, the caller will not get a busy
signal but will continue to hear the ringing signal.  This is a problem with
the software for the system, according to the office of telecommunications,
for which there is no apparent solution.

[The Aggressive Aspect:]

Nothing in common

The full-feature electronic telephones called D-Terms now in use on the
University system are not compatible with Northwestern Bell or any other
telephone system.  Serious mishap, including explosion and fire, can occur
if these telephones are connected to the wrong system.


Bogus ROOT domain server on ARPAnet

Robert Lenoil <@EDDIE.MIT.EDU:LENOIL@DEEP-THOUGHT.MIT.EDU>
Fri 19 Jun 87 15:31:12-EDT
Here is an interesting example of how a malicious host could cause
considerable interruption to the ARPANET:        

  Subject: Bogus ROOT domain server on ARPAnet       [PGN Excerpting Service]
  Date: Mon, 08 Jun 87 22:40:46 -0500
  From: Paul Richards <richards%shangrila.cs.uiuc.edu@a.cs.uiuc.edu>

  Tonight, we had what I'd call a major failure on the ARPA domain name system.
  A system at NORTHWESTERN.ARPA, [10.4.0.94], started advertising itself as a
  root domain name server, with the consequences that we stopped being able to
  locate any domain names at all....

  Paul Richards University of Illinois at Urbaba-Champaign; Computer Science
        richards@b.cs.uiuc.edu, +217 333-3536


Printer raises utility false alarm

"A. Harry Williams" <HARRY%MARIST.BITNET@wiscvm.wisc.edu>
Mon, 22 Jun 87 10:01:02 EDT
Last week the local utility company was training the Customer Support Reps
(CSR) on the new procedures for emergency outages, such as during a storm.
There were several people from different areas in the company, all at the
main site.  One of the screens on the computer terminal used for handling
the emergency problems calls for the name of a printer to print the report.
One of the people involved could only remember the name of the printer in
the main operations for the company.  Needless to say, there were several
hurried phones calls after a utility company crew and police arrived at the
"scene of the downed power lines" to find no problem existing.  Fortunately,
the name of the CSR is on report, so they were able to track down the person
that way, and find out the false alarm.  A little while later the operations
room called back and asked if they had sent out a gas crew an hour before.


[New VAX UNIX file system disk purge runs amok]

<Mike.Accetta@q.cs.cmu.edu>
22 Jun 87 13:03:20 EDT
We experienced serious file system losses on many of the VAX UNIX systems
this weekend beginning early in the morning on Saturday 6/20.  At that time,
a new system file which controls the disk purge operation was distributed
and failed on all of the VAX systems which received it.  On all but three
machines this operation was aborted after removing a substantial number of
its system files but before any private files were affected. These machines
were returned to service upon restoration of their system files during the
weekend.  The following machines:

    SPEECH2.CS.CMU.EDU  SAM.CS.CMU.EDU       ME.RI.CMU.EDU

each also lost a large part of one of their private file partitions.  These
file partitions are in the process of being restored from tape backups and
the machines should be back in at least limited service by 1400 Monday, 6/22.

Normally, the particular disk purge operation in question would have
recursively removed all files in /usr/preserve that were more than a week
old.  However, on Saturday morning the mode of failure resulted in the
attempted recursive removal beginning at / of all files which were more than
a week old on each affected system.

Machines with (to our knowledge) only system files removed were:

    PH1.SPEECH.CS.CMU.EDU FAS.RI.CMU.EDU    GNOME.CS.CMU.EDU
    G.CS.CMU.EDU      THEORY.CS.CMU.EDU UNH.CS.CMU.EDU
    ROVER.RI.CMU.EDU      ISL1.RI.CMU.EDU   IUS1.CS.CMU.EDU
    IUS2.CS.CMU.EDU   SPEECH1.CS.CMU.EDU    CIVE.RI.CMU.EDU

Finally, a number of the VAX workstations were also affected.  Problems
have been corrected and all system files restored on:

    LAB.AGORA       EDJ.ARCHONS EMC.CS      EP.FAC
    MRT.MACH        PIE5.MACH   A.NL        AMADEUS.PRODIGY
    DRAKON.RESDOC   F.SPEECH    G.SPEECH    Y.SPEECH
    SPEECH3     NDIFF.VLSI  D.SPEECH

Some workstations where a problem is suspected were inaccessible and have
not yet been checked and/or corrected.  We will attempt to track down and if
necessary correct problems with these systems on Monday.  You may also
contact the Operator at x2607 to report a problem if your machine appears to
be in this category,

So far as we know, no private files on any workstation examined so far were
removed and over all only VAX mainframe and workstation systems were
affected.  At this point, while we know what went wrong and where, we still
do not completely know why.

We do apologize for any inconvenience this failure has caused.

Please report problems with the web pages to the maintainer