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>