copyright | disclaimer | privacy | contact  
Australia's Leading Computer Emergency Response Team
Search this site

On this site

 > About AusCERT
 > Membership
 > Contact Us
 > PKI Services
 > Publications
 > Sec. Bulletins
 > Conferences
 > News & Media
 > Services
 > Web Log
 > Site Map
 > Site Help
 > Member login


ESB-2006.0419 -- [Solaris] -- A Security Vulnerability in sendmail(1M) May Allow a Denial of Service (DoS) To Occur

Date: 23 August 2006
References: AL-2006.0048  

Click here for printable version
Click here for PGP verifiable version
Hash: SHA1

             AUSCERT External Security Bulletin Redistribution

                        ESB-2006.0419 -- [Solaris]
        A Security Vulnerability in sendmail(1M) May Allow a Denial
                         of Service (DoS) To Occur
                              23 August 2006


        AusCERT Security Bulletin Summary

Product:              Sendmail
Publisher:            Sun Microsystems
Operating System:     Solaris 8, 9 and 10
Impact:               Denial of Service
Access:               Remote/Unauthenticated
CVE Names:            CVE-2006-1173

Ref:                  AL-2006.0048

Revision History:  August 23 2006: Updated Contributing Factors and
                                   Resolution sections
                   August 21 2006: Updated workaround section
                   August  4 2006: Sun released updates to Contributing
                                   Factors and Resolution sections
                   June   22 2006: Mitigation section updated
                   June   16 2006: Initial Release

- --------------------------BEGIN INCLUDED TEXT--------------------

Sun(sm) Alert Notification
     * Sun Alert ID: 102460
     * Synopsis: A Security Vulnerability in sendmail(1M) Versions Prior
       to 8.13.7 May Allow a Denial of Service (DoS) To Occur
     * Category: Security
     * Product: Solaris 9 Operating System, Solaris 10 Operating System,
       Solaris 8 Operating System
     * BugIDs: 6424201
     * Avoidance: Workaround, Patch
     * State: Workaround
     * Date Released: 14-Jun-2006
     * Date Closed: 
     * Date Modified: 20-Jun-2006, 10-Jul-2006, 21-Jul-2006, 26-Jul-2006,
       02-Aug-2006, 16-Aug-2006, 21-Aug-2006

1. Impact

   On hosts where sendmail(1M) is configured to accept incoming mail, a
   local or remote unprivileged user may be able to prevent sendmail from
   successfully delivering queued messages, resulting in a Denial of
   Service (DoS) of the sendmail delivery mechanism.

   On hosts which do not accept remote incoming mail, but make use of
   sendmail(1M) to deliver messages to other hosts and users, a local
   unprivileged user may be able to prevent sendmail from delivering
   queued messages, again resulting in a Denial of Service (DoS) of the
   sendmail delivery mechanism.

   If either of the two issues above are exploited, an additional Denial
   of Service (DoS) to the system may occur if sendmail(1M) is configured
   to write unique core files to disk and to attempt to flush the
   delivery queue regularly. Each attempt to flush the delivery queue
   will result in a new core file being written to disk, eventually
   consuming all available space.

   This issue is referenced in the following documents:

   CVE-2006-1173 at

   CERT VU#146718 at

