Date: Sat, 21 Oct 1995 17:06:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, gibbs@freefall.freebsd.org Cc: CVS-commiters@freefall.freebsd.org, ache@freefall.freebsd.org, cvs-user@freefall.freebsd.org Subject: Re: cvs commit: src/secure/libexec/telnetd sys_term.c Message-ID: <199510210706.RAA08451@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>>>> 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: >... >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. Perhaps this should be decided by ld.so. It already ignores LD_LIBRARY_PATH for setuid executables except to wipe it out (see ldconfig.8). Perhaps it should ignore the critical variables for all processes started by root. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510210706.RAA08451>