From owner-freebsd-hackers Mon Oct 23 20:18:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA27740 for hackers-outgoing; Mon, 23 Oct 1995 20:18:14 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA27731 for ; Mon, 23 Oct 1995 20:18:07 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA05093; Mon, 23 Oct 1995 20:17:59 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id UAA00294; Mon, 23 Oct 1995 20:16:29 -0700 Message-Id: <199510240316.UAA00294@corbin.Root.COM> To: ache@freefall.freebsd.org cc: freebsd-hackers@freebsd.org, John Polstra Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs In-reply-to: Your message of "Tue, 24 Oct 95 05:00:22 +0300." From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 20:16:28 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >In message > =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: > >>In message <199510240141.SAA00275@corbin.Root.COM> David Greenman >> writes: > >>> Any shell script which is suseptible to a security hole because a command >>>failed to execute is broken. There are many reasons why things can fail >>>ranging from no diskspace available to who knows what. I think Andrey's hack >>>is an attempt to dam a river with a piece of tissue paper. The real problem > >>If we try to plug all potential holes that we find, even small ones, >>probability of security violation becomes reduced. I don't plan to dam whole >>river, just plug in small leak reducing leaks number at whole. > >BTW, why you stuck on "shell scripts" only? The same hole can hits >when commands entered by hand, see my example. If you are capable of entering commands by hand then it is not an issue - the malicious user can set the environment variables directly and he'll see the command failure, so? Actually, I really don't think this is an issue in any case, and I would rather see the hack removed than to continue in this direction. Now that I've had some time to think about this, I would rather that we just remove support for LD_NOSTD_PATH completely. Except for shared library debugging, I can't think of a legitimate use for it. -DG