From owner-freebsd-security Thu Apr 13 09:34:33 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA20516 for security-outgoing; Thu, 13 Apr 1995 09:34:33 -0700 Received: from mpp.com (dialup-1-21.gw.umn.edu [134.84.101.21]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA20500 for ; Thu, 13 Apr 1995 09:34:21 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id LAA07243; Thu, 13 Apr 1995 11:31:22 -0500 From: Mike Pritchard Message-Id: <199504131631.LAA07243@mpp.com> Subject: Re: cvs commit: src/usr.sbin/cron/cron do_command.c To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Date: Thu, 13 Apr 1995 11:31:22 -0500 (CDT) Cc: pritc003@maroon.tc.umn.edu, freebsd-security@FreeBSD.org In-Reply-To: from "Andrey A. Chernov, Black Mage" at Apr 13, 95 01:40:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3529 Sender: security-owner@FreeBSD.org Precedence: bulk > >> > >> ache 95/04/12 11:57:40 > >> > >> Modified: usr.sbin/cron/cron do_command.c > >> Log: > >> Close MAILTO security hole > > >I took a look at your fix, and the security hole is still there. Simply > >checking if the first character of the MAILTO variable is a '-' isn't > >enough, since I could simply prefix the MAILTO variable with a space (or > >lots of them or whatever). > > Did you really tried f.e. > > sendmail ' -v' Yes, I just got your fix via sup and was able to obtain root access even with your fix installed. Here is what I set my MAILTO variable to: MAILTO=" -C/usr/tmp/c test" This is then sprinted into a string, which is then parsed with "strtok" to split the string up. Strtok skips the leading spaces, and you wind up with a valid argument to sendmail. Just so you are sure I've got your fix, here is the Id string from do_command.c: static char rcsid[] = "$Id: do_command.c,v 1.2 1995/04/12 18:57:37 ache Exp $"; > >I can also add additional arguments, > >which with sendmail isn't a problem, but what if the administrator chooses > >to edit cron/config.h and use a different mail delivery program? > >when who knows how those extra arguments are going to be used. > > It is administrators fault. Even if you use sendmail, who knows what might change in sendmail in the future that might allow this to cause problems? There may even be a way right now to exploit the extra arguments that no one has thought of yet. > >I still think that the best way to fix this problem is to require that > >the user name that cron intends to send mail to points to a valid login > >name (which my fix does). That way there is no doubt that the user isn't > >passing something funny in the variable that may be interpreted by either > >the popen call or sendmail in some unintended manner. Programs that run as > >root should be as restrictive as possible with user supplied parameters that > >they pass off to other programs that are also going to be run as root (or > >as anything other than the calling user). They shouldn't try and decide if > >the parameters look "OK" enough to pass along. They should require that > >they conform to a very strictly defined format. > > Your fix breaks MAILTO handling according to cron manpage. How? The cron man page states: ... current minute. When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists). It doesn't sound like cron is saying that it allows anything other than a valid user name in the MAILTO varaible. It doesn't say anything about mailing to a mail address, just to a user. If you need the mail to go somewhere else, either setup an account that cron can mail to that you can forward in /etc/aliases, or if you are a normal user, use one of the mail filtering programs to do it for you. Cron shouldn't have to worry about anything other than delivering mail back to a valid local user. I still think that the best fix is to only allow valid local user names to be specified in the MAILTO variable. Then there is no doubt that the user isn't able to spoof sendmail. Either that or run sendmail as the user and let them put anything they like in the MAILTO variable. > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"