Date: Thu, 13 Apr 1995 11:31:22 -0500 (CDT) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Cc: pritc003@maroon.tc.umn.edu, freebsd-security@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron do_command.c Message-ID: <199504131631.LAA07243@mpp.com> In-Reply-To: <OHbZ4ZluuB@astral.msk.su> from "Andrey A. Chernov, Black Mage" at Apr 13, 95 01:40:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >>
> >> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504131631.LAA07243>