Bug 552622 (CVE-2009-4565) - CVE-2009-4565 sendmail: incorrect verification of SSL certificate with NUL in name
Summary: CVE-2009-4565 sendmail: incorrect verification of SSL certificate with NUL in...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-4565
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://web.nvd.nist.gov/view/vuln/det...
Whiteboard:
Depends On: 552078 553390 553618 554987 556574
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-05 17:11 UTC by Tomas Hoger
Modified: 2019-09-29 12:33 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-17 15:07:20 UTC
Embargoed:


Attachments (Terms of Use)
Upstream patch (3.81 KB, patch)
2010-01-07 16:53 UTC, Tomas Hoger
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0237 0 normal SHIPPED_LIVE Low: sendmail security and bug fix update 2010-03-29 12:40:12 UTC
Red Hat Product Errata RHSA-2011:0262 0 normal SHIPPED_LIVE Low: sendmail security and bug fix update 2011-02-16 14:35:47 UTC

Description Tomas Hoger 2010-01-05 17:11:56 UTC
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

Comment 1 Tomas Hoger 2010-01-07 16:53:22 UTC
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.

Comment 3 Tomas Hoger 2010-01-07 19:16:31 UTC
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.

Comment 6 Tomas Hoger 2010-01-13 09:52:36 UTC
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.

Comment 9 Fedora Update System 2010-03-28 19:24:25 UTC
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

Comment 10 Fedora Update System 2010-03-28 23:28:26 UTC
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

Comment 11 errata-xmlrpc 2010-03-30 08:22:59 UTC
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

Comment 15 Fedora Update System 2010-06-14 17:26:31 UTC
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.

Comment 16 Fedora Update System 2010-06-21 12:53:25 UTC
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.

Comment 18 errata-xmlrpc 2011-02-16 14:35:54 UTC
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


Note You need to log in before you can comment on or make changes to this bug.