Note: This is an archival copy of Security Sun Alert 200422 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000305.1.
Solaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System
Date of Workaround Release
Date of Resolved Release
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
This issue can occur in the following releases:
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
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.
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:
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:
# 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)
This issue is addressed in the following releases:
This solution has no attachment