Red Hat Bugzilla – Bug 552622
CVE-2009-4565 sendmail: incorrect verification of SSL certificate with NUL in name
Last modified: 2018-10-27 08:50:13 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-4565 to the following vulnerability: sendmail before 8.14.4 does not properly handle a '\0' character in a Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based SMTP servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended access restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408. References: http://www.sendmail.org/releases/8.14.4 http://www.securityfocus.com/bid/37543 http://secunia.com/advisories/37998 http://www.vupen.com/english/advisories/2009/3661
Created attachment 382283 [details] Upstream patch I went through the 8.14.3 -> 8.14.4 and this should be all that's needed to fix this. There are other TLS-related changes in .4 like introductions of configuration options for server and client SSL options, but those do not really seem related to this issue.
This bug can cause an incomplete CommonName string to be extracted from the certificate to ${cn_subject} or ${cn_issuer} macros. NUL in CN will not cause truncation of the value extracted to ${cert_subject} and ${cert_issuer} macros, as subjects stored in those macros are extracted using OpenSSL's X509_NAME_oneline(), which escapes NUL character. Those affected macros can be used in two basic ways: - In rules that are executed when sendmail acts as an SMTP client to verify identity of the SMTP server it connects to. - To verify identity of the SMTP client connecting to the sendmail SMTP server. Notes regarding the first kind of use: When use of TLS is configured for client connections, verification of the SSL certificates is not enabled by default and has to be configured in access_map. Successful verification of the server's certificate is not often configured as SMTP server on the internet may not have certificates issued by some trusted CA. CN checking can be enabled in addition to the verification. Common configurations do not have these checks enabled and hence TLS provides no integrity guarantees, so an attacker can perform MITM attacks regardless of this issue. When both VERIFY and CN checks are enabled, attacker needs a specially crafted certificate from the trusted CA configured for use in sendmail and needs to be able to hijack client's connection. Notes regarding the second kind of use: Client certificates are usually used to permit RELAY for roaming users with changing IP address. Those checks are usually done using the values of ${cert_subject} and ${cert_issuer}, and hence are unlikely to be affected by this problem. As this issue affects not very common configurations and the issue is not easy to exploit, this has been rated as having low security impact. Future sendmail updates may address this flaw.
Unlike the original issue CVE-2009-2408 that was reported for NSS / Firefox, sendmail will not handle * wildcard as special character in CN checks in TLS_Srv or TLS_Clt maps. Possible attacks will require per-host certificate, rather than "universal MITM certificate" as was published before.
sendmail-8.14.4-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/sendmail-8.14.4-3.fc12
sendmail-8.14.4-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/sendmail-8.14.4-3.fc11
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0237 https://rhn.redhat.com/errata/RHSA-2010-0237.html
sendmail-8.14.4-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
sendmail-8.14.4-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2011:0262 https://rhn.redhat.com/errata/RHSA-2011-0262.html