riddle@ut-sally.UUCP (Prentiss Riddle) (01/16/85)
: This is a shar archive. Extract with sh, not csh.
echo x - README
sed -e 's/^X//' > README << '!RoNnIe!RaYgUn!'
XFindsuid is a little utility we dreamt up to watch for potential Trojan horse
Xprograms by keeping an eye on our suid and sgid files and telling us when
Xthey change unexpectedly.
X
XWe run it using the following line in crontab:
X
X 40 3 * * * /etc/findsuid/findsuid >/etc/findsuid/fserror 2>&1
X
XIncluded here is the findsuid shell script, a man page, a makefile, and a
Xsample "stop" file.
X
X--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
X--- {ihnp4,harvard,seismo,gatech,ctvax}!ut-sally!riddle
!RoNnIe!RaYgUn!
echo x - Makefile
sed -e 's/^X//' > Makefile << '!RoNnIe!RaYgUn!'
XFSLIB=/etc/findsuid
X
Xall:
X# Do nothing.
X
Xinstall:
X cp findsuid.sh ${FSLIB}/findsuid
X chmod 740 ${FSLIB}/findsuid
X
Xclean:
X# Do nothing.
!RoNnIe!RaYgUn!
echo x - findsuid.8
sed -e 's/^X//' > findsuid.8 << '!RoNnIe!RaYgUn!'
X.TH FINDSUID 8L "18 October 1984"
X.UC
X.SH NAME
Xfindsuid \- find changes in setuid and setgid files
X.SH SYNOPSIS
X.B findsuid
X.SH DESCRIPTION
X.I Findsuid
Xis a
Xshell script intended to be run periodically by
X.IR cron (8)
Xin order
Xto spot changes in files with the suid or sgid bits set.
X.PP
X.I Findsuid
Xuses
X.IR find (1)
Xto search system directories for all files with the 4000 or 2000 permission
Xbits set. It then compares these files with the contents of a ``stop file''
Xcontaining
X.B "ls -lga"
Xoutput for known setuid or setgid programs.
XAny additions or changes to this list represent potential security
Xproblems, so they are reported by mail to system administrators for further
Xinvestigation.
X.SH FILES
X.nf
X/etc/findsuid/stop the ``stop file''
X.fi
X.SH "SEE ALSO"
Xfind(1), chmod(1), cron(8)
X.SH BUGS
XThe location of the stop file, the directories to be searched and the
Xnames of users to be informed of changes are all defined by shell variables
Xin the source.
X.PP
XKeeping the stop files up to date with changes to all
Xthe suid files on more than a couple of hosts is a royal pain!
!RoNnIe!RaYgUn!
echo x - findsuid.sh
sed -e 's/^X//' > findsuid.sh << '!RoNnIe!RaYgUn!'
X#! /bin/sh
X#
X# findsuid 840919 Prentiss Riddle
X#
X# Shell script intended to be run periodically by cron in order
X# to spot changes in files with the suid or sgid bits set.
X#
X# Findsuid uses find(1) to search the directories in $SEARCH for all
X# files with the 4000 or 2000 permission bits set. $STOP is a file
X# containing "ls -lga" output for known setuid or setgid programs.
X# Any additions or changes to this list represent potential security
X# problems, so they are reported to the users named in $INFORM.
X#
XINFORM="findsuid"
XSEARCH="/"
XSTOP=/etc/findsuid/stop
XTEMPOLD=/tmp/fsold$$
XTEMPCUR=/tmp/fscur$$
XTEMPNEW=/tmp/fsnew$$
XTEMPM=/tmp/fsm$$
X
Xumask 077
X# find the setuid programs and sort
Xfind $SEARCH \( -perm -4000 -o -perm -2000 \) -exec ls -lga {} \; | \
X sort > $TEMPCUR
X# compare with the sorted stop list
Xsort <$STOP >$TEMPOLD
Xcomm -13 $TEMPOLD $TEMPCUR | sort +8 >$TEMPNEW
X# report changes
Xif test -s $TEMPNEW; then
X echo 'Subject: New setuid or setgid files found on '`hostname`'.' >$TEMPM
X echo '' >>$TEMPM
X echo 'The following files have their setuid or setgid bits' >>$TEMPM
X echo 'set and are not listed in '$STOP >>$TEMPM
X echo 'or have changed:' >>$TEMPM
X echo '' >>$TEMPM
X cat $TEMPNEW >>$TEMPM
X /bin/mail $INFORM <$TEMPM
X /bin/rm $TEMPM
Xfi
X/bin/rm $TEMPOLD $TEMPCUR $TEMPNEW
!RoNnIe!RaYgUn!
echo x - stop.sample
sed -e 's/^X//' > stop.sample << '!RoNnIe!RaYgUn!'
X-rwsr-xr-x 1 root bin 10240 Jun 13 13:13 /bin/chgrp
X-rwsr-xr-x 1 root bin 12288 Jun 13 13:13 /bin/df
X-rws--s--- 1 root term 22528 Aug 13 13:13 /bin/login
X-rws------ 1 root bin 21504 Jun 13 13:13 /bin/login.old
X-rwsr-xr-x 1 root bin 22528 Jun 13 13:13 /bin/mail
X-rwsr-xr-x 1 root bin 14336 Jun 13 13:13 /bin/passwd
X-rwxr-sr-x 1 root MEM 22528 Jun 13 13:13 /bin/ps
X-rwsr-xr-x 1 root bin 16384 Jun 13 13:13 /bin/su
X-rwxr-sr-x 1 root MEM 14336 Jun 13 13:13 /etc/dmesg
X-rwsr-x--- 1 root operator 29696 Jun 13 13:13 /etc/dump
!RoNnIe!RaYgUn!
exitdave@lsuc.UUCP (David Sherman) (01/24/85)
Of course, it's fine to have a "findsuid" program that runs from
crontab and informs you if there are setUID programs not in the
"stop" list, but anyone who can become root can do some obvious
things:
- patch the findsuid program with some subtle bug
(like introducing a non-printing char which will
make a test fail), so it silently stops being useful
- edit the stop list to include their own pet Trojan horses
(so you had better examine the stop list manually occasionally)
- modify any of the programs on the stop list so that when
called with a particular sequence, they give that person
a root shell.
Moral: once someone becomes root on a machine, if they really want
to keep the capability they can, unless you recompile all the system
source from a tape.
--
{utzoo pesnta nrcaero utcs}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsrgv!lsuc!daveemks@uokvax.UUCP (01/30/85)
Another problem with having a find-suid-programs program that runs based on crontab entries is that anyone can see when the find-suid-programs program is going to run next, and make their moves on that basis. Perhaps /usr/lib/crontab should be mode 600... But then one could always check the last access time of the program, or look up the per-proc accounting. kurt
mike@enmasse.UUCP (Mike Schloss) (02/02/85)
> Another problem with having a find-suid-programs program that runs based > on crontab entries is that anyone can see when the find-suid-programs > program is going to run next, and make their moves on that basis. > > kurt But what are they going to do about it. I suppose that if they knew the order in which file systems were traversed they might be able to move their program to a safe area and back again when all clear but this seems a little drastic. Easier to just modify an existing suid-root program (like su) to grant a specific user or password root access. CACM had an interesting article on this stuff a while back... It amounted to this, once root has been comprimised just once, the whole system is suspect unless everything is rebuilt from scratch, from the distribution tape.
jsq@ut-sally.UUCP (John Quarterman) (02/04/85)
Sure, if someone with root privileges is knowledgeable enough,
you'd have to fumigate your disks to get rid of them, and that
might not even work (see Thompson's Turing award paper in CACM).
What we use findsuid for is to catch clumsy crackers, and also
to find uses of non-root suid programs where groups would be better.
--
John Quarterman, CS Dept., University of Texas, Austin, Texas 78712 USA
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqjab@uokvax.UUCP (02/04/85)
/***** uokvax:net.unix-wizar / emks / 3:45 pm Jan 29, 1985 */ Another problem with having a find-suid-programs program that runs based on crontab entries is that anyone can see when the find-suid-programs program is going to run next, and make their moves on that basis. Perhaps /usr/lib/crontab should be mode 600... But then one could always check the last access time of the program, or look up the per-proc accounting. /* ---------- */ There is a good argument for locking the "per process accounting" records, since it was NONE OF YOUR BUSINESS what programs I run. Any findsuid program needs to notice the MODIFICATION time of any of the "permitted" files and report recently-changed binaries. There might also be a good argument for disallowing setuid/setgid (for system ids) files on non-system disks: this is a quick HACK to exec(2). (Please don't flame the above suggestion as "non-portable": of course it's not portable, but you change YOUR copy of the system to meet YOUR needs.) Jeff Bowles Lisle, IL
sean@ukma.UUCP (Sean Casey) (02/05/85)
> Another problem with having a find-suid-programs program that runs based > on crontab entries is that anyone can see when the find-suid-programs > program is going to run next, and make their moves on that basis. > > kurt I do not think that findsuid is designed to be a serious security program. It is a nice little watchdog that will trap a novice that happens to find a bug (there's lots) and creates his own su (or similar), but it's extremely simple, and easy to bypass. A friend of mine wrote an interesting security program for Tops- 10. It locked itself in core and set up breakpoints at some of the monitor calls. It then checked the parameters on these calls and made sure they were "ok". It entwined itself to the monitor so tightly that it was almost impossible to defuse without taking down the whole monitor with it. It checked for a number of things and logged (in an undeletable file!) conditions which it considered unusual. If I were to go about writing a serious security program for Unix, I'd probably go about it much the same way. I would make the process as unkillable as possible, and have it periodically check things. 'nuff ramblin' Sean Casey
emks@uokvax.UUCP (02/08/85)
/***** uokvax:net.unix-wizar / enmasse!mike / 8:04 pm Feb 1, 1985 */ > Another problem with having a find-suid-programs program that runs based > on crontab entries is that anyone can see when the find-suid-programs > program is going to run next, and make their moves on that basis. > > kurt But what are they going to do about it. I suppose that if they knew the order in which file systems were traversed they might be able to move their program to a safe area and back again when all clear but this seems a little drastic. Easier to just modify an existing suid-root program (like su) to grant a specific user or password root access. CACM had an interesting article on this stuff a while back... It amounted to this, once root has been comprimised just once, the whole system is suspect unless everything is rebuilt from scratch, from the distribution tape. /* ---------- */ Your last paragraph is correct. From a more practical standpoint, though, were I to find some loophole (like using sendmail to create suid-root files containing binaries, etc.), I'd prefer to know at what time the regular search for suid programs took place. If I *knew* that the find started at 4 a.m., I'd remove all traces before then. That's all a hypothetical "what-if" thing, though. You're far more correct to say that once a system's been broken, it remains that way (from a potential security violation standpoint) until a trustworthy person brings in certified "clean" code. kurt