Bug 552622 (CVE-2009-4565)

Summary: CVE-2009-4565 sendmail: incorrect verification of SSL certificate with NUL in name
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: bressers, jko, kreilly, mcermak, mjc, mlichvar, qe-baseos-daemons, tao, twoerner
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4565
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-17 15:07:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 552078, 553390, 553618, 554987, 556574    
Bug Blocks:    
Attachments:
Description Flags
Upstream patch none

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