v21i025: System ecurity analysis tool, Part03/05

[Rich Salz]

Submitted-by: Dan Farmer <df at sei.cmu.edu>
Posting-number: Volume 21, Issue 25
Archive-name: cops/part03

#	This is a shell archive.
#	Remove everything above and including the cut line.
#	Then run the rest of the file through sh.
#----cut here-----cut here-----cut here-----cut here----#
#!/bin/sh
mkdir cops 2>/dev/null
mkdir cops/docs 2>/dev/null
mkdir cops/src 2>/dev/null
mkdir cops/extensions 2>/dev/null
# shar:	Shell Archiver
#	Run the following text with /bin/sh to create:
#	cops/rc.chk
#	cops/reconfig
#	cops/root.chk
#	cops/stop.sample
#	cops/suid.chk
#	cops/docs/COPS.report
#	cops/docs/KUANG.README
#	cops/docs/SUID.README
# This archive created: Tue Jan 30 23:26:56 1990
# By:	dan (Purdue University)
echo shar: extracting cops/rc.chk '(1822 characters)'
cat << \SHAR_EOF > cops/rc.chk
#!/bin/sh
#
#  Usage: rc.chk
#
#  This checks pathnames and files inside the shell script files /etc/rc*
# for writability.
#
#  Mechanism:  The commands inside the files /etc/rc* are executed when
# the machine is booted.  This shell script greps for commands/paths that
# are of these forms:
#
#	/path/command			# or whatever
#		or
#	PATH=:/bin:/usr/bin:.		# or whatever
#		or
#	MYVAR=`/path/command`		# or whatever
#	
#  It then takes each potential problem-string and uses the program
# "is_writable" to determine if it is world writable.  All results are
# echoed to standard output.
#
AWK=/bin/awk
LS=/bin/ls
TEST=/bin/test
EGREP=/usr/bin/egrep
ECHO=/bin/echo
SORT=/usr/bin/sort


# CHANGE THIS LINE OR PUT IN FILE NAMES IF/AS NEEDED!
#    (for example: init_files="/etc/rc /etc/rc.local")
#
init_files=`$LS /etc/rc*`

#
#  This should get all paths in /etc/rc* files; at least two types here.
# First type starts with a "/", the second is either in the form :
#
#	PATH=:/bin:/usr/bin:.		# or whatever
# or
#	MYVAR=`/bin/echo "hello"`	# or whatever
#
#
#   Notice also I strip out any references to /tmp, /usr/tmp,
# /dev/*ty's, and /dev/null.
first_pass=`$AWK '{for (i=1;i<=NF;i++) if ((index($i,"/")) && ((first=substr($i,1,1)!=">"))&& first!="#" && first!="$" && (last=substr($i,length($i),1))!="\"") print $i}' $init_files | $EGREP -v "/dev/.*ty|/tmp|/usr/tmp|/dev/null" | $SORT -u`

all_files=`$ECHO $first_pass| $SORT | $UNIQ`

#  First, get the ones starting with "/":
#
#   DANGER!  DANGER!  DANGER Will Robinson! Awk runs out of room ("bails
# out") if too many files are here....
all_files=`$ECHO $first_pass|$AWK 'BEGIN{RS=FS}{if(substr($0,1,1)=="/")print $0}'`

for i in $all_files
	do
	if ./is_writable $i
		then
		$ECHO "Warning!  File $i (in /etc/rc*) is _World_ writable!"
	fi
	done

# end of script
SHAR_EOF
echo shar: extracting cops/reconfig '(4535 characters)'
cat << \SHAR_EOF > cops/reconfig
#! /bin/sh
#
#  Usage: reconfig
#
#   This replaces the program paths (e.g. /bin/awk) in COPS with an
# alternate path that is found in the file "file.paths".
#   All programs are renamed "name.old", and the new version replaces
# the original name.  It then uses sed to replace all occurances of
# the target strings.
#   Basically, the program looks through all directories listed in
# $all_dirs for the list of programs in $all_commands and when it finds
# them, puts them in a sed source file.  It then goes to all of the
# shell files COPS uses ($shell_scripts) and replaces all occurances of
# the variables found with the new value.  It goes through some
# contortions trying to look for test (it has to find test without
# using test), and does some other not so smart things, but it seems
# to get the job done.

# shell is always here, isn't it?
SH=/bin/sh

# need these later
TEST=
AWK=
SED=
STRINGS=
YPCAT=

#  Potential directories to find commands:
all_dirs='/bin /usr/bin /usr/ucb /usr/local/bin'

#   First things first; are test and echo built-in shell commands?
# Theory.  If test is executed correctly and not found in the path
# I set, then they should be built into the shell, right?
PATH=/bin:/usr/bin
for dir in $all_dirs
	do
	if test -f $dir/test
		then
		TEST=$dir/test
		break
	fi
	done
# if not set, then set to default
if test -z "$TEST"
	then
	TEST=test
	fi

for dir in $all_dirs
	do
	if $TEST -f $dir/echo
		then
		ECHO=$dir/echo
		break
	fi
	done

# if not set, then set to default
if $TEST -z "$ECHO"
	then
	ECHO=echo
	fi

# The sed filter file
location=./file.paths

#  Target shell scripts in question:
shell_scripts="makefile chk_strings cops dev.chk dir.chk file.chk cron.chk group.chk passwd.chk rc.chk root.chk suid.chk kuang init_kuang"

#  Target commands in question, sans those checked above:
all_commands='cc nroff mkdir awk sed sh cat chmod comm mv date egrep cp expr find grep ls mail rm sort uniq'
rest_of_them=' echo test'

#  make sure everything is here:
for i in $shell_scripts
	do
	if $TEST ! -s $i
		then
		$ECHO  ERROR -- Shell script $i not found!
		exit
	fi
done

