Date: Fri, 20 Oct 1995 12:03:30 -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: "Andrey A. Chernov" <ache@freefall.freebsd.org>, "Justin T. Gibbs" <gibbs@freefall.freebsd.org>, CVS-commiters@freefall.freebsd.org, cvs-user@freefall.freebsd.org Subject: Re: cvs commit: src/secure/libexec/telnetd sys_term.c Message-ID: <199510201903.MAA09981@aslan.cdrom.com> In-Reply-To: Your message of "Fri, 20 Oct 1995 20:55:50 %2B0300." <YBcA-Xmis3@ache.dialup.demos.ru>
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,
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)
>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.
>BTW, I don't know any pgm != ld which use
>something like LD_* for internal purposes.
That's not the point.
>--
>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?199510201903.MAA09981>