cops and robbers-unix system security.txt

1000 HOWTOs for various needs [WINDOWS]

                     February 19, 1991





                           - 6 -


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  impossi-
bility  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:

Aho, Kernighan, and Weinberger 88

Baldwin 87

Fiedler and Hunter 86

Grampp and Morris 84

Wood and Kochran 86


     Of course with all of the problems listed below,  look-
ing  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:

     1)  COPS Checks "vital" system directories  to  see  if
they are world-writable.  Directories listed as critical are
in a configuration file and are initially:

/ /etc /usr

/bin /Mail /usr/spool

/usr/adm /usr/etc /usr/lib

/usr/bin /usr/etc /usr/spool/mail

/usr/spool/uucp /usr/spool/at

     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 writ-
able.  The program that performs this task is dir.chk

     2)  Check "vital" system  files  to  see  if  they  are
world-writable.   Files  listed  as critical are in a confi-
guration file (file.chklst) and are initially:



                     February 19, 1991





                           - 7 -


/.*

/etc/*

/bin/*

/usr/etc/yp*

/usr/lib/crontab /usr/lib/aliases /usr/lib/sendmail


The wildcards are used like in UNIX, so these would  include
(some of the more important files):

/.login /.profile /.cshrc /.crontab /.rhost

/etc/passwd /etc/group /etc/inittab /etc/rc

/etc/rc.local /etc/rc.boot /etc/hosts.equiv /etc/profile

/etc/syslog.conf /etc/export

As well as the executable command files (among others):

sh,csh, and ls.


     Method -- again read through a configuration file list-
ing  all  of the files to be checked, comparing each in turn
with a write mask.  The program that performs this  task  is
file.chk

     3)  Check "vital" system  files  to  see  if  they  are
world-readable,  plus  check  for  a NFS file system with no
restriction.  These critical files are:

/dev/kmem /dev/mem

All file systems found in /etc/fstab

Plus a small number of user selectable  files  --  initially
set to include /.netrc, /usr/adm/sulog, and /etc/btmp.

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 dev.chk

     4)  Check all files in system for SUID status,  notify-
ing the COPS user of any changes in SUID status.

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



                     February 19, 1991





                           - 8 -


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 suid.chk and was written by Pren-
tiss Riddle.

     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.

Method -- Read through password file, flag  any  differences
with  normal password file, as documented in "man 5 passwd".
Fortunately, the syntax of the password file  is  relatively
simple  and  rigid.  The  program that performs this task is
passwd.chk


     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.

Method -- Read through group file, flag any differences with
normal  group  file  as documented in "man 5 group".  Again,
the syntax of this file is fairly simple.  The program  that
performs this task is group.chk

     7)  Check passwords of users on system.

Method -- using  the  stock  "crypt"  command,  compare  the
encrypted password found in the /etc/passwd file against the
following (encrypted) guesses:

The login id (uid), information in the gecos field, and  all
single letter passwords.

The program that performs this  task  is  pass.chk  and  was
written  by  Craig  Leres  and  was modified by Seth Alford,
Roger Southwick, Steve Dum, and Rick Lindsley.

     8)  Check the root path,  umask,  and  if  root  is  in
/etc/ftpuser.

Method -- look inside the /.profile  and  /.cshrc  files  to
ensure  that  all  of  the  directories listed are not world
writable, that "." isn't anywhere in the path, and that  the
umask  is  not set to create world writable files.  The pro-
gram that performs this task is root.chk

     9)  Examine the commands in  /etc/rc*  to  ensure  that
none of the files or paths used are world-writable.

Method -- grep through the files  and  examine  any  strings
that  start  with  "/"  for  writability.   The program that



                     February 19, 1991





                           - 9 -


performs this task is rc.chk

     10)  Examine the commands in /usr/lib/crontab to ensure
that none of the files or paths used are world-writable.

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 "/"  for  writability.
The  program  that performs this task is cron.chk 11)  Check
all of the user home directories  to  ensure  they  are  not
world writable.

Method -- get all of the home directories using  the  system
call  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 home.chk
and it was written by John Owens.

     12) Check important user files in  user's  home  direc-
tories  to  ensure  they  are not world writable.  The files
checked (all in the individual users'  home  directory,  all
with the prefix "."):

rhost profile login cshrc kshrc tcshr crhost

netrc forward dbxinit distfile exrc emacsrc

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
user.chk

     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 U-Kuang (rhymes with "twang") 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 dis-
tribution.  For more information on this  fascinating  secu-
rity  checker,  see  kuang.man.ms  and [Baldwin 87].  I have
rewritten it in Bourne shell (it was in C-Shell) for further
portability.

     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



                     February 19, 1991





                           - 10 -


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.

     Design Notes:

     The programs that are described here were  designed  to
address the problems discussed above, but still be usable on
as many UNIX "flavors" 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  improve-
ments (that might not be too hard :-), suggestions, or other
security programs that you would like  to  see  get  further
distribution can be sent to:

     [e-mail]

     (That's me)

     or

     [e-mail]

     (Dr. Eugene Spafford)

     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.