#   This finds the paths to any program used in COPS, then prints out
# a sed filter to the file "file.paths" that is used by this shell
# script to change all occurances of that command in the COPS system.
#
#   For example, if sed is in /usr/bin, it will create a line that looks
# like this:
#
# s.AWK=*$.AWK=/usr/bin/sed.
#
#  This corresponds to the sed command substitute ("." is used as a
# delineator instead of "/" because the strings will be containing
# "/"'s) /usr/bin/sed in place of whatever was to the right of the
# equal sign.  This works because all commands are accessed by the
# variable "$XYZ", where "XYZ" corresponds to the lowercase command
# "xyz".  And, of course, all command variables are set at the top
# of each command file.
#

# First we need awk and sed if this shell script will work....
for dir in $all_dirs
	do
	if $TEST -f $dir/awk ; then
		AWK=$dir/awk
		fi
	if $TEST -f $dir/sed ; then
		SED=$dir/sed
		fi
	done
if $TEST -z "$AWK" ; then
	$ECHO "Cannot find awk; awk is needed to run this shell script"
	exit 1
	fi

if $TEST -z "$SED" ; then
	$ECHO "Cannot find sed; sed is needed to run this shell script"
	exit 1
	fi

# zero out the file, then put in the real locations...
$ECHO > $location

for command in $all_commands
	do
	found=false
	for dir in $all_dirs
		do
		# if find the command in one of the directories, print string
		if $TEST -f $dir/$command
			then
			# this converts to upper case
			upper=`$ECHO $command | $AWK 'BEGIN{upper="ABCDEFGHIJKLMNOPQRSTUVWXYZ";lower="abcdefghijklmnopqrstuvwxyz";} \
			{out = ""; for(i=1;i <= length($1);i++) {
				if((cpos = index(lower,c = substr($1,i,1))) > 0)
					c = substr(upper,cpos,1); \
				out = out c; \
				} printf("%s",out)}'`

		$ECHO "s-^$upper=.*\$-$upper=$dir/$command-" >> $location
			found=true
			break
			fi
		done
	if $TEST "$found" = "false"
		then
		$ECHO ERROR!  $command not found!  Change or delete command!
		exit
		fi
	done

$ECHO "s-^ECHO=.*\$-ECHO=$ECHO-" >> $location
$ECHO "s-^TEST=.*\$-TEST=$TEST-" >> $location

# almost forgot -- we need chmod, mv too:
for dir in $all_dirs
	do
	if $TEST -f $dir/mv ; then
		MV=$dir/mv
		fi
	if $TEST -f $dir/chmod ; then
		CHMOD=$dir/chmod
		fi
	done

for i in $shell_scripts
	do
	$ECHO "Changing paths in $i..."
	$SED -f $location $i > $i.new
	$MV $i $i.old
	$MV $i.new $i
	# finally, make sure everything is back to executable status
	$CHMOD 700 $i

done
SHAR_EOF
echo shar: extracting cops/root.chk '(3194 characters)'
cat << \SHAR_EOF > cops/root.chk
#!/bin/sh
#
#  Usage: root.chk
#
#  This shell script checks pathnames inside root's startup files for 
# writability, improper umask settings (world writable), non-root
# entries in /.rhosts, and to ensure that root is in /etc/ftpusers.
# Also check for a single "+" in /etc/hosts.equiv (world is trusted).
# Startup files are /.login /.cshrc /.profile
#
#  Mechanism:  These files contain paths and filenames that are stripped
# out using "grep".  These strings are then processed by the "is_writable"
# program to see if they are world writable.  Strings of the form:
#
#	path=(/bin /usr/bin .)
#		and
#	PATH=/bin:/usr/bin:.:
#
# are checked (using grep) to ensure that "." is not in the path.  All
# results are echoed to standard output. 
#  For umask stuff, simply grep for umask in startup files, and check
# umask value.  For /etc/ftpuser, simple grep to check if root is in
# the file.  For /etc/hosts.equiv, just check to see if "+" is alone
# on a line by awking it.
#
#
AWK=/bin/awk
SED=/bin/sed
TEST=/bin/test
ECHO=/bin/echo
GREP=/bin/grep
SORT=/usr/bin/sort
EXPR=/bin/expr

csh=/.cshrc
sh=/.profile
rhosts=/.rhosts
big_files="/.login /.cshrc /.profile"
ftp=/etc/ftpusers
equiv=/etc/hosts.equiv

# parse into separate paths:
for i in $big_files
	do
	if $TEST -s $i
		then
		./chk_strings $i

		# check for umask stuff (thanks to Bruce Spence):
		if umsk=`$GREP umask $i ` 2>/dev/null
			then
			mask=`$ECHO $umsk|$AWK '{if($2!=""){if(length($2)==1) print "00"$2; \
				else if (length($2)==2) print "0"$2; \
				else print $2} else print "000"}'`
#			perm=`$EXPR substr $mask 3 1`
			perm=`$ECHO $mask | $SED 's/[0-9][0-9]//'`
			if $TEST "$perm" -lt 2 -o "$perm" = 4
				then
				if $TEST "$umsk"
					then
					$ECHO "Warning!  Root's umask set to $umsk in $i"
					fi
				fi
			fi
		fi
	done

# check to see if root is in ftpusers file
if $TEST -s $ftp
	then
	if test ! `$GREP "root" $ftp`
		then
		$ECHO Warning!  $ftp exists and root is not in it
		fi
	fi

# check for a "+" in hosts.equiv.  Bad.  Bad dog.
if $TEST -f $equiv ; then
	$AWK '{if (NF==1 && $1=="+") printf("Warning!  A \"+\" entry in %s!\n", "'$equiv'")}' $equiv
	fi

# check for non-root entries in /.rhosts
#$AWK '{if ((NF==1&&!($1=="localhost" || $1=="root"))||(NR!=1&&$2!="root")) printf("Warning!  Non root entry in %s! %s\n", $rhosts, $0)}' $rhosts


