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>
next in thread | raw e-mail | index | archive | help
>>>> 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510210706.RAA08451>