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.
Solaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System
Date of Resolved Release
Security Vulnerability in sendmail(1M) Versions Prior to 8.13.6
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
This issue can occur in the following releases:
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
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.
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.
This issue is addressed in the following releases:
This solution has no attachment