# echo checking paths...
{
#
# Get the root paths from $csh.
if $TEST -f $csh; then
$GREP path $csh | $AWK '{split($0,p1,"="); \
for (i=1;i<=NF;i++) { \
	if (substr($i,1,1)=="/") { \
		if (substr($i,length($i),1)!=")"){ print $i} \
		else {print substr($i,1,length($i)-1)} \
		} \
	else if ($i ~ /^path/) {split($i,p2,"(");if (substr(p2[2],1,1)=="/") { \
		print p2[2]}}} \
	}'
fi

#
# Get the root paths from $sh.
if $TEST -f $sh; then
$GREP PATH $sh | $SED 's/\(PATH=.*\);.*/\1/' |
	$AWK -F= '{split($2,temp,":"); \
		for (i in temp) \
			if (temp[i] == "") print "."; \
			else print temp[i]}'
fi
} |
 $SORT -u |
  while read i
  do
	# check to see if "." is in path
	if $TEST "." = "$i"
	then
		$ECHO "Warning!  \".\" is in roots path!"
	fi

	if ./is_writable $i
	then
		$ECHO "Warning!  Directory $i is _World_ writable!"
	fi
  done

# end of script
SHAR_EOF
echo shar: extracting cops/stop.sample '(644 characters)'
cat << \SHAR_EOF > cops/stop.sample
-rwsr-xr-x  1 root     bin         10240 Jun 13 13:13 /bin/chgrp
-rwsr-xr-x  1 root     bin         12288 Jun 13 13:13 /bin/df
-rws--s---  1 root     term        22528 Aug 13 13:13 /bin/login
-rws------  1 root     bin         21504 Jun 13 13:13 /bin/login.old
-rwsr-xr-x  1 root     bin         22528 Jun 13 13:13 /bin/mail
-rwsr-xr-x  1 root     bin         14336 Jun 13 13:13 /bin/passwd
-rwxr-sr-x  1 root     MEM         22528 Jun 13 13:13 /bin/ps
-rwsr-xr-x  1 root     bin         16384 Jun 13 13:13 /bin/su
-rwxr-sr-x  1 root     MEM         14336 Jun 13 13:13 /etc/dmesg
-rwsr-x---  1 root     operator    29696 Jun 13 13:13 /etc/dump
SHAR_EOF
echo shar: extracting cops/suid.chk '(2063 characters)'
cat << \SHAR_EOF > cops/suid.chk
#!/bin/sh
#
#   Shell script intended to be run periodically by cron in order
#   to spot changes in files with the suid or sgid bits set.
#
#	suid.chk	840919		Prentiss Riddle
#
#     This changes into the $SECURE directory first, then 
#   uses find(1) to search the directories in $SEARCH for all
#   files with the 4000 or 2000 permission bits set.  $STOP is a file
#   containing "ls -lga" output for known setuid or setgid programs.
#   Any additions or changes to this list represent potential security
#   problems, so they are reported to the users named in $INFORM.
#
#  Modified 8/15/89, Dan Farmer:
#	Just changed the program/doc names and some of the temp
#  files to make it fit in with the rest of the programs....
#

#  CHANGE THIS LINE!
INFORM="foo at bar.edu"
#

TEST=/bin/test
ECHO=/bin/echo
SH=/bin/sh
LS=/bin/ls
CAT=/bin/cat
MAIL=/bin/mail
CHMOD=/bin/chmod
SORT=/usr/bin/sort
COMM=/usr/bin/comm
FIND=/usr/bin/find
RM=/bin/rm

SECURE=.
SEARCH=.
STOP=./stop.sample
TEMPOLD=./fsold$$
TEMPCUR=./fscur$$
TEMPNEW=./fsnew$$
TEMPGON=./fsgon$$
TEMPM=./fsm$$

umask 077
OLDCWD=`pwd`

if $TEST ! -d "$SECURE"
	then
	$ECHO "Error -- Security directory $SECURE doesn't exist"
	exit 1
fi

$CHMOD 700 $SECURE
cd $SECURE

# find the setuid programs and sort
$FIND $SEARCH \( -perm -4000 -o -perm -2000 \) -exec $LS -lga {} \; | \
	$SORT > $TEMPCUR
# compare with the sorted stop list
$SORT <$STOP >$TEMPOLD
$COMM -13 $TEMPOLD $TEMPCUR | $SORT +8 >$TEMPNEW
$COMM -23 $TEMPOLD $TEMPCUR | $SORT +8 >$TEMPGON
# report changes
if $TEST -s $TEMPNEW -o -s $TEMPGON; then
	HOSTNAME=`$SH -c "/bin/uname -n || /usr/bin/uuname -l || /bin/hostname" 2>&-`
	$ECHO '' >>$TEMPM
	if $TEST -s $TEMPNEW; then
		$ECHO 'These files are newly setuid/setgid:' >>$TEMPM
		$ECHO '' >>$TEMPM
		$CAT $TEMPNEW >>$TEMPM
		$ECHO '' >>$TEMPM
	fi
	if $TEST -s $TEMPGON; then
		$ECHO 'These files are no longer setuid/setgid:' >>$TEMPM
		$ECHO '' >>$TEMPM
		$CAT $TEMPGON >>$TEMPM
	fi
	$MAIL $INFORM <$TEMPM
	$RM -f $TEMPM
fi
$RM -f $TEMPOLD $TEMPCUR $TEMPNEW $TEMPGON

