Date: Fri, 20 Oct 1995 22:27:57 +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: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> Cc: 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: <ZBzW_XmeG5@ache.dialup.demos.ru> In-Reply-To: <199510201903.MAA09981@aslan.cdrom.com>; from "Justin T. Gibbs" at Fri, 20 Oct 1995 12:03:30 -0700 References: <199510201903.MAA09981@aslan.cdrom.com>
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_OBJECTS");
>./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).
>>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.
2) login is dynamic.
>>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.
--
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?ZBzW_XmeG5>