A Security Vulnerability in sendmail(1M) Versions Prior to 8.13.7 May Allow a Denial of Service (DoS) To Occur

---

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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1173

CERT VU#146718 at http://www.kb.cert.org/vuls/id/146718

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 without patch 114137-06
• Solaris 10 without patch 122857-03

Notes:

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 (127.0.0.1), port 25
    connection open
    220 an.example.com ESMTP Sendmail 8.13.5+Sun/8.13.5;
    Mon, 20 Mar 2006 17:07:57 GMT
    quit
    221 2.0.0 an.example.com 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 (127.0.0.1), port 25
    connect: Connection refused

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

    $ file /etc/mail/sendmail.cf
    /etc/mail/sendmail.cf:  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 processes:

    $ 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

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.

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/sendmail.cf" and "/etc/mail/submit.cf" (if present) files:

    define(`confSEPARATE_PROC',`true')dnl

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/sendmail.cf" and "/etc/mail/submit.cf" 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 follows:

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)

 

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 9 with patch 114137-06 or later
• Solaris 10 with patch 122857-03 or later

Modification History


Date: 20-JUN-2006

20-Jun-2006:

• Updated Relief/Workaround section

Date: 10-JUL-2006

10-Jul-2006:

• Updated Relief/Workaround section

Date: 21-JUL-2006

21-Jul-2006:

• Updated Contributing Factors and Resolution sections

Date: 26-JUL-2006

26-Jul-2006:

• Updated Contributing Factors and Relief/Workaround sections

Date: 02-AUG-2006

02-Aug-2006:

• Updated Contributing Factors and Resolution sections

Date: 16-AUG-2006

16-Aug-2006:

• Updated Relief/Workaround section

Date: 21-AUG-2006

21-aug-2006:

• Updated Contributing Factors and Resolution sections

Date: 28-AUG-2006

28-Aug-2006:

• Updated Contributing Factors and Resolution sections
• State: Resolved

Attachments

This solution has no attachment