From owner-freebsd-hackers Mon Oct 23 18:58:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA19659 for hackers-outgoing; Mon, 23 Oct 1995 18:58:22 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA19646 for ; Mon, 23 Oct 1995 18:58:15 -0700 Received: by sequent.kiae.su id AA16527 (5.65.kiae-2 ); Tue, 24 Oct 1995 05:54:10 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 24 Oct 95 05:54:10 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id EAA00492; Tue, 24 Oct 1995 04:53:25 +0300 To: davidg@Root.COM, Nate Williams Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra References: <199510240141.SAA00275@corbin.Root.COM> In-Reply-To: <199510240141.SAA00275@corbin.Root.COM>; from David Greenman at Mon, 23 Oct 1995 18:41:19 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 24 Oct 1995 04:53:25 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Lines: 27 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1482 Sender: owner-hackers@freebsd.org Precedence: bulk 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. > My "vote" is to remove the hack. Regarding telnetd: I really think the >proper solution to the problem is to do an inclusive env check, not an >exclusive one. In other words, only specific environment variables should be >allowed to be set (DISPLAY, TERM, a few others). It's really impossible to know >what environment variables might lurk out there now and in the future - for >instance, we check "TZ" in libc, and while I don't know how that could used to >spoof telnetd/login, stranger things have happend. For telnetd: I agree. Try to cantact with telnet maintainers on this issue. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849