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