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 15 Issue 17

Thursday 21 October 1993

Contents

o A chip, off the old block
PGN
o Fiber Optic Cable "Meltdown" in Connecticut
E.M. Culver
o NII confidential report "on sale"
Martyn Thomas
o US Has It Too (Re: Russian Doomsday Device)
Li Gong
o Media Explosion => Loss of Community ?
Fred Baube
o Re: Auto rentals, law suits, and the risks
Jerry Leichter
o Dangers of anonymous remailers
anonymous
o Privacy Digests
PGN
o SunOS and Solaris vulnerabilities
PGN
CERT Advisory
o Info on RISKS (comp.risks)

A chip, off the old block

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 21 Oct 93 14:27:27 PDT
A 2.5-year-old boy and his dog wandered off from their home block in
Blacktown, near Sydney, but apparently neither of them could figure out how
to get home again.  The dog wore a tag indicating that he had a microchip
implanted by the Australian Animal Registry, which led to identification of
the dog's owners, who -- happily -- were the boy's parents.

[From a clipping from the Sydney Morning Herald, 14 Oct 1993, front page,
sent to RISKS by Cameron McLaren in Watson's Bay, Australia.  This item
provides a nice technology-related success story.  Little Arf Anony?]


Fiber Optic Cable "Meltdown" in Connecticut

<EMCULVER@delphi.com>
Wed, 20 Oct 1993 20:20:04 -0400 (EDT)
A couple of weeks ago a SNET (Local telco) fiber optic cable was found to have
been "melted" near where it crosses the Housatanic River.  This degraded
in-state long distance service and caused the 911 services in several towns,
possibly to the New York border (the paper never said) to fail.  My brother is
a network maven at a local bank.  He got some more information:

The papers reported the cable was "melted".  The cable was several feet under
ground; evidence of a campfire was reported.  Must have been one Hell of a
campfire!

The telco is certainly not telling all!


NII confidential report "on sale"

Martyn Thomas <mct@praxis.co.uk>
Thu, 21 Oct 1993 14:50:34 +0100 (BST)
The report on the Primary protection System for the UK Sizewell B nuclear
reactor, from the Nuclear Installations Inspectorate to the Advisory Council
on the Safety of Nuclear Installations, is available for two pounds sterling
from Computer Weekly, a trade weekly. The report is classified "confidential
to members" but the newspaper is selling it "to promote well informed
discussion". The report has provoked some controversy in the UK since it was
leaked a few weeks ago, because it contains some surprises about the results
of the verification activities.

If you want to read a well-written, technical report on the design and
verification of a large, real-world safety-critical software system, send
your two pounds to Computer Weekly, Sizewell Report, Quadrant House, The
Quadrant, Sutton, Surrey SM2 5AS.

Then tell RISKS what you think.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel: +44-225-444700.   Email: mct@praxis.co.uk    Fax: +44-225-465205


US Has It Too (Re: Russian Doomsday Device, Kenney, RISKS-15.11)

Li Gong <gong@csl.sri.com>
Thu, 21 Oct 93 09:59:19 -0700
In RISKS-15.11, we saw reports (in NY Times, etc.) that Mr. Bruce Blair, a top
US nuclear expert, alleged that the Russians have a Doomsday Device, a
computerized system that could automatically launch nuclear strikes even when
the Russian leadship is all wiped out.  Not noted in RISKS (and also not noted
in the San Francisco Chronicle report I saw) are the following two important
points (I got these from The Manchester Guardian Weekly, Oct.17, 1993, p.6):

(1) Blair wrote this in a book, "The Logic of Accidental Nuclear War".

(2) He also pointed out that the US has things quite similar.  For example,
the Trident submarines commanders can launch a nuclear strike even when they
have lost contact with the US and if they *believe* a nuclear conflict has
started.

Someone with access to the book could give us a more complete picture?

Li GONG     Email: gong@csl.sri.com   Tel: 415-859-3232  Fax: 415-859-2844
SRI International, Computer Science Lab, Menlo Park, California 94025, USA


Media Explosion => Loss of Community ?

F.Baube[tm] <flb@flb.optiplan.fi>
Wed, 20 Oct 93 23:11:41 EET
There has been concern expressed that when we all stop consuming the same mass
media, our shared sense of reality will unravel, with a RISK of bad
consequences for social cohesion in general.

That's one way of looking at it.

But consider also that if the technological revolution succeeds in remaking
the very nature of the media, from one-way mass transmissions to something
more like a community, however many "channels" it may be fragmented into, we
all stand to gain more than we lose.