2. Contributing Factors

   This issue can occur in the following releases:

   SPARC Platform
     * Solaris 8 without patch 110615-15
     * Solaris 9 without patch 113575-07
     * Solaris 10 without patch 122856-02

   x86 Platform
     * Solaris 8 without patch 110616-15
     * Solaris 9
     * Solaris 10 without patch 122857-03


   1. The current Solaris 8 sendmail patches (110615-14 for SPARC and
   110616-14 for x86) update sendmail to version 8.11.7p2+Sun. This
   version of sendmail is affected by this vulnerability.

   The Solaris 8 patches which will address this vulnerability will
   update sendmail to version 8.11.7p3+Sun. This is a minor change to
   this version of sendmail, however, these are the only patches which
   are required to address this vulnerability in Solaris 8.

   The Solaris 9 and 10 patches which address this issue will update
   sendmail directly to version 8.13.7+Sun.

   2. This issue only affects systems which have sendmail(1M) enabled, or
   which use sendmail to deliver messages.

   3. Sendmail versions prior to 8.13.7 are impacted by this issue.

   A) To determine if sendmail(1M) is running on the system and its
   version number, the mconnect(1) command can be used, as in the
   following example:
    $ /usr/bin/mconnect
    connecting to host localhost (, port 25
    connection open
    220 ESMTP Sendmail 8.13.5+Sun/8.13.5;
    Mon, 20 Mar 2006 17:07:57 GMT
    221 2.0.0 closing connection

   If sendmail is not running on the system, the mconnect(1) command will
   report the following:
    $ /usr/bin/mconnect
    connecting to host localhost (, port 25
    connect: Connection refused

   To determine if sendmail(1M) is configured for use in delivering
   messages, the presence of the `' file can be checked, using
   a command such as the following:
    $ file /etc/mail/
    /etc/mail/  English text

   To determine if there are currently messages in sendmail's queue which
   may be affected by this issue, the following commands can be used with
   the default sendmail(1M) configuration (the second command is
   available on Solaris 9 and later only):
    # mailq
    /var/spool/mqueue is empty
    Total requests: 0

    # mailq -Ac
    /var/spool/clientmqueue is empty
    Total requests: 0

   B) To determine if the system is vulnerable to the additional issue of
   disk space consumption, check whether sendmail(1M) is configured to
   create unique core dumps using the coreadm(1M) command to check the
   global and per-process core dump settings which affect the sendmail
    $ coreadm | grep global
    global core file pattern: /var/cores/core.%f.%p
    global core file content: default
    global core dumps: enabled
    global setid core dumps: disabled
    global core dump logging: disabled

    # coreadm `pgrep sendmail`
    109584:  core.%f.%p      default

       109586: core default

3. Symptoms

   If this issue has been exploited to cause a Denial of Service(DoS),
   some messages may remain in the delivery queue indefinitely, and will
   not be delivered to their destinations. Note that if this issue
   occurs, sendmail will continue to receive messages from remote hosts
   and will successfully deliver messages which are not deferred into the
   delivery queue.

   If sendmail is configured to save unique core dumps, these will be
   stored at a path that depends on the configuration set with
   coreadm(1M) and will occupy an increasing share of the disk space. 

4. Relief/Workaround

   To prevent the disruption of the sendmail(1M) delivery mechanism, the
   'ForkEachJob' option can be set, causing sendmail to deliver each
   message in its own process, preventing any one message from disrupting
   the delivery of other messages. However, this may have an impact on
   the performance of the delivery process.

   This option can be set by adding the following line to the *.mc files
   used to generate the "/etc/mail/" and "/etc/mail/"
   (if present) files:

   The *.mc files are located in "/usr/lib/mail/cf" for Solaris 8 and 9,
   and "/etc/mail/cf/cf" for Solaris 10.

   Generate the new *.cf files from these revised *.mc files and copy to
   "/etc/mail/" and "/etc/mail/" as required. Please
   refer to "/usr/lib/mail/README" for additional information on how to
   use the *.mc files.

   Restart sendmail once the modifications have been performed, as

   Solaris 10:
    # svcadm restart sendmail

   Solaris 8, 9:
    # /etc/init.d/sendmail stop
    # /etc/init.d/sendmail start

   To prevent sendmail(1M) from filling up the disk, it can be configured
   using the coreadm(1M) command to write statically named core files.
   This should be applied to both the global core file pattern (if
   enabled) and the per-process core file pattern.

   For example, to disable global core files:
    # coreadm -d global

   and to make sendmail core dump filenames static until the sendmail
   service is restarted:
    # coreadm -p core.%f $(pgrep sendmail)

   A preliminary T-Patch is available for the following release from

   x86 Platform
     * Solaris 9 T-patch T114137-06

   This document refers to one or more preliminary temporary patches
   (T-Patches) which are designed to address the concerns identified
   herein. Sun has limited experience with these patches due to their
   preliminary nature. As such, you should only install the patches on
   systems meeting the configurations described above. Sun may release
   full patches at a later date, however, Sun is under no obligation
   whatsoever to create, release, or distribute any such patch.

5. Resolution

   This issue is addressed in the following releases:

   SPARC Platform
     * Solaris 8 with patch 110615-15 or later
     * Solaris 9 with patch 113575-07 or later
     * Solaris 10 with patch 122856-02 or later

   x86 Platform
     * Solaris 8 with patch 110616-15 or later
     * Solaris 10 with patch 122857-03 or later

   A final resolution is pending completion.

Change History

     * Updated Relief/Workaround section

     * Updated Relief/Workaround section

     * Updated Contributing Factors and Resolution sections

     * Updated Contributing Factors and Relief/Workaround sections

     * Updated Contributing Factors and Resolution sections

     * Updated Relief/Workaround section

     * Updated Contributing Factors and Resolution sections

   This Sun Alert notification is being provided to you on an "AS IS"
   basis. This Sun Alert notification may contain information provided by
   third parties. The issues described in this Sun Alert notification may
   or may not impact your system(s). Sun makes no representations,
   warranties, or guarantees as to the information contained herein. ANY
   This Sun Alert notification contains Sun proprietary and confidential
   information. It is being provided to you pursuant to the provisions of
   your agreement to purchase services from Sun, or, if you do not have
   such an agreement, the Terms of Use. This Sun Alert
   notification may only be used for the purposes contemplated by these

   Copyright 2000-2006 Sun Microsystems, Inc., 4150 Network Circle, Santa
   Clara, CA 95054 U.S.A. All rights reserved

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:

Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email:
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.