#  end it all....
exit 0
SHAR_EOF
echo shar: extracting cops/docs/COPS.report '(33839 characters)'
cat << \SHAR_EOF > cops/docs/COPS.report
.ps 12
.vs 12
.PH ````
.pn
.nr W 78
.ce 2
\fBCOPS and Robbers
UN*X System Security\fP
.sp
.sp
.PP
In the last few years, computer security has received a great deal
more attention than it has in the past.  Computerized break-ins and
criminal activity, once merely the product of the imagination of
science fiction writers,
has became a fairly common occurence in both commercial and academic
circles.  In this paper, I will go over the problems that face any
multiuser computing system, then discuss how these problems apply to UNIX\**
.FS
Although originally designed and developed by Ken Thompson and
Dennis Ritchie of AT&T, UNIX has grown far beyond its' original
design and now numerous companies market their own \*Qflavor\*U of
UNIX.  When I use the term UNIX in this paper, I don't mean merely
AT&T's version, but instead I mean the majority of the most popular
varieties, made by developers at Berkely, Sun, and a host of other
manufacturers.  I believe UNIX is still a trademark of Bell
Laboratories.
.FE
specifically, and finally present in detail a suite of programs that
were developed in an attempt to address some of the main problems
that could be solved via software.  UNIX, although considered to be
a fairly secure operating system ([Wood 88], [Duff 89], etc), has the
advantage of having many published works ([Grampp and Morris 84],
[Bishop 83], etc) on the problems that a computing site can have with
security, and in addition, on how a UNIX system administrator might
make his/her system more secure by monitoring various aspects of his/her
UNIX site.  This, combined with UNIX's popularity, make it an ideal
target for a software security system to operate on.
.PP
In this report I am not going to discuss specific ways of breaking
into a given UNIX machine (for a more detailed description on how to
compromise UNIX security, see either [Baldwin88], [Bishop83],
[Wood & Kochran 86], or [Grampp & Morris 84]) -- instead, I will
concentrate on how to improve and strengthen the potentially good
security of a generic UNIX system by means of a software toolkit
that examines the weaker areas of UNIX that are either traditionally
ignored (due to the time constraints or ignorance of the system
administrators) or are simply reoccurring problems that need to be
watched over.  In addition, this report is not meant for UNIX neophytes
-- although a great deal of proficiency is not needed to read
this report and use the programs described herein, a familiarity with
basic UNIX features -- the file system and file permission modes for
example -- and commands such as
.ul
awk, grep, sed
as well as a working knowledge of shell and C programming are necessary
to understand the internal workings of the security system described in
this paper.
.PP
Although there is no reasonable way that all security problems can be
solved (at least not with a software solution) on any arbitrary UNIX
system, administrators and system programs can be assisted by a software
security tool.  The Computer Oracle Password and Security system (COPS)
that will be described in this paper is just such a device.  The COPS
system is a collection of programs and shell scripts that attempt
to address as many of these problems as possible in an efficient,
portable, and above all in a reliable and safe way.  The main goal
of COPS is one of prevention; it tries to anticipate and eliminate
security problems by making sure people don't get a chance to
compromise security in the first place.  Alerting the
administrators of a potential intruder or that a virus has infected 
the system is beyond the scope of the present system, although with 
work with such capabilities could be added ([Bauer and Koblentz 88]
and [Duff 89].)
.PP
To understand the reason COPS might check any specific problem, a
look at computer security problems in general is in order.  The
problems listed below are not meant to be inclusive, but they are
indicative of the myriad types of dilemmas a typical computer multiuser
system might encounter:
.PP
1)  Administrators, system programmers, and computer operators.  The
very people that (should) worry the most about security are sometimes
the ones that are the
least concerned.  Carelessness is one of the main culprits; a mistake by a user
might cause little or no problem, but when someone with no
restrictions (or almost none) on their computer activity makes a mistake,
a security hole can result.  \*QI can trust my users\*U is a fine
statement to make -- but can you trust your users' friends?  How about
the users of computers that are networked to yours?
New software, systems, or procedures
can facilitate extra problems; a computing staff is often ill or
completely non-trained on new techniques and software.
Too often \*QRTFM\*U is the only training that they will ever receive.
Programs that are created for in-house use are often ill-documented and
not debugged thoroughly, and when users other than the author start to
use/abuse the program, problems can result.  Especially misunderstood,
even by experienced UNIX system programmers, is the SUID program or,
worse yet, the SUID shell script ([Bishop 83].)
When a user says that his/her password was forgotten (or any
other account/security related problem), what checks are made to verify
that the person is really the owner of that account?  Are users that are
security problems kept track of, so that repeated abuses of the system will
result in punitive action?  Does your site even have a security policy?
And of course, the last straw is that most system administrators simply
have too much other work to do than to constantly check
the system for potential security flaws -- let alone to double-check that
any work done by other system programmers has been done correctly.
These are the actions that often get left unsaid and undone.
.PP
A UNIX environment has no special defenses against this kind of
\*Qattack\*U.  Fortunately, a number of these potential problems (unless
catastrophic in scope) are not only correctable, but are
easy to detect with a software toolkit such as COPS.  Even the most
careful UNIX guru will periodically make a mistake; COPS has been
designed to aid in her/his never ending battle against the forces of
darkness.
.PP
2)  Physical security.  This is perhaps the most frustrating of all 
possible problems because it effects all computer systems and is often the
hardest to safeguard against.  Even if the software is secure, even if 
the system administrators are alert to potential problems, what happens 
if a user walks up to the root console and starts typing?  Does the night
janitorial staff let anyone into the machine room without proper 
identification? Who has access to the key that opens up the computing 
center?  Are terminals that are logged on left unguarded or unlocked?
Are passwords written on or near a users terminal or desk?
No software in the world can help
against human nature or carelessness.  Reiterating to your staff and users
that terminals should not be left alone or unguarded and that passwords
(especially root) should not be typed in front of unfriendly (and in
this case, _everyone_ is your enemy) eyes would be a good start.  A
simple analogy: since you would never give the keys to the company car
away, why on earth would you give away the keys to your computer, which
is certainly worth a hell of a lot more time and money (although it may
not get as good mileage on the interstate.)  Common sense goes a long
ways to help prevent this kind of risk.
.PP
3)  Authentication.  What is authentication?  All modern computing
systems that have capabilities for multiple users have a means of
identifying who is
using the computer at any given time.  A common means of identification
is by using a password; and since the inception of this idea, poor
passwords have been a perennial problem.  People have a tendency to
use their own name, or their social security number, or some other
common word, name, or phrase for a password.  The problem then arises
when an unauthorized user wants to access clandestine information,
he/she simply tries one of these simple passwords until a successful
match is found.
.PP
Other problems with authentication?  What computer hosts are
\*Qtrusted\*U and allow users to log in from other machines without 
any further authentication?  Are incorrect login attempts kept and/or
monitored so as to allow administrators to keep track of any unusual
activity?  What about \*QTrojan horses\*U -- programs that can steal
passwords and the privileges that a user owns -- is there a program or a
administrative method that detects a potential 'horse?
.PP
Fortunately UNIX systems again have some fairly good tools to aid in
this fight.  Although finding simple passwords is indeed a trivial
task, forcing the users on a system to use passwords that are harder to
guess is also
trivial, by either modifying the mechanism that gets/gives the password
to the user, and/or by having the system administrators run a simple
password detector periodically, and notifying users if their password is
deemed too obvious.  The
.ul
crypt
command, although proven to be insecure for a knowledgeable and
resourceful attacker ([Reed and Weinberger 84], [Baldwin 86]), does
offer an added shield against most unauthorized users.  Logs can be kept
of incorrect login attempts, but as with most security measures, to be
effective someone (usually the site administrator) must take the time to
examine the evidence.
.PP
4)  Bugs/Features.  Massive software designs (such as an operating system)
are usually the result of a team or of teams of developers working together.
It only takes one programmer to make a mistake, and it will almost always
happen.  \*QBack doors\*U that allow unauthorized entrances are sometimes
purposefully coded in -- for debugging, maintenance, or other reasons.
And there are always 
unexpected side effects when thousands of people using the system start
doing strange (stupid?) things.  The best kind of defense against this
is to report the problems to the developer as they are discovered, and
if possible, to also report a way to fix the problem.  Unfortunately,
in many cases the
source code is needed to make a bug fix, and especially in non-academic
areas, this is simply not available due to the prohibitive costs involved.
Combining this with the reluctance of a (usually) commercial developer
to admit any problems with their product, and the end result is a
security hole that will not be mended unless some kind of financial loss
or gain is at stake -- for the developer of the product, not yours!
.PP
5)  Ignorance.  Users who don't know or care can be a problem as well.
Even if
someone doesn't care about their own security, they can unwittingly
compromise the entire system -- especially if they are a user with
high privileges.  Administrators and system operators are not immune to
this either, but hopefully are better informed, or at least have access
to a means of combating this dysfunction.  It may also be due to apathy,
an unwillingness to learn a new system, a lack of time to explore all of
the features of a large system, or simply not enough computer savvy to
learn more about a very complex system, and no one willing to
teach it to the user.  This problem is much like illiteracy; it is a
never-ending battle that will never go completely away.  And while a 
software toolkit such as COPS can help combat this problem by calling
attention to neglected or misunderstood critical areas, by far and away
the best weapon against this is education.  An educated user will simply
not make as many mistakes; and while it may seem impractical to teach
_all_ users about (even) the fundamentals of computer security, think of
all the time and resources wasted tracking down the mistakes that keep
recurring time and time again.
.PP
6)  Unauthorized permissions or privileges.  Are users given _too much_
freedom?  Do new computer accounts have any default security at all, or
are the new users expected to know what to do to protect their programs,
data, and other files.  System files, programs, and data are sometimes
shipped with minimal or no protection when gotten straight from the
manufacturer; someone at the installation site must have enough
knowledge to \*Qtune\*U the system to be effective and safe.  Password,
memory, and log files especially should all be carefully monitored,
but unfortunately an experienced user can often still find out any information
they want with perseverance and a little luck.  This is
where a system such as COPS can really shine.  After a new system is
configured, some basic flaws can be uncovered with just a small amount
of effort.  New system problems that somehow slip through the cracks of
the site installers can be caught and modified before any serious
problems result.  The key here is to prevent your system users from
getting a denial of computer service that they need and deserve.  Service
could mean anything from CPU time, response time, file space, or any
other commodity that a computer has to offer.
.PP
7)  Crackers/Hackers/Evil twin brothers.  Not much is needed on this
subject, save to say that they are often not the main problem.
Professional evil-users are a rarity; often harmful acts are done 
by users who \*Qjust wanted to see what would happen\*U or had no idea
of the ramifications of their acts.  Someone who is truly experienced is 
very difficult to stop, and is certainly outside the realm of any
software security tool as discussed in this paper.  Fortunately, most
evil-doers are fairly inexperienced and ignorant, and when they make a
mistake, a watchful administrator can deal with a problem before it gets
out of hand.  Sometimes they can even reveal security problems that 
were previously undiscovered.  COPS can help here mostly by reducing an
attacker's options; the less holes to exploit, the better.
.PP
The COPS system attempts to help protect as many of the above
items as possible for a generic UNIX system.  In the proper UNIX spirit,
instead of having a large program that attempts to solve every possible
problem, it is composed of several small programs that each check one
or more potential UNIX security holes.
The COPS system uses a variety of these problems to see if there are any
cracks in a given UNIX security wall.  These methods correspond to some
of the problems discussed above; specifically to administrators, system
programmers, and computer operators; authentication; ignorance;
unauthorized permissions or privileges; and finally crackers/hackers/evil
twin brothers (numbers 1,3,5, and 6.)  It is very difficult, almost a
practical impossibility to give software assistance to problems in
physical security, and finally bugs or features that are present in a
given UNIX system are possible to detect, but are not covered in this
system (yet).  The design of most of the the programs were at least
described if not outlined from the following sources:
.sp
Aho, Kernighan, and Weinberger 88
.sp
Baldwin 87
.sp
Fiedler and Hunter 86
.sp
Grampp and Morris 84
.sp
Wood and Kochran 86
.sp
.PP
Of course with all of the problems listed below, looking at the actual
source code of the program is very instructive -- each numbered section
lists the corresponding program that is used to perform the check:
.PP
1)  COPS Checks \*Qvital\*U system directories to see if they are
world-writable.  Directories listed as critical are in a configuration
file and are initially:
.sp
/ /etc /usr
.sp
/bin /Mail /usr/spool
.sp
/usr/adm /usr/etc /usr/lib
.sp
/usr/bin /usr/etc /usr/spool/mail
.sp
/usr/spool/uucp /usr/spool/at
.PP
The method COPS uses to detect problems -- read through a configuration
file (dir.chklst) containing all of the potential danger spots, and
then simply comparing each directory modes with a bit mask to see if it
is world writable.  The program that performs this task is
.ul
dir.chk
.PP
2)  Check \*Qvital\*U system files to see if they are world-writable.
Files listed as critical are in a configuration file (file.chklst)
and are initially:
.sp
/.*
.sp
/etc/*
.sp
/bin/*
.sp
/usr/etc/yp*
.sp
/usr/lib/crontab /usr/lib/aliases /usr/lib/sendmail
.sp
.sp
The wildcards are used like in UNIX, so these would include (some of the
more important files):
.sp
/.login /.profile /.cshrc /.crontab /.rhost
.sp
/etc/passwd /etc/group /etc/inittab /etc/rc
.sp
/etc/rc.local /etc/rc.boot /etc/hosts.equiv /etc/profile
.sp
/etc/syslog.conf /etc/export
.sp
As well as the executable command files (among others):
.sp
.ul
sh, csh,
and
.ul
ls.
.sp
.PP
Method -- again read through a configuration file listing all of the
files to be checked, comparing each in turn with a write mask.  The
program that performs this task is
.ul
file.chk
.PP
3)  Check \*Qvital\*U system files to see if they are world-readable,
plus check for a NFS file system with no restriction.
These critical files are:
.sp
/dev/kmem /dev/mem
.sp
All file systems found in /etc/fstab
.sp
Plus a small number of user selectable files -- initially set to
include /.netrc, /usr/adm/sulog, and /etc/btmp.
.sp
Method -- checking each in turn against a read mask for their read status.
The file system names are read from /etc/fstab, the selectable files are
kept in a variable.  The program that
performs this task is
.ul
dev.chk
.PP
4)  Check all files in system for SUID status, notifying the COPS user
of any changes in SUID status.
.sp
Method -- Use the "find" command on the root directory (this must be
done by root to avoid missing any files unreadable but still dangerous.)
The previous run will create a file that can be checked against the
current run to keep track of changes in SUID status and any new SUID
files.  The program that performs this task is
.ul
suid.chk
and was written by Prentiss Riddle.
.PP
5)  Check the /etc/passwd file (and the yellow pages password database, if
applicable) for null passwords, improper # of fields, non-unique user-id's,
non-numeric group id's, blank lines, and non-alphanumeric user-id's.
.sp
Method -- Read through password file, flag any differences with
normal password file, as documented in \*Qman 5 passwd\*U.  Fortunately,
the syntax of the password file is relatively simple and rigid. The program
that performs this task is
.ul
passwd.chk
.sp
.PP
6)  Check the /etc/group file (and the yellow pages database, if
applicable) for groups with passwords, improper # of fields,
duplicate users in groups, blank lines, and non-unique group-id's.
.sp
Method -- Read through group file, flag any differences with
normal group file as documented in \*Qman 5 group\*U.  Again, the syntax
of this file is fairly simple.  The program that performs this task is
.ul
group.chk
.PP
7)  Check passwords of users on system.
.sp
Method -- using the stock \*Qcrypt\*U command, compare the encrypted
password found in the /etc/passwd file against the following
(encrypted) guesses:
.sp
The login id (uid), information in the gecos field, and all single
letter passwords.
.sp
The program that performs this task is
.ul
pass.chk
and was written by Craig Leres and was modified by Seth Alford,
Roger Southwick, Steve Dum, and Rick Lindsley.
.PP
8)  Check the root path, umask, and if root is in /etc/ftpuser.
.sp
Method -- look inside the /.profile and /.cshrc files to ensure that
all of the directories listed are not world writable, that \*Q.\*U
isn't anywhere in the path, and that the umask is not set to create
world writable files.  The program that performs this task is
.ul
root.chk
.PP
9)  Examine the commands in /etc/rc* to ensure that none of the
files or paths used are world-writable.
.sp
Method -- grep through the files and examine any strings that start with
\*Q/\*U for writability.  The program that performs this task is
.ul
rc.chk
.PP
10)  Examine the commands in /usr/lib/crontab to ensure that none of the
files or paths used are world-writable.
.sp
Method -- grep through the crontab file and examine any strings after
field five (first five are not files, but how crontab is to be
run) that start with \*Q/\*U for writability.  The program that performs
this task is
.ul
cron.chk
11)  Check all of the user home directories to ensure they are not
world writable.
.sp
Method -- get all of the home directories using the system call
.ul
getpwent()
and then for every home directory found, check the write permissions of
of the home directory against a bit mask.  The program that performs
this task is
.ul
home.chk
and it was written by John Owens.
.PP
12) Check important user files in user's home directories to ensure
they are not world writable.  The files checked (all in the individual
users' home directory, all with the prefix \*Q.\*U):
.sp
rhost profile login cshrc kshrc tcshr crhost
.sp
netrc forward dbxinit distfile exrc emacsrc
.sp
Method -- using the same system call as #10, determine user home
directory.  Then simply check all of the above files against a bit mask.
The program that performs this task is
.ul
user.chk
.PP
13) Given a goal to compromise, such as user root, and a list of user
and group id's that can be used in an attempt to achieve the goal, this
security tool will search through the system until it verifies that the
goal is compromisible or not.  The program that performs this tricky task
is part of the
.ul
U-Kuang
(rhymes with \*Qtwang\*U)
system.  Robert Baldwin was kind enough to allow me to include this
security checker (a fine security machine in it's own right)
within this distribution.  For more information on this fascinating
security checker, see kuang.man.ms and [Baldwin 87].  I have rewritten
it in Bourne shell (it was in C-Shell) for further portability.
.PP
None of programs listed above certain cover all of the possible areas
that can harm a system, but if run together they can aid an overworked
administrator to locate some of the potential trouble spots.  The COPS
system is not meant to be a panacea against all UNIX security woes,
but an administrator who examines the security toolbox programs and 
this research paper might reduce the danger of their UNIX system being
compromised -- and that's all any security tool can ever hope to do.
The COPS system could never replace a vigilant administration
staffed with knowledgeable people, but hopefully, as administrators look
into the package, more comprehensive programs will come into being,
covering more of the problems that will continue as the latest versions
of UNIX continue to grow.
.PP
Design Notes:
.PP
The programs that are described here were designed to address the
problems discussed above, but still be usable on as many UNIX
\*Qflavors\*U as possible.  Speed was sacrificed for
simplicity/portability; hopefully the tools here will either be
replaced or modified, as by no means are they the final word or
solution to _any_ of these problems; indeed, it is my hope that
after other programmers/administrators see this report, they will
create newer, better, and more general tools that can be
re-distributed periodically.  None of the programs need to be run by
root to be effective, with the exception of the SUID checker (to
ensure that all files are checked.) Some of the tools were written by
myself, the others were written by other programmers on the network
and (with their permission) presented here.  All of the programs in
this report are in the public domain, with the exception of Robert
Baldwin's U-Kuang system; they all exist solely to be used and
modified to fit your needs.  If they are re-distributed, please 
keep them in their original form unless it is clearly stated that
they were modified.  Any improvements (that might not be too hard :-),
suggestions, or other security programs that
you would like to see get further distribution can be sent to:
.PP
df at medusa.cs.purdue.edu
.PP
(That's me)
.PP
or
.PP
spaf at uther.cs.purdue.edu
.PP
(Dr. Eugene Spafford)
.PP
Note that the COPS system is still in an infancy
stage -- although it has been tested on a variety of computers at
Purdue, it has not undergone any serious trials.
.PP
Enhancements I envision include:
.sp
i) Improved speed and portability without sacrificing functionality
(pretty obvious, I guess....)
.sp
ii) A level of severity assigned to each warning; anything that could 
compromise root instantly (root having no password, for example) might
have a level 0 priority, while simply having a user with a writable home
directory might only be level 3.  This way the system could be run at
a certain threshold level, or simply have the set of warnings
prioritized for a less sophisticated administrator.
.sp
iii) Better handling of SUID programs.
The current program needs more work to be done on it to be run effectively
by most people; many will not be willing to put the time needed to go
through the list of SUID files by hand to decide if they are needed or
not.
Perhaps also an alarm would sound if a shell script is SUID; doubly so if
root owned.
.sp
iv) A CRC checker that would check a file system (possibly just the most
important programs (such as this :-)) and report if any of the
executable files were changed -- possibly signalling a viral infection.
.sp
v) The eradication of any design flaws or coding errors that are in
the COPS system.
.PP
The main purpose of creating the COPS system was twofold; the first was
to foster an understanding of the security problems common to most UNIX
systems, and the second was to try to create and apply software tools
that, when run, will inform system administrators of potential problems
present in their system.  No attempt is made by the tools to correct any
problems because a potential security problem at one site may be
standard policy/practice at another.  An emphasis on furthering
education and knowledge about UNIX in general is the key to good
security practices, not following blindly what an unintelligent tool
might say.
.PP
Some of the advantages to using a system such as COPS are:
.sp
i) Nearly Continuous monitoring of traditional problem areas.
.sp
ii) A new system can be checked before being put into production.
.sp
iii) New or inexperienced administrators can not only stop some of their
problems in security they may have, but can also raise their
consciousness about the potential for security dilemmas.
.PP
And a couple of disadvantages:
.sp
i) An administrator could get a false sense of security from running
these programs.  Caveat emptor (ok, they are free, but still beware.)
.sp
ii) A specific path to the elimination of the problem is not presented.
This could also be construed as an advantage, when considering the third
point.
.sp
iii) Badguys can get these tools.  You know -- the guys with black hats.
What happens when they get a copy of this package?  With any sensitive
subject like security, knowledge is zealously guarded.  People are
afraid that absolute knowledge corrupts -- who knows, they may be right.
But I staunchly stand by the tree of knowledge.  Let the bad guys taste
the fruit, and they may see the light, so to speak.  In addition, the
system does not say how to exploit the hole, just that it exists.
.PP
.ul
Results of Running COPS:
.PP
Not surprisingly, the results when COPS was run varied significantly
depending on what system and site it was run on.  Here at Purdue, it was
run on a Sequent Symmetry running DYNIX 3.0.12, on a pair of Suns (a
3/280 and 3/50) running UNIX 4.2 release 3.4, a VAX 11/780 running 4.3
BSD UNIX, a VAX 8600 running Ultrix 2.2, and finally a NeXT machine
running their 0.9 O/S version of UNIX.  The results of the COPS
system showed a reasonable amount of security concern on all of the
machines; the faculty only machines showed the weakest security, followed
by the machines used by the graduate students, and finally the undergraduate
machines had the strongest security (our administrators _know_ that you
can't trust those (us?) young folks.)  Whether this was showing that
Purdue has a good administration, or that the UNIX vendors have a fairly
good grasp on potential security problems, or if it was merely 
showcasing the shortcomings of this system wasn't clear to me from the
results.
.PP
The security results probably will vary significantly from machine to
machine -- this
is not a fault of UNIX; merely having the same machine and software
does not mean that two sites will not have completely different security
concerns.  In addition, different vendors and administrators have
significantly varying opinions on how a machine should be set up.  There
is no fundamental reason why any system cannot pass all or nearly all of
these tests, but what is standard policy at one sites may be an
unthinkable risk at another, depending upon the nature of the work being
done, the information stored on the computer, and the users of the
system.
.PP
When I first started researching this report, I thought it would be a
fairly easy task.  Go to a few computing sites, read some theoretical
papers, gather all the programs everyone had written, and write a
brief summary paper.  But what I found was an
tremendous lack of communication and concerted effort towards the
subject of security.  AT&T had written a couple of programs ([Kaplilow
and Cherepov 88], as had Hewlett Packard ([Spence 89]), but they were
proprietary.  I heard rumors that the
government was either working on or had such a security system, but they
certainly weren't going to give it to me.
The one book devoted to UNIX security ([Kochran and Wood 86]) was good,
but the programs that they presented were not expansive enough for what
I had in mind, plus the fact that they had written their programs
mostly based on System V.  And while most system administrators I talked
to had written at least a shell script or two that performed a minor
security task (SUID programs seemed the most popular), no one seemed to
exchange ideas or any
their problems with other sites -- possibly afraid that the admission of
a weakness in their site might be an invitation to disaster.  There is
an excellent security discussion group on the network ([Various Authors
84-]), from which I received some excellent ideas for this project, but
it is very restrictive to whom it allows to participate.  I hope that
with the release of this security system it will not only help stamp
out problems with UNIX security, but would encourage people to exchange
ideas, programs, problems and solutions to the computer community at large.

Dan Farmer
September 29, 1989
.PP
.ul
Acknowledgements:
I would like to thank Eugene Spafford for his invaluable help in
the researching, planning, and development of this project.  Without
the writings and programs created by Robert Morris, Matt Bishop, and
other capable UNIX programmers, this project could never have gotten
off the ground.  Thanks also go to Brian Kernighan, Dennis Ritchie,
Donald Knuth, and Ken Thompson, for such inspirational computer work.
And of course without Peg, none of this would have come into being.
Thanks again to all of you.
.bp
.ce
.ul
BIBLIOGRAPHY

.sp
_, UNIX Programmers Manual, 4.2 Berkeley Software Distribution,
Computer Science Division, Department of Electrical
Engineering and Computer Science University of California,
Berkeley, CA, August 1983.
.sp
_, DYNIX(R) V3.0.12 System Manuals, Sequent Computer Systems, Inc., 1984.
.sp
Aho, Alfred V., Brian W. Kernighan, and Peter J. Weinberger, The
AWK Programming Language, Addison-Wesley Publishing Company, 1988.
.sp
Authors, Various, UNIX Security Mailing List/Security Digest,
December 1984 -.
.sp
Baldwin, Robert W., Crypt Breakers Workbench, Usenet, October
1986.
.sp
Baldwin, Robert W., Rule Based Analysis of Computer Security,
Massachusetts Institute of Technology, June 1987.
.sp
Bauer, David S. and Michael E. Koblentz, NIDX - A Real-Time
Intrusion Detection Expert System, Proceedings of the Summer
1988 USENIX Conference, Summer, 1988.
.sp
Bishop, Matt, Security Problems with the UNIX Operating System,
Department of Computer Sciences, Purdue University, January
31, 1983.
.sp
Bishop, Matt, How to Write a Setuid Program, April 18, 1985.
.sp
Denning, Dorothy, Cryptography and Data Security, Addison-Wesley
Publishing Company, Inc, 1983.
.sp
Duff, Tom, Viral Attacks On UNIX System Security, Proceedings of
the Winter 1988 USENIX Conference, Winter, 1988.
.sp
Fiedler, David and Bruce Hunter, UNIX System Administration,
Hayden Book Company, 1986.
.sp
Grampp, F. T. and R. H. Morris, "UNIX Operating System Security,"
AT&T Bell Laboratories Technical Journal, October 1984.
.sp
Kaplilow, Sharon A. and Mikhail Cherepov, "Quest -- A Security
Auditing Tool," AT&T Bell Laboratories Technical Journal,
AT&T Bell Laboratories Technical Journal, May/June 1988.
.sp
Morris, Robert and Ken Thompson, "Password Security : A Case
History," Communications of the ACM, November 1979.
.sp
Reed, Brian, "Reflections on Some Recent Widespread Computer
Break-ins," Communications of the ACM, vol. Vol 30, No. 2,
February 1987.
.sp
Reed, J.A. and P.J. Weinberger, File Security and the UNIX System
Crypt Command, Vol 63, No. 8, AT&T Bell Laboratories
Technical Journal, October 1984.
.sp
Smith, Kirk, Tales of the Damned, UNIX Review, February 1988.
.sp
Spafford, Eugene H., The Internet Worm Program: An Analysis,
Purdue Technical Report CSD-TR-823, Nov 28, 1988.
.sp
Spafford, Eugene H., 1989.  Private Communications
.sp
Bruce Spence, spy: A UNIX File System Security Monitor, Workshop
Proceedings of the Large Installation Systems Administration III,
September, 1988.
.sp
Stoll, Clifford, Stalking the Wily Hacker, Volume 31, Number 5,
Communications of the ACM, May 1988.
.sp
Thompson, Ken, Reflections on Trusting Trust, Volume 27, Number
8, Communications of the ACM, August 1984.
.sp
Wood, Patrick and Stephen Kochran, UNIX System Security, Hayden
Books, 1986.
.sp
Wood, Patrick, A Loss of Innocence, UNIX Review, February 1988.
SHAR_EOF
echo shar: extracting cops/docs/KUANG.README '(886 characters)'
cat << \SHAR_EOF > cops/docs/KUANG.README

  The U-Kuang system is currently setup in a minimum configuration; e.g.
it assumes only that world modes/permissions are to be used.  To fully
use the system, if the password checkers and the home-directory checker
come back with any positive results (i.e. with an account that can be
broken), modify the init_kuang file to reflect this.
  To use this system to it's full capabilities, be sure to read the
manual, kuang.man.ms.

This directory contains the various programs and shell scripts
that make up the Kuang security checking system.

The file, kuang.man.1, documents the system in the style of a UNIX
manual page.  The file, kuang.mss, is a draft of a paper on
this system.


To run the system:

0. Execute 'make' to build the programs.
1. Read kuang.man.1
2. Modify the file, init_kuang, to set the initial set of privileges.
3. Execute "sh kuang" (or run the COPS system.)

SHAR_EOF
echo shar: extracting cops/docs/SUID.README '(501 characters)'
cat << \SHAR_EOF > cops/docs/SUID.README
Findsuid is a little utility we dreamt up to watch for potential Trojan horse
programs by keeping an eye on our suid and sgid files and telling us when
they change unexpectedly.

We run it using the following line in crontab:

	40 3 * * * /etc/findsuid/findsuid >/etc/findsuid/fserror 2>&1

Included here is the findsuid shell script, a man page, a makefile, and a
sample "stop" file.

--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- {ihnp4,harvard,seismo,gatech,ctvax}!ut-sally!riddle
SHAR_EOF
#	End of shell archive
exit 0

-- 
Please send comp.sources.unix-related mail to rsalz at uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.