I would like to cite a passage by Jean Baudrillard, critiquing the send-only
nature of the mass media.  When you think of future media, don't think of home
banking and 500 channels of Home Shopping and Gomer Pyle USMC, don't even stop
to think of personalized morning newspapers, think of genuinely interactive
media where "viewers" (as we would now call them, for lack of a better term)
are aware of and can respond to each other -- every channel an encounter.


"The mass media are anti-mediatory and intransitive.  They fabricate
non-communication -- this is what characterizes them, if one agrees to define
communication as an exchange, as a reciprocal space of speech and a response,
and thus of a *responsibility* (not a psychological or moral responsibility,
but a personal, mutual correlation in exchange).  We must understand
communication as something other than the simple transmission-reception of a
message, whether or not the latter is considered reversible thru feedback.
Now, the totality of the existing architecture of the media founds itself on
the latter definition: they are always what prevents response, making all
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
processes of exchange impossible (except in the various forms of response
*simulation*, themselves integrated in the transmission process, thus leaving
the unilateral nature of the communication intact).  This is the real
abstraction of the media.  [from "Towards a Political Economy of the Sign"]

Fred Baube (tm), GU/MSFS/88 baube@optiplan.fi


Re: Auto rentals, law suits, and the risks

Jerry Leichter <leichter@lrw.com>
Tue, 19 Oct 93 23:26:26 EDT
RISKS recently included a discussion of the increasing use by car rental
agencies of computer queries of motor vehicle department databases in order
to deny car rentals to bad drivers.  At least one writer suggested that a law
to make any collectors of such data responsible for errors would help keep the
error rate under control.  It's easy to see this as (a) yet another item on
the list of databases that will go wrong because databases *always* go wrong;
(b) yet another risk and inconvenience that will be imposed on everyone by the
evil users of databases; (c) yet another thing that needs regulation.  But
it's not that simple.  Decisions about databases, from their creation to their
maintenance and use, are not purely technical decisions.  They are made in a
social and legal context, and are affected by a complex set of circumstances.
A "quick legal fix" is as unlikely to help as a "quick technical fix".

There's a background to the rental company decisions.  Many states have passed
laws that make the owner of a vehicle responsible for any damage done with
that vehicle.  This includes car rental companies.  If a car rental company in
New York rents a car to Joe Dangerous, and Joe hits Sid Sorry badly injuring
him, not only can Sid sue Joe - likely a pointless exercise, as Joe has no
assets so is "judgement proof" - but he can also sue the rental company.  It
makes no difference that the rental company knew nothing about Joe's past
driving record; they own the car, they can be held accountable.

In New York, about a year or so ago, after what they claimed were large
losses, several of the larger companies announced very large surcharges on
cars rented at airports to drivers who lived in certain zipcodes.  Needless to
say, the zipcodes involved are populated largely by poorer, often minority,
residents.

Remember that in judging the risk associated with an action, one must also
consider the available alternatives.  Screening based on actual driving
records, errors and all, is a HUGE improvement.  It's quite true that the
relatively well-to-do, probably mainly white, readers of RISKS have much more
chance of being denied a rental car due to an error in the records in the new
system than they did under the older system, which in effect spread the errors
uniformly over a less vocal population - or at least a population we are
unlikely to hear much from on this list.  Still, it seems like a much better
trade-off from a social policy point of view.

Finally, on the matter of using lawsuits to curb actions we don't like: This
whole mess is an illustration of the complexities.  Actions have consequences,
often undesirable ones.  It's almost impossible for someone under 25 to rent a
car in the US today: They are considered uninsurable at any acceptable rate by
the rental companies.  The surcharges effectively locked out the poor.
Checking of driver's records theoretically locks out those who are really bad
drivers - but the criteria used are arbitrary.  Two moving violations in the
last 3 years?  Sorry, no car for you.  If you make a business risky enough, it
will either vanish or simply become so expensive that it might as well have.

    -- Jerry


Dangers of anonymous remailers

<an32153@anon.penet.fi>
Thu, 21 Oct 1993 01:51:07 UTC
Recently, I asked for information on Usenet, but wanted to remain
anonymous, so I used an anonymous remailer to post.  Most people have
seen anonymous postings, and some people have probably replied to them.
What many people probably never think about is the following text at the
end of every post (that you will see at the end of my post):

> Due to the double-blind, any mail replies to this message will be anonymized,
> and an anonymous id will be allocated automatically. You have been warned.

