Date: Fri, 20 Oct 1995 20:55:50 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su> To: "Andrey A. Chernov" <ache@freefall.freebsd.org>, "Justin T. Gibbs" <gibbs@freefall.freebsd.org> Cc: CVS-commiters@freefall.freebsd.org, cvs-user@freefall.freebsd.org Subject: Re: cvs commit: src/secure/libexec/telnetd sys_term.c Message-ID: <YBcA-Xmis3@ache.dialup.demos.ru> In-Reply-To: <199510201723.KAA09542@aslan.cdrom.com>; from "Justin T. Gibbs" at Fri, 20 Oct 1995 10:23:24 -0700 References: <199510201723.KAA09542@aslan.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199510201723.KAA09542@aslan.cdrom.com> Justin T. Gibbs
writes:
>>ache 95/10/20 10:16:59
>>
>> Modified: secure/libexec/telnetd sys_term.c
>> Log:
>> Don't allow LD_* env. variables to be tricked
>> Submitted by: Sam Hartman <hartmans@mit.edu>
>I think that it should *only* exclude the variables that cause
>the vulnerability. Just because I choose to use a variable
>called LD_MY_TERMINAL_IS_BLUE doesn't mean I should get burned.
Probably. But... There is too many LD_* variables in our ld,
also some of them are unimplemented, they may be implemented
in future or new LD_* variables can be added (in honor of Solaris
style as I see). Better is not track ld changes here and refuse
all LD_* variables at once. BTW, I don't know any pgm != ld which use
something like LD_* for internal purposes.
--
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YBcA-Xmis3>