From owner-freebsd-security Thu Oct 26 14:52:25 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28832 for security-outgoing; Thu, 26 Oct 1995 14:52:25 -0700 Received: from jli (jli.portland.or.us [199.2.111.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA28812 for ; Thu, 26 Oct 1995 14:52:20 -0700 Received: from cumulus by jli with uucp (Smail3.1.29.1 #3) id m0t8aD7-0001b9C; Thu, 26 Oct 95 14:51 PDT Message-Id: X-Wily-Tags: Put then wsend 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 References: <199510261550.QAA16944@racer.dkrz.de> In-reply-to: Your message of Thu, 26 Oct 1995 16:50:40 BST. <199510261550.QAA16944@racer.dkrz.de> Date: Thu, 26 Oct 1995 14:51:15 -0700 From: Bill Trost Sender: owner-security@FreeBSD.ORG Precedence: bulk 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.