This means that if Bill replies to my anonymous posting, it will go
through the remailer and become anonymized.  If Bill has sent an
anonymous message before, I will receive mail from him with his
(permanent) anonymous id.  If he puts in his signature at the end of his
mail (which I always do when replying to a stranger), he will be giving
me his anonymous id with his "real" id.  I can then save this
information in a database and cross-reference it with any anonymous
postings.

In fact, I have been doing just that.  I use the "Insidious Big Brother
Database" (bbdb) from within emacs, and it automatically inserts email
senders into my database, and marks all net-news headers from people in
my database.  I do this just because I'm curious, not malicious.  My
database is encrypted, so only I can read it.  I could be evil, though.

I could post flame-bait in newsgroups like alt.sexual.abuse.recovery,
save all the information from people that flame me, and then post the
cross-references to alt.rush.limbaugh.  Or I could do worse.

Be careful to whom you reply.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind, any mail replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin@anon.penet.fi.


Privacy Digests

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 19 Oct 93 08:54:12 PDT
Periodically I will remind you of TWO useful digests related to privacy, both
of which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in privacy
problems.  RISKS will continue to carry general discussions in which risks to
privacy are a concern.

* The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein.  He manages it as
  a rather selectively moderated digest, somewhat akin to RISKS; it spans the
  full range of both technological and non-technological privacy-related issues
  (with an emphasis on the former).  For information regarding the PRIVACY
  Forum, please send the exact line:

information privacy

  as the BODY of a message to "privacy-request@vortex.com"; you will receive
  a response from an automated listserv system.  To submit contributions,
  send to "privacy@vortex.com".

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
  run by Dennis G. Rears.  It is gatewayed to the USENET newsgroup
  comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
  forum, and was established to provide a forum for discussion on the
  effect of technology on privacy.  All too often technology is way ahead of
  the law and society as it presents us with new devices and applications.
  Technology can enhance and detract from privacy.  Submissions should go to
  comp-privacy@pica.army.mil and administrative requests to
  comp-privacy-request@pica.army.mil.

There is clearly much potential for overlap between the two digests, although
contributions tend not to appear in both places.  If you are very short of time
and can scan only one, you might want to try the former.  If you are interested
in ongoing detailed discussions, try the latter.  Otherwise, it may well be
appropriate for you to read both, depending on the strength of your interests
and time available.
                        PGN


CERT reports and system breakins

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 21 Oct 93 15:38:02 PDT
The CERT Advisory that follows my message is serious stuff.  I tend not to run
CERT postings in RISKS, for many of a variety of reasons (e.g., their
already-wide distribution, or narrow focus, or sensitivity), but this one
seemed particularly relevant to the bigger picture, which is that system and
network security stinks in most systems, particularly those on the Internet.
Numerous sites have been increasingly experiencing breakins.  In addition to
the problems described in the CERT Advisory, many systems have recently had
passwords captured from outside intruders using promiscuous-mode Ethernet
tapping.  This has resulted in the compromise of both incoming and outgoing
passwords used for FTPs and TELNETs, for example.  Some of these passwords
have even been posted for use by others.  It is long past high time for system
vendors and system administrators to get serious about system/network
security.  Perhaps the CERT message will serve as yet another reminder,
although I have little confidence in things improving very rapidly.  PGN]


CERT Advisory - SunOS and Solaris vulnerabilities

CERT Advisory <cert-advisory-request@cert.org>
Thu, 21 Oct 93 13:50:31 EDT
CA-93:15                         CERT Advisory
                               October 21, 1993
            /usr/lib/sendmail, /bin/tar, and /dev/audio Vulnerabilities

The CERT Coordination Center has learned of several vulnerabilities
affecting Sun Microsystems, Inc. (Sun) operating systems. Three
separate vulnerabilities are described in this advisory.  The first
and third vulnerabilities affect all versions of SunOS 4.1.x and all
versions of Solaris 2.x.  The second affects all systems running any
version of Solaris 2.x (but does not affect SunOS 4.1.x systems).

Patches can be obtained from local Sun Answer Centers worldwide as
well as through anonymous FTP from the ftp.uu.net (192.48.96.9) system
in the /systems/sun/sun-dist directory.  In Europe, these patches are
available from ftp.eu.net in the /sun/fixes directory.

Information concerning specific patches is outlined below. Please note
that Sun sometimes updates patch files.  If you find that the checksum
is different, please contact Sun.

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

I.   /usr/lib/sendmail Vulnerability

     This vulnerability affects all versions of SunOS 4.1.x including
     4.1.1, 4.1.2, 4.1.3, 4.1.3c, and all versions of Solaris 2.x
     including Solaris 2.1 (SunOS 5.1) and Solaris 2.2 (SunOS 5.2).
     Sun is preparing a version of this patch for Solaris 2.3 but no
     patch ID is available at this time.

     ** This vulnerability is being actively exploited and we strongly
        recommend that sites take immediate and corrective action. **

     A. Description

        A vulnerability exists in /usr/lib/sendmail such that remote
        users may gain access to affected systems.

     B. Impact

        Unauthorized access to affected systems may occur.

     C. Solution

        1.  Obtain and install the appropriate patch following the
            instructions included with the patch.

        System       Patch ID   Filename         BSD         Solaris
                                                 Checksum    Checksum
        ------       --------   ---------------  ---------   -----------
        SunOS 4.1.x  100377-07  100377-07.tar.Z  36122  586  11735 1171
        Solaris 2.1  100840-03  100840-03.tar.Z  01153  194  39753  388
        Solaris 2.2  101077-03  101077-03.tar.Z  49343  177  63311  353

        The checksums shown above are from the BSD-based checksum
        (on 4.1.x, /bin/sum; on Solaris, /usr/ucb/sum) and from the SVR4
        version that Sun has released with Solaris (/usr/bin/sum).


II.  Solaris 2.x /bin/tar Vulnerability

     This vulnerability exists in all versions of Solaris 2.x including
     Solaris 2.1 and Solaris 2.2.  Information about patches for current
     versions of Solaris is described below.  Sun is preparing a patch
     for the upcoming Solaris 2.3 release. The patch ID will be 101327-01,
     and it will be available as soon as Solaris 2.3 is shipped.

     This vulnerability does not exist in SunOS 4.1.x systems.

     A. Description

        A security vulnerability exists in /bin/tar such that tarfiles
        created using this utility may incorporate portions of the
        /etc/passwd file.

     B. Impact

        Usernames and other information from /etc/passwd and /etc/group
        may be disclosed. However, since Solaris 2.x uses shadow passwords,
        encrypted passwords should not appear in /etc/passwd and therefore
        should not be disclosed by this vulnerability.

     C. Solution

        We recommend that all affected sites take the following steps
        to secure their systems.

        1.  Obtain and install the appropriate patch following the
            instructions included with the patch.

        System       Patch ID   Filename         BSD         Solaris
                                                 Checksum    Checksum
        ------       --------   ---------------  ---------   -----------
        Solaris 2.1  100975-02  100975-02.tar.Z  37034 374   13460  747
        Solaris 2.2  101301-01  101301-01.tar.Z  22089 390    4703  779

        The checksums shown above are from the BSD-based checksum
        (on 4.1.x, /bin/sum; on Solaris, /usr/ucb/sum) and from the SVR4
        version that Sun has released with Solaris 2.x (/usr/bin/sum).

        2.  If your site is not using shadow passwords, we recommend
            that all passwords be changed, especially those for
            sensitive accounts such as root.

        3.  Depending upon the sensitivity of the information contained
            in the /etc/passwd file, sites may wish to replace existing
            tar files where this is possible.  Restoring an existing
            archive file, and then producing a new tarfile with the
            patched tar, will result in a clean archive file.


III. /dev/audio Vulnerability

     This vulnerability affects all Sun systems with microphones. This
     includes all versions of SunOS 4.1.x including 4.1.1, 4.1.2, 4.1.3,
     4.1.3c, and all versions of Solaris 2.x including Solaris 2.1
     (SunOS 5.1) and Solaris 2.2 (SunOS 5.2).  Sun is addressing this
     problem in Solaris 2.3.

     A. Description

        /dev/audio is set to a default mode of 666. There is also no
        indication to the user of the system that the microphone is on.

     B. Impact

        Any user with access to the system can eavesdrop on conversations
        held in the vicinity of the microphone.

     C. Solution

        To prevent unauthorized listening with the microphone, the
        permissions of the audio data device (/dev/audio) should allow
        only the user logged in on the console of the machine to read
        /dev/audio. To prevent unauthorized changes in playback and record
        settings, the permissions on /dev/audioctl should be similarly
        changed.

        *** Any site seriously concerned about the security risks
        associated with the microphone should either switch off the
        microphone, or unplug the microphone to prevent unauthorized
        listening. ***

        1. Restricting access on 4.x systems

        Use fbtab(5) to restrict the access to these devices. See the
        man page for more information about this procedure.

        2. Restricting access on Solaris 2.x systems

        To restrict access to these devices to a specific users, the
        permissions on the device files must be manually changed.

        As root:

        # chmod 600 /dev/audio
        # chown 

                    
    

Please report problems with the web pages to the maintainer

Top