Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).

[jimd () starshine org (Jim Dennis)]

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