Date: Thu, 26 Oct 1995 14:51:15 -0700 From: Bill Trost <trost@cloud.rain.com> To: gwk@cray.com, davidg@Root.COM Cc: phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@FreeBSD.ORG Subject: Re: telnetd fix Message-ID: <m0t8aCi-00005FC@cloud.rain.com> In-Reply-To: Your message of Thu, 26 Oct 1995 16:50:40 BST. <199510261550.QAA16944@racer.dkrz.de> References: <199510261550.QAA16944@racer.dkrz.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I would like to propose a solution substantially different from the one seemingly everyone else has been exploring. I havve discussed this in a similar context -- let's see what's wrong with it here. (-: The problem is not that telnetd can pass along "bad" environment variables, but that telnetd is a program *running as root* that can pass along bad environment variables. The question then becomes: Why does telnetd need to run as root? As far as I can tell, telnetd is run as root so that it can modify /var/run/utmp, either directly or via the -h flag to login. The solution I propose, then, is to create a new user (say, "utmp") that owns (or can at least write) the utmp file. Telnetd runs as this user, so it can clear out the utmp entry when the child's session has closed. /usr/bin/login doesn't check to see that it is running as root when given the -h flag; instead, it checks to see that the user that invoked it has write permissions on the utmp. Environment variables passed in by telnetd then become handled the same way they do when passed in from a user's shell, which takes care of the shared library problem. This solution could close some unknown holes in telnetd as well -- the next stack-spamming attack, for instance.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t8aCi-00005FC>