🚀 go-pugleaf

In article <175@pcsbst.UUCP>, jh@pcsbst.UUCP (Johannes Heuft) writes:
> In article <892@cosmo.UUCP> jum@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.

Yes, there is a workaround; it is tedious but it works.  Write
a small front-end (say. lp.c) that does:

	/*--------------------- lp.c -----------------------*/
	#define	REAL_LP	/usr/bin/.lp

	main(argc, argv)
	int	argc;
	char	*argv[];
	{
		putenv("IFS= \t\n");
		putenv("SHELL=/bin/sh");
		putenv("PATH=/bin:/usr/bin");

		execv(REAL_LP, argv);
	}
	/*--------------------- lp.c -----------------------*/

(*) rename /usr/bin/lp to /usr/bin/.lp
(*) install the above lp fix to /usr/bin/lp
(*) remove setuid/setgid permissions from /usr/bin/.lp
(*) add the setuid/setgid permission + owner + group to /usr/bin/lp
(*) remove all read access from the now-setuid file

The old program is still susceptible to the IFS bug but it is
entirely harmless: the setuid front-end will fix it.  Disclaimer:
no warranty that this fixes all bugs, prevents all scam, or stops
all hunger in the world.  It works for me but there are always
smarter people out there.

Not all of the programs Johannes mentions are at risk, but in
any case, it has been my experience that making all setuid or
setgid programs unreadable by anybody will help quite a bit.
There is much to be learned by poking around object files, and
closing this door makes it much more difficult to see where
the holes are or might be.

---
Steve Friedl      V-Systems, Inc.        *Hi Mom*
friedl@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl

-- 
Steve Friedl      V-Systems, Inc.        *Hi Mom*
friedl@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl