Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.bugs.sys5
Subject: Re: A security hole
Message-ID: <7528@brl-smoke.ARPA>
Date: 23 Mar 88 20:52:21 GMT
References: <181@wsccs.UUCP> <722@rivm05.UUCP> <478@minya.UUCP> <892@cosmo.UUCP> <175@pcsbst.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

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

Oh, come on.  The IFS trick is quite well-known, ESPECIALLY among
the "hackers" who like to mess up system operation.  It is better
for everyone to be aware of the problem than to pretend that by
not talking about it there will be no problem.

>There is no real work-around in SVR2 except ...
>The IFS problem is fixed in SVR3.

It is easy to fix this in the SVR2 shell, too:
/*	@(#)main.c	1.7	*/
...
	/*
	 * default internal field separators - $IFS
	 */
	assign(&ifsnod, sptbnl);	/* DAG -- was dfault(); now forced */

And don't say "but what if you don't have source"?  The originator
of your binary distribution DOES have source; get them to fix it.