Note: This is an archival copy of Security Sun Alert 275870 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1021797.1.
Applies to:OpenSolaris Operating System - Version: All Versions
Sun Software > Operating Systems > Solaris Operating System
Sun SPARC Sun OS
Exploitation of this issue is considered difficult and would typically require redirecting sendmail to an incorrect server by some means such as leveraging an exploit in DNS. The specific impact would depend on the way sendmail is configured to use the X.509 certificates.
For example, if sendmail is configured to require that mail being sent to a certain domain will only be delivered to that domain's mail server if it has a valid certificate for that domain, then it may be possible for a remote user to impersonate that server by presenting a forged certificate. The remote user would first have to cause sendmail to connect to a server which he or she controls instead of the correct one.
This issue is also discussed in the following documents:
CVE 2009-4565 at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4565
1. This issue only affects systems on which sendmail has been configured to use TLS with X.509 certificates. To determine if sendmail is running on a host and whether TLS is enabled, the mconnect(1) command can be used to connect to sendmail (if running), after which, the EHLO command will output the supported extensions.
If "STARTTLS" appears in the list of supported extensions, the sendmail server may be vulnerable.$ mconnect mailserver
The sendmail configuration would determine how the certificates are used, and therefore what may be achieved by a user presenting a forged certificate. See the sendmail documentation for more information, for example, the file /etc/mail/cf/README under the heading 'STARTTLS'.
If sendmail is not running on the system the mconnect(1) command will report the following:
2. Sendmail shipped with Solaris 8 and 9 does not support TLS and those releases are not impacted.$ /usr/bin/mconnect
This solution has no attachment