|
Note: This is an archival copy of Security Sun Alert 200494 as previously published on http://sunsolve.sun.com. Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000372.1. |
Category Security Release Phase Resolved Solaris 9 Operating System Solaris 10 Operating System Solaris 8 Operating System Bug Id 6397275, 6403051 Date of Resolved Release 17-APR-2006 Security Vulnerability in sendmail(1M) Versions Prior to 8.13.6 Impact A local or remote unprivileged user may be able to execute arbitrary code with elevated privileges or cause a Denial of Service (Dos) condition due to a security vulnerability in the sendmail(1M) daemon involving signal handling. This issue is referenced in the following documents: CVE-2006-0058 at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058 CERT VU#834865 http://www.kb.cert.org/vuls/id/834865 which is referenced in CERT Technical Cyber Security Alert TA06-081A: http://www.us-cert.gov/cas/techalerts/TA06-081A.html Contributing Factors This issue can occur in the following releases: SPARC Platform
x86 Platform
Notes: 1. The current Solaris 8 sendmail patches (110615-13 for SPARC and 110616-13 for x86) update sendmail to version 8.11.7p1+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.7p2+Sun. This is a minor change to this version of sendmail and this is tracked using BugID 6403051. The Solaris 9 and 10 patches which address this issue will update sendmail directly to version 8.13.6+Sun. 2. This issue only affects systems which have sendmail enabled. Sendmail versions prior to 8.13.6 are impacted by this issue. To determine the version of sendmail(1M) running on a system, 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 Symptoms There are no reliable symptoms that would indicate this issue has been exploited to execute arbitrary commands with elevated privileges on a system. The symptoms of the Denial of Service would be the sendmail daemon no longer running. Workaround Until patches can be applied, sites may wish to block access to the affected service from untrusted networks such as the Internet, or disable the sendmail daemon where possible. Use a firewall or other packet-filtering technology to block the appropriate network ports. Consult your vendor or your firewall documentation for detailed instructions on how to configure the ports. The sendmail daemon can be disabled using the following commands: For Solaris 9: # /etc/init.d/sendmail stop This will disable sendmail on the running system but it will be restarted on reboot. To disable sendmail for future reboots, the '/etc/rc2.d/S88sendmail' script will need to be renamed so that it no longer begins with an 'S', as in the following example: # mv /etc/rc2.d/S88sendmail /etc/rc2.d/not-S88sendmail For Solaris 10: # svcadm disable svc:/network/smtp:sendmail This will disable the sendmail daemon for future reboots as well. To re-enable sendmail, the 'enable' subcommand can be supplied to svcadm(1M) with the same FMRI for sendmail above. Resolution This issue is addressed in the following releases: SPARC Platform
x86 Platform
Modification History Date: 24-MAR-2006 24-Mar-2006:
Date: 27-MAR-2006 27-Mar-2006:
Date: 30-MAR-2006 30-Mar-2006:
Date: 03-APR-2006 03-Apr-2006:
Date: 07-APR-2006 07-Apr-2006:
Date: 17-APR-2006 17-Apr-2006:
References110615-14110616-14 113575-06 114137-05 122856-01 122857-01 Attachments This solution has no attachment | |||||||||||||||
|
|