A security hole
Johannes Heuft
jh at pcsbst.UUCP
Wed Mar 23 02:46:28 AEST 1988
In article <892 at cosmo.UUCP> jum at cosmo.UUCP (Jens-Uwe Mager(sysop))
reveals the IFS trick.
Jens-Uwe, lots of system administrators with SVR2 (or less) will hate you
now, because their task of maintaining a decent computer operation will
be turned sour by some would-like-to-be hackers, who are worse than
the real ones.
There is no real work-around in SVR2 except removing the set-userid
bits or even the programs. Even if you cannot spare a seperate
machine for networking you will be surprised how many set-userid bits
or set-userid bit programs may be removed without hindering the
system operation. Think about it and try it. Somebody should make
a list of such programs and comment on what happens if the bits
are removed. Here a small start of this list:
at program may be removed in most installations
crontab remove suid-bit and let system administrator do
crontab installation
cu should remove suid-bit and wait for complaints
login remove suid-bit -> logout via login does not work (no problem)
rmail
mail
mailx depending on several settings, e.g. umask, following
procedure may work (as in SVR3)
introduce new group "mail"
chgrp mail /bin/mail /usr/bin/mailx
chmod 2555 /bin/mail /usr/bin/mailx
chgrp mail /usr/mail
chmod 775 /usr/mail
chgrp mail /usr/mail/*
chmod 775 /usr/mail/*
su try the IFS-tick. If it does work REMOVE su. Write
your own su if necessary.
/usr/lib/ex*
remove suid-bit (see other security articles!)
umount
mount remove suid bits and wait for complaints
...
...
Does somebody care to comment or add to the list??
The IFS problem is fixed in SVR3.
More information about the Comp.bugs.sys5
mailing list