Subject: RISKS DIGEST 15.17

Subject: RISKS DIGEST 15.17
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Thursday 21 October 1993 Volume 15 : Issue 17

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

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

The RISKS Forum is a moderated digest discussing risks; comp.risks is its
USENET counterpart. Undigestifiers are available throughout the Internet,
but not from RISKS. Contributions should be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with appropriate, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive
problems, and other information to [email protected] (not automated).
BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
There are also alternative repositories, such as [email protected] .

If you are interested in receiving RISKS via fax, please send E-mail to
[email protected], phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for
information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR
GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone
PGN at +1 (415) 859-2375 if you cannot E-mail [email protected] .

ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Thu, 21 Oct 93 14:27:27 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: A chip, off the old block

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

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

Date: Wed, 20 Oct 1993 20:20:04 -0400 (EDT)
From: [email protected]
Subject: Fiber Optic Cable "Meltdown" in Connecticut

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!

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

Date: Thu, 21 Oct 1993 14:50:34 +0100 (BST)
From: Martyn Thomas <[email protected]>
Subject: NII confidential report "on sale"

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: [email protected] Fax: +44-225-465205

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

Date: Thu, 21 Oct 93 09:59:19 -0700
From: Li Gong <[email protected]>
Subject: US Has It Too (Re: Russian Doomsday Device, Kenney, RISKS-15.11)

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: [email protected] Tel: 415-859-3232 Fax: 415-859-2844
SRI International, Computer Science Lab, Menlo Park, California 94025, USA

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

Date: Wed, 20 Oct 93 23:11:41 EET
From: [email protected] (F.Baube[tm])
Subject: Media Explosion => Loss of Community ?

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 [email protected]

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

Date: Tue, 19 Oct 93 23:26:26 EDT
From: Jerry Leichter <[email protected]>
Subject: Re: Auto rentals, law suits, and the risks

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

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

Date: Thu, 21 Oct 1993 01:51:07 UTC
From: [email protected]
Subject: Dangers of anonymous remailers

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 [email protected].
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 [email protected].

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

Date: Tue, 19 Oct 93 08:54:12 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Privacy Digests

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 "[email protected]"; you will receive
a response from an automated listserv system. To submit contributions,
send to "[email protected]".

* 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
[email protected] and administrative requests to
[email protected].

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

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

Date: Thu, 21 Oct 93 15:38:02 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: CERT reports and system breakins

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]

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

Date: Thu, 21 Oct 93 13:50:31 EDT
From: CERT Advisory <[email protected]>
Subject: CERT Advisory - SunOS and Solaris vulnerabilities

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 <console user's username>.<desired group> /dev/audio
# chmod 600 /dev/audioctl
# chown <console user's username>.<desired group> /dev/audio

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The CERT Coordination Center wishes to thank Paul De Bra, Department
of Computing Science, Eindhoven University of Technology; David Slade of
Bellcore; and Mabry Tyson of SRI for reporting these vulnerabilities, and
Sun Microsystems, Inc. for their response to these problems.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: [email protected]
Telephone: 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).

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

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