Date: Thu, 26 Oct 1995 16:50:40 +0100 (MET) From: "Georg-W. Koltermann" <gwk@racer.dkrz.de> To: davidg@Root.COM Cc: phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix Message-ID: <199510261550.QAA16944@racer.dkrz.de> In-Reply-To: <199510261200.FAA00275@corbin.Root.COM> (message from David Greenman on Thu, 26 Oct 1995 05:00:19 -0700)
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> > At the moment, I'm seriously considering adding a switch to shut off the > >> > feature in FreeBSD's telnetd and making it the default in inetd.conf. > >> > >> YES! > >> > >> -- > >> Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > > > >NO! > > > >I'd rather like to see a statically linked login, which would plug the > >hole without any side-effects. > > Have people not been listening? The problem I keep bringing up has to do > with environment variables used in libc. Building login static doesn't affect > this. My original message is attached. > > -DG > > To: dab@cray.com > cc: security@freebsd.org, hartmans@mit.edu > Subject: telnetd fix > From: David Greenman <davidg@Root.COM> > Reply-To: davidg@Root.COM > -------- > Dave - > > Hi; I've been thinking about the telnetd security patch that was recently > sent out. I've been watching the list of "vulnerable" environment variables > grow daily...I really think that excluding certain environment variables is the > wrong approach to solving the problem. I think it is is much wiser to do an > inclusive test rather than an exclusive one - in other words, only allow > setting specific environment variables such as DISPLAY and TERM (perhaps those > two comprise a complete list - I can't think of any legitimate others). The > reasoning is simple: while you may catch the current set of environment > variables related to shared library spoofing, a quick search through _just_ > libc in FreeBSD reveals yet another list of worries: > > HOME > TZNAME > TZ > LANG > TMPDIR > NLSPATH > RES_OPTIONS > HOSTALIASES > LOCALDOMAIN > PATH_LOCALE David, [[ well, maybe I was not listening close enough, I will not deny that I am unable to read every line of every mail carefully when I receive so many of them every day.]] In my opinion these other environment variables *should not* be a problem. Or at least not a problem that can be fixed in telnetd. A program that runs with root priviledges on behalf of a user *has to* take special precaution that it is side-effect free. For example, it must not use $PATH, nor $HOME without checking carefully if these are trouble-free. It must not use any inherited environment variable as part of the name of a file that it writes without similar security measures. Of course the same care has to be applied with regard to any library routine that is called which in turn can use environment variables. After all nothing prevents any user from setting up a malicious environment and then typing /usr/bin/login! I believe these issues are understood and taken care of by people who write these kinds of programs. On the other hand, no programmer can safeguard against linking in code from a bad dynamic library long after he has finished his program. So extra steps must be taken that a program with root priviledges actually uses only the code that the programmer wanted. One approach is having ld.so effectively ignore environment variables like $LD_LIBRARY_PATH. The SUNOS man page for ld.so says, e. g.: NOTE: when running a set-user- or set-group-ID program, ld.so will only search for libraries in directories it "trusts", which are /usr/lib, /usr/5lib, /usr/local/lib, and any directories specified within the executable as a result of -L options given when the executable was constructed. A previous mail from Sam Hartman included a more detailed explanation (maybe that part was contributed by Theodore Ts'o): Most runtime linkers treat set user-id and set group-id programs specially: for these programs the environment variables are ignored when the program is run by a user other than the owner of the file, or by someone in a group other than the primary group of the file. Even though login is often set user-id, the environment variables are used because it is run by telnetd which runs as root. So it seems the action taken in ld.so is only effective if login gets called by a logged-in user, and not when it gets started by telnetd or any other root-process (xdm? rlogind? you-name-it-d?). The next logical step would be to avoid dynamic linking altogether for the login program. This has been proposed by someone else before (I don't recall his name), and I brought it up again in my previous mail. There remains an issue with static linking. Sometimes library writers invent new features. Functions which previously were simple and safe later become feature-full and tailorable by environment variables. E. g. some versions of tmpfile(3) obey $TMPDIR if set, while older versions use the hard-coded P_tmpdir from <stdio.h> for the directory where the file is created. This way a program which was believed-safe may become unsafe just by relinking with a newer version of a library routine. This is in no way restricted to dynamic linking, it can happen just as well with static linking at compile time. The *only* protection here is, IMHO, to have the program *itself* clear out the environment at startup time. One can *not* depend on the caller (which happens to be telnetd here) to do this, because in almost every case the caller could just as well be a shell operated by a malicious user. $DISCLAIMER (you know what I mean) Georg-W. Koltermann, gwk@cray.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510261550.QAA16944>