Date: Fri, 20 Oct 1995 13:30:15 -0700 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: =?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> Cc: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>, CVS-commiters@freefall.freebsd.org, "Andrey A. Chernov" <ache@freefall.freebsd.org>, cvs-user@freefall.freebsd.org Subject: Re: cvs commit: src/secure/libexec/telnetd sys_term.c Message-ID: <199510202030.NAA10249@aslan.cdrom.com> In-Reply-To: Your message of "Fri, 20 Oct 1995 22:27:57 %2B0300." <ZBzW_XmeG5@ache.dialup.demos.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>In message <199510201903.MAA09981@aslan.cdrom.com> Justin T. Gibbs
> writes:
>
>>>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,
>
>>These are all that I found, and only a few are a security risk:
>
>>aslan# find . -name \*.c -print | xargs grep getenv
>>./ld.c: add_search_path(getenv("LD_LIBRARY_PATH"));
>>./ld.c: if (!nostdlib && getenv("LD_NOSTD_PATH") == NULL)
>>./rtld/rtld.c: add_search_path(getenv("LD_LIBRARY_PATH"));
>>./rtld/rtld.c: if (getenv("LD_NOSTD_PATH") == NULL)
>>./rtld/rtld.c: int tracing = (int)getenv("LD_TRACE_LOADED_OBJECT
>S");
>>./rtld/rtld.c: if (getenv("LD_SUPPRESS_WARNINGS") == NULL &&
>>./rtld/rtld.c: getenv("LD_WARN_NON_PURE_CODE") != NULL)
>>./rtld/rtld.c: char *cp, *ld_path = getenv("LD_LIBRARY_PATH");
>>./rtld/rtld.c: if (realminor < minor && getenv("LD_SUPPRESS_WARNINGS
>") == NULL)
>
>Your grep miss unsetenv("LD_PRELOAD")
>(unimplemented in FreeBSD now, but exist in Solaris).
But there is no guarantee that ld environment variables will
be the only security holes. Doing any type of selective cleansing
of the environment is bogus.
>>>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.
>
>>I disagree. The only security risk opened by this bug is accessing
>>non standard libraries by changing your LD_LIBRARY_PATH. Since
>>login is static, this whole thing could be solved by only modifying
>>the child processes environment after its been forked, but I guess
>>they went for the easiest fix.
>
>1) No, LD_NOSTD_PATH have risk too. Unimplemented LD_PRELOAD have risk
>too.
Not unless you also specify an LD_LIBRARY_PATH.
>2) login is dynamic.
Yup. You are right.
>>>BTW, I don't know any pgm != ld which use
>>>something like LD_* for internal purposes.
>
>>That's not the point.
>
>I say BTW :-)
>
>As I already say, probably you are right.
>Your agrument is eliminate _possible_ LD_* names burning against
>my easy way of tracking _possible_ ld LD_* changes :-)
>Let me think a little more on this issue.
What environment does ld look at during an exec call? The environment
of the original process? Could we work around this with an execle or
exect approach?
>--
>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
--
Justin T. Gibbs
===========================================
Software Developer - Walnut Creek CDROM
FreeBSD: Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510202030.NAA10249>