[3633] in bugtraq
Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
daemon@ATHENA.MIT.EDU (Jim Dennis)
Mon Nov 18 18:30:36 1996
Date: Sun, 17 Nov 1996 14:28:09 -0800
Reply-To: Jim Dennis <jimd@starshine.org>
From: Jim Dennis <jimd@starshine.org>
X-To: alan@manawatu.gen.nz
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
In-Reply-To: <Pine.SUN.3.90.961117235225.5461E-100000@papaioea.manawatu.gen.nz> from "Alan Brown" at Nov 17,
96 11:54:47 pm
Jim Dennis
>
> On Sat, 16 Nov 1996, Leshka Zakharoff wrote:
>
> > # This is exploit for sendmail smtpd bug
>
> How many of these exploits are thwarted by setting sendmail.cf's
> O RunAsUser=postmaster switch, making /var/spool/mail and var/spool/mqueue
> 664 postmaster.mail and giving postmaster a shell of /bin/false (C
> version, compiled -Bstatic.)
>
> AB
AB,
I doubt that Leshka's bug is affect by these measures.
His bug seems to rely on the simple facts that the simple
facts that sendmail is SUID root (which it needs to bind
to port 25 and to "run as" (su to) any UID) and that it
improperly trusts the information in it's *argv[0] for
the purposes of re-exec'ing on receiving a SIGHUP.
These are unrelated to the permissions on the spool
files. This exploit doesn't involve the operation
of sendmail after it's bound to it's port and is
listening. It involves the fact that sendmail will
allow normal users to exec it, as a daemon, and it
will subsequently load an arbitrary piece of code, from
an arbitrary location (just as long as you invoke sendmail
with an *arg[0] (it's first argument) as a full path to that
that code and the filename of that code is "smtpd").
Because the process is now owned by the user -- that user
can now send it signals. Because sendmail's sighup()
function (HUP handler) just logs and re-exec -- it will let
the control when the bogus code is executed.
I suspect that some implementations of Unix are not vulnerable
to part of this attack --- they probably won't allow the
user run process to send a signal to the already running
sendmail (that one that was started by init or root).
That would not be adequate protection. Many sites don't run
an SMTP listener -- they just have sendmail process the queue
through a cronjob. Those sites would vulnerable.
I think the "right" answer looks something like this:
sendmail should stat the file before it re-exec's
If that file isn't owned by it's EUID (usually root)
or isn't SUID (if it's EUID doesn't match its UID)
it should fail.
Is there a standard, portable way for a Unix program to
know what file was loaded and exec'd (the true link/inode
through which it was exec'd)?
Is it time to revisit this idea of sendmail being user
executable? Should we have one small program that runs
as the listener, and another small program that serves as
the local delivery agent, and another small program that
serves as the smtp transport, and another small program
that performs the routing and aliasing/dispatch function?
Perhaps, if the Internet community *is* going to continue
to rally around sendmail, it's time to review the QA process
under which we release and distribute sendmail. Last night
I spend about three hours looking around the news groups and
web, and the sendmail docs and sources for an e-mail address
of who to send a patch to or how to report a bug.
Eric Allman's address isn't listed anywhere that I could find.
The sendmail sources seem to indicate that Eric is still
involved in maintaining sendmail -- and they didn't list
any other names (exept for some specific ports). There doesn't
seem to be a sendmail-bugs@cs.berkeley.edu or a web page
explaining how to join the "sendmail security bug du jour" club.
It seems like this has been going on for twenty years. In the
short 3 years that I've been paying attention to bugtraq there
seems to be one exploitable sendmail bog every quarter
(remember the mime overflow from a couple months ago).
There must be a better way. Maybe I'll look over the sources
to smail...or mmdf...or mayber I'll print out and actually
read the sendmail sources.
The problem is that I'm not a C programmer (yet). So,
while this will be a great learning experience -- it might
not have a tremendous about of "net" benefit (if you'll all
excuse the pun).
Jim Dennis,
Starshine Technical Services
