v21i027: System ecurity analysis tool, Part05/05
Rich Salz
rsalz at bbn.com
Fri Mar 23 04:59:24 AEST 1990
Submitted-by: Dan Farmer <df at sei.cmu.edu>
Posting-number: Volume 21, Issue 27
Archive-name: cops/part05
# 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/docs/pass
# cops/docs/passwd
# cops/docs/rc
# cops/docs/release.notes
# cops/docs/root
# cops/docs/suid.man
# cops/docs/tilde
# cops/docs/user
# cops/docs/warnings
# This archive created: Tue Jan 30 23:27:14 1990
# By: dan (Purdue University)
echo shar: extracting cops/docs/pass '(1289 characters)'
cat << \SHAR_EOF > cops/docs/pass
.TH PASS.CHK 1 "December 31, 1989"
.UC 4
.SH NAME
pass.chk \- Checks critical files for writability.
.SH SYNOPSIS
.B pass.chk
[
options
]
.SH DESCRIPTION
By default
.I pass.chk
only checks for accounts with passwords the same
as the login name. The following options add more extensive checking. (The
tradeoff is cpu time -- with all options enabled it can run into the 100's
of MINUTES.) Any argument that does not begin with a "-" is assumed to be
a file name. (A single '-' means stdin.) If no file name is given, /etc/passwd
is used.
.PP
Options are:
.TP
.B \-v
verbose -- list all guesses on stdout
.TP
.B \-u
output the username on the line of the password file
currently being checked. If the program stops
abruptly you will then know how far it got.
.TP
.B \-w file
use the list of words contained in "file" as likely
passwords. Words in the file are one to a line.
.TP
.B \-b
check all guesses backwards too
.TP
.B \-g
use the Full Name portion of the gecos field to
generate more guesses
.TP
.B \-s
check the single letters a-z, A-Z, 0-9 as passwords
.TP
.B \-c
with each guess, check for all lower case and
all upper case versions too.
.TP
.B \-n
complain about null passwords (default is to keep quiet)
.TP
.B \-p
print the password when guessed
.SH FILES
.Ps
/etc/passwd
.Pe
SHAR_EOF
echo shar: extracting cops/docs/passwd '(781 characters)'
cat << \SHAR_EOF > cops/docs/passwd
.TH PASSWD.CHK 1 "December 31, 1989"
.UC 4
.SH NAME
passwd.chk \- Checks password file(s) for inconsistencies.
.SH SYNOPSIS
.B passwd.chk
.SH DESCRIPTION
.I passwd.chk
checks the password files -- /etc/passwd and yppasswd if yellow pages are being
used -- for incorrect number of fields, duplicate ids, non-alphanumeric
login names, nonnumeric user ids', users with uid = 0 and not root, blank lines,
accounts with no passwords, invalid login directories, and non-numeric password id's.
.SH FILES
.Ps
/etc/passwd
passwd.chk uses the process id as a temporary file name for the ypchecking.
.Pe
.SH "SEE ALSO"
.Ps
passwd(5)
.Pe
Awk part based on _password_ from _The AWK Programming Language_, page 78.
.SH BUGS
It doesn't use the exact syntax of yellow pages to check for errors.
SHAR_EOF
echo shar: extracting cops/docs/rc '(775 characters)'
cat << \SHAR_EOF > cops/docs/rc
.TH RC.CHK 1 "December 31, 1989"
.UC 4
.SH NAME
rc.chk \- Checks contents of /etc/rc* file(s) for potential danger.
.SH SYNOPSIS
.B rc.chk
.SH DESCRIPTION
.I rc.chk
This checks pathnames and files inside the shell script files /etc/rc*
(e.g. /etc/rc, /etc/rc.local, etc.) for writability.
It filters out all paths or files that have a /tmp, /dev/null,
or /dev/*ty, plus everything after a ">"; e.g. if crontab is writing
to a file it doesn't care.
.SH FILES
/etc/rc*
.SH BUGS
Awk runs out of room ("bails out") if too many files are found in the
/etc/rc* files.
.PP
Spurious messages can occur --
.I rc.chk
only uses a approximation of which files should be checked. Also,
Unless a file has a full pathname (i.e. begins with a "/", it will
not be checked for writability.
SHAR_EOF
echo shar: extracting cops/docs/release.notes '(3580 characters)'
cat << \SHAR_EOF > cops/docs/release.notes
Brief Info-Capsule of COPS programs and files (release 1.0):
-------------------------------------------------------------------------
Programs and some important files that are included in this release:
-------------------------------------------------------------------------
cops A driving shell script for most of the programs
below. It tosses output to /dev/null except
what it wants, and mails any pertinent output
to the users $SECURE_USER listed in the COPS file.
Usage: cops
suid.chk Checks the system for _changes_ in SUID status.
This is the one program that should be run as
superuser. You must first run a find on all
SUID programs from the / directory, and then use
that as a "stop file" (see man page below.)
suid.man Manual for COPS.suid
findsuid.stop The database originally set up with "find".
Usage: suid.chk
makefile A makefile for programs enclosed.
Type "make" to make 'em (see Makefile for more
information.)
chk_strings Checks for writable paths/files in a file.
Usage: chk_strings <file>
cron.chk Checks for writable paths/files in /usr/lib/crontab.
Usage: cron.chk
dev.chk Checks /dev/*mem and all devs listed by "/etc/fstab"
command for world read/writability (respectively.)
In addition, checks a small group of files for
non-world readability (/usr/adm/sulog, etc.)
Usage: dev.chk [-g]
(-g checks for group read/writability as well)
dir.chk Checks directories listed in "dirs.chklst"
for writability.
dir.chklst List of directories for above.
Usage: dir.chk [-g]
(-g checks for group writability as well)
file.chk Checks files listed in "files.chklst"
for writability.
file.chklst List of directories for above.
Usage: file.chk [-g]
(-g checks for group writability as well)
group.chk Checks /etc/group for non-unique groups, invalid
fields, non-numeric group ids, etc.
Usage: group.chk
home.chk.c Checks all users home-dirs listed in /etc/passwd
for bad modes (basically world write, strangeness).
Usage: home.chk
rc.chk Checks all commands and paths listed in /etc/rc*
for writability.
Usage: rc.chk
reconfig Changes the paths for the programs used in COPS.
Example: changes /bin/awk --> /usr/bin/awk
file.paths Data file for reconfig (created by reconfig.)
Usage: reconfig
is_readable Checks a file/directory and determines readability
status; returns a "0" if is readable, a "1"
otherwise.
Usage: is_readable [-g] filename
is_writable Checks a file/directory and determines writability
status; returns a "0" if is writable, a "1"
otherwise.
Usage: is_writable [-g] filename
kuang The U-Kuang expert system. Read the accompanying
instructions in kuang.man. It basically checks
to see if a given user (by default root) is
compromisible, given that certain rules are true
(i.e. /etc/passwd writable gives root access, etc.)
Usage: kuang
init_kuang Contains the targets for the kuang system.
passwd.chk Checks /etc/passwd for non-unique uids, invalid
fields, non-numeric user ids, etc.
Usage: passwd.chk
pass.chk Checks /etc/passwd for crummy passwords.
pass.words Data file for pass.chk; use "pass -w pass.words"
to use them. Defaults to checking for the users' id.
Usage: pass.chk [-flags]
user_chk.c Checks all users listed in /etc/passwd; looks at
.login/.cshrc/.rhosts/.profile, etc., for bad
modes (basically world write, strangeness).
Usage: user_chk
SHAR_EOF
echo shar: extracting cops/docs/root '(414 characters)'
cat << \SHAR_EOF > cops/docs/root
.TH ROOT.CHK 1 "December 31, 1989"
.UC 4
.SH NAME
root.chk \- Checks contents of root owned startup files as well as
a variety of miscellaneous potential dangers.
.SH SYNOPSIS
.B root.chk
.SH DESCRIPTION
.I root.chk
This checks the paths inside root's startup files for the current directory
being used as a valid path and for improper umask settings (world writable).
.SH FILES
.Ps
/.login
/.cshrc
/.profile
.Pe
SHAR_EOF
echo shar: extracting cops/docs/suid.man '(1065 characters)'
cat << \SHAR_EOF > cops/docs/suid.man
findsuid \- find changes in setuid and setgid files
.sp
SYNOPSIS
.sp
.ul
findsuid
.sp
DESCRIPTION
.PP
Findsuid is a shell script intended to be run periodically by
.ul
cron (8)
in order to spot changes in files with the suid or sgid bits set.
.PP
.ul
Findsuid
uses
.ul
find (1)
to search system directories for all files with the 4000 or 2000 permission
bits set. It then compares these files with the contents of a ``stop file''
containing
.ul
\*Qls -lga\*U
output for known setuid or setgid programs.
Any additions or changes to this list represent potential security
problems, so they are reported by mail to system administrators for further
investigation.
.sp
FILES
.sp
.nf
/usr/adm/findsuid.stop the ``stop file''
.fi
.sp
SEE ALSO
.sp
find(1), chmod(1), cron(8)
.sp
BUGS
.sp
The location of the stop file, the directories to be searched and the
names of users to be informed of changes are all defined by shell variables
in the source.
.PP
Keeping the stop files up to date with changes to all
the suid files on more than a couple of hosts is a royal pain!
SHAR_EOF
echo shar: extracting cops/docs/tilde '(230 characters)'
cat << \SHAR_EOF > cops/docs/tilde
.TH TILDE 1 "December 31, 1989"
.UC 4
.SH NAME
tilde \- returns a user's home directory.
.SH SYNOPSIS
.B tilde
user
.SH DESCRIPTION
This merely prints a user's home directory, or "Error" if not found.
Named for the Csh feature.
SHAR_EOF
echo shar: extracting cops/docs/user '(461 characters)'
cat << \SHAR_EOF > cops/docs/user
.TH USER.CHK 1 "December 31, 1989"
.UC 4
.SH NAME
user.chk \- Checks key files in user home directories for world writability.
.SH SYNOPSIS
.B user.chk
.SH DESCRIPTION
This checks the following files in all of the user home directories
(it calls getpwent() to get user directories) for world writability:
.Ps
.rhost .profile .login
.cshrc .bashrc .kshrc
.tcshrc .rhost .netrc
.forward .dbxinit .distfile
.exrc .emacsrc
.Pe
SHAR_EOF
echo shar: extracting cops/docs/warnings '(10292 characters)'
cat << \SHAR_EOF > cops/docs/warnings
This file contains a list of most of the security warnings that you
might see while using the COPS system. Not included here are messages
that you may receive from the Kuang system and the SUID checker. For
help on using those tools, read the appropriate documentation on each
of those ("kuang.doc and suid.doc".)
First, I'll define some arbitrary terms which I'll use when describing
any problems you may encounter, then I'll list the messages, what they may
mean, and how you can change your system to eliminate any danger posed.
Some almost identical warnings were eliminated from the list; however
most warnings should have an analogous entry that is very close syntactically
to it in this file. All messages in COPS are prepended by "Warning!";
this has been excluded here for brevity.
There may be more than one way to overcome any problem listed here. If
you are unsure about whether to change a problem, try looking at some of
the references listed at the end of the technical report (cops.report) for
more information on how an attacker may compromise your system. Some of
the more dangerous security holes include writable directories and key files
(such as /etc/passwd), root owned SUID files writable to world or that give
a root shell, null passwords, and writable files that are executed by root.
Don't take everything that COPS says as gospel! What may be a serious
security hole on one machine may not be on your own, and vice-versa.
However, the more you value the information on your machine, the more you
should be concerned about security.
Some terms I'll use:
xyz -- An arbitrary number. Usually a line number in a file.
foo_file -- stands for a file you might see in your warning message.
foo_file2 -- Same as "foo_file", stands for a different file than the
first (used when two filenames are needed in one message.)
foo_dir -- a typical directory.
Group file -- /etc/group or the yellow pages group. If the warning starts
with "Group", it is the former, "YGroup" is the latter.
foo_group -- either /etc/group or ygroup.
Password file -- /etc/passwd or the yellow pages password. If the warning
starts with "Password", it is the former, "YPassword" refers
to the latter.
foo_pass -- either /etc/passwd or ypasswd.
cron_file -- will be either /usr/cron or
/usr/spool/cron/crontabs/foo_file.
foo -- anything that doesn't fit above. Usually an arbitrary
name, or group name, or whatever.
bar -- As "foo", if more than one name is needed in one message.
foo_bar -- As "foo", if more than two names are needed in one message.
WARNING MESSAGES
-----------------
1)
foo_file is _World_ writable!
foo_file is group readable!
This simply means that a file is world writable; e.g. Anyone can modify
or delete this file. This can be especially bad if the file can (even
indirectly) give root access, such as the system password file, "/etc/passwd".
To fix, type:
chmod a-w foo_file
This removes write access for group "all/world".
2)
foo_file (in cron_file) is World writable!"
File foo_file (inside root executed file foo_file2) is _World_ writable!"
File foo_file (in /etc/rc*) is _World_ writable!"
Similar to the above messages, but potentially more serious. Files
in this group are being used by root, and either being utilized as input,
output, or for execution. Examine the file they are inside and see how
it is being used. Files being executed are the most dangerous because
if they are changed, the new file gets executed with root privileges. Input
files are next, because changing them can alter what the executing program
does and cause undesirable side affects. Even output files can be dangerous,
however, because they may be used as an output or even as a program file
later on.
To fix, either delete the reference to foo_file inside the
cron/rc*/foo_file2/whatever file, or type:
chmod a-w foo_file
to remove write access for group "all/world".
3)
Directory foo_dir is _World_ writable!
This simply means that a directory is world writable; e.g. Anyone can
delete this directory, as well as mess with the files and subdirectories
inside of it. For instance, if /usr/spool is world writable, even if cron
is not writable, this is a problem, because the cron directory can be
replaced and new crontab files put in (which all run with root privileges.)
As a general rule, if you wish to have a file or directory secure, all
directories that are parent directories must be secure.
To fix, type:
chmod a-w foo_dir
This removes write access for group "all/world".
4)
Duplicate Group(s) found in foo_group:"
This means that one or more duplicate group names have been found.
This is mostly a system accounting problem; when adding or deleting names
from a group you will have problems.
To fix, remove all but one instance of each group in your /etc/group file.
5)
Group foo_bar has duplicate user(s):"
Similar to (4), a group has the same user listed more than once. If
all instances of the user is not deleted, they probably will remain with
their old privileges.
To fix, remove all but one instance of a user in each group of your
/etc/group file.
6)
Group file, line xyz, non-numeric group id: foo
Group id's must be numeric. Testing a non-numeric id will give
unpredictable results.
To fix, change the old id to a valid group id.
7)
Group file, line xyz, is blank
To fix, remove all blank lines.
8)
Group file, line xyz, does not have 4 fields: foo
More trouble. Testing of one or more of the groups will result
in invalid results, depending which is the missing field(s).
To fix, ensure group has four valid fields.
9)
Group file, line xyz, nonalphanumeric user id: foo
As (6).
To fix, change the old id to a valid group id.
10)
Group file, line xyz, group has password: foo
To fix, change the old password to an asterisk ("*").
11)
Password Problem: Guessed: foo shell: bar passwd: foo_bar
If an account has a guessed password, it is susceptible to other password
guessing programs (the one in COPS is rather crude and slow). Obviously, if
the password is known, the account is compromised.
To fix, either have the user change her/his password or change it yourself.
12)
Password Problem: null passwd: foo shell: bar
Password file, line xyz, no password: foo
If an account has no password, anyone can log into the account at will.
To fix, either have the user change her/his password or change it yourself.
13)
Duplicate uid(s) found in foo_passwd:"
This is a problem, especially if the accounts have different permissions
or privileges. When the user's account is deleted, one or more accounts may
remain active.
To fix, simply delete all but one occurrence of the users account.
14)
Password file, line xyz, user foo has uid = 0 and is not root bar
Ideally, no one but root should have uid = 0. Anyone with uid=0 is
superuser, for all purposes. Occasionally, a maintenance account has
uid=0, or perhaps a small group of administrators. Be very careful!
To fix, change the uid from 0 to some other valid number. If the
account or person really needs root privileges, have them use the root
account so you can keep track of who is using root.
15)
Password file, line xyz, nonalphanumeric login: foo
Another maintenance problem. Someone's been messing with the password
file, or you have some bugs in your software that fools around with it.
To fix, delete or change the login to a valid login.
16)
Password file, line xyz, invalid login directory: foo
User foo's home directory bar is not a directory!
A user has a non-existent or invalid login directory listed in the password
file. Sometimes these are maintenance accounts, but it is discouraged.
Examine the account to see if it should really exist.
To fix, either delete the account or put in a valid login directory.
17)
Password file, line xyz, nonnumeric group id: foo
Password file, line xyz, nonnumeric user id: foo
A user has a invalid user or group id. Dangerous if, when checked, it
translates to invalid number (who knows what would happen), or worse yet, 0.
To fix, change the field to a legal, numeric value.
18)
Password file, line xyz, does not have 7 fields: foo
Dangerous, because when a program checks for a field value it will come
up with who knows what.
To fix, ensure all fields have legal values.
19)
Password file, line xyz, is blank
To fix, delete all blank lines.
20)
NFS file system foo exported with no restrictions.
Anyone can mount the file system. May or may not be a problem, but
look over closely, if you value ANY of the info on it!
To fix, put in a valid list of hosts that may mount it.
21)
Root's umask set to xyz
If root's umask is set incorrectly, any files that it creates will be
have bad permissions (e.g. world writable if 000, x00, or xy0).
To fix, put a "safe" value; 077 or whatever.
22)
"." is in roots path!
Trojan horses traditionally play upon having the current directory in
a users path. A bad user will put a trojan horse with a the same name as
a common system command ("ls" is a favorite) and place it in a location that
s/he thinks might be executed. When the trojan horse is executed, it will
not only execute the command, but will also either steal your account
privileges or have your account perform some action that they desire.
23)
User foo's home directory foo_dir is mode xyz!
If a user's home directory is writable, you have the same problems as (3),
except all of the user's files are in jeopardy this time.
To fix, type:
chmod a-w foo_dir
24)
User foo: .bar is mode xyz!
In this case, ".bar" stands for one of the user's initialization files,
such as .login, .profile, .exrc, ect. If the user's file is world writable,
then anyone can modify that file, and whenever the user logs in or executes
a command (such as "vi", when referring to ".exrc"), they will execute
whatever commands the bad girl/boy wants them to.
To fix, type:
chmod a-w foo_file
SHAR_EOF
# End of shell archive
exit 0
>From @medusa.cs.purdue.edu:df at cs.purdue.edu Wed Jan 31 00:01:51 1990
Received: from BBN.COM by pineapple.bbn.com id <AA01286 at pineapple.bbn.com>; Wed, 31 Jan 90 00:01:48 -0500
Received: from medusa.cs.purdue.edu by BBN.COM id aa22146; 30 Jan 90 23:57 EST
Received: by medusa.cs.purdue.edu (5.61/PURDUE_CS-1.2)
id <AA08905 at medusa.cs.purdue.edu>; Tue, 30 Jan 90 23:57:37 -0500
From: dan <df at cs.purdue.edu>
Message-Id: <9001310457.AA08905 at medusa.cs.purdue.edu>
Subject: COPS, note #2
To: Rich Salz <rsalz at BBN.COM>
Date: Tue, 30 Jan 90 23:57:34 EST
In-Reply-To: <8910021306.AA00139 at prune.bbn.com>; from "Rich Salz" at Oct 2, 89 9:06 am
X-Mailer: ELM [version 2.2 PL10]
Status: R
The shar files are in no special order, nor do they have to be
unpacked in any order. Since I don't know much 'bout shar, I put
in some mkdir's at the beginning of the shars so the directory
structure I wanted would be preserved. You may do with them what
you will....
-- dan
--
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.
More information about the Comp.sources.unix
mailing list