|
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. |
Category Security Release Phase Resolved Solaris 9 Operating System Solaris 10 Operating System Solaris 8 Operating System Bug Id 6424201 Date of Workaround Release 14-JUN-2006 Date of Resolved Release 28-AUG-2006 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
x86 Platform
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
x86 Platform
Modification History Date: 20-JUN-2006 20-Jun-2006:
Date: 10-JUL-2006 10-Jul-2006:
Date: 21-JUL-2006 21-Jul-2006:
Date: 26-JUL-2006 26-Jul-2006:
Date: 02-AUG-2006 02-Aug-2006:
Date: 16-AUG-2006 16-Aug-2006:
Date: 21-AUG-2006 21-aug-2006:
Date: 28-AUG-2006 28-Aug-2006:
References122856-02122857-03 110615-15 110616-15 113575-07 114137-06 Attachments This solution has no attachment | |||||||||||||||
|
|