RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 818572 - invalid order of TLS shutdown operations
Summary: invalid order of TLS shutdown operations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: beta
: ---
Assignee: Jan Vcelak
QA Contact: David Spurek
URL:
Whiteboard:
Depends On:
Blocks: 719895 818570
TreeView+ depends on / blocked
 
Reported: 2012-05-03 12:13 UTC by Karel Srot
Modified: 2015-03-02 05:26 UTC (History)
4 users (show)

Fixed In Version: openldap-2.4.23-29.el6
Doc Type: Bug Fix
Doc Text:
Cause: TLS connection to an LDAP server established, used, and correctly terminated. Consequence: The order of the internal TLS shutdown operation is incorrect. This can cause unexpected behavior of the underlying crypto library (Mozilla NSS). Fix: Patch applied to reoder the operations performed when closing the connection. Result: The order of TLS shutdown operations matches with Mozilla NSS crypto library documentation. No unexpected behavior and crashes caused by incorrect order of TLS shutdown operations are possible.
Clone Of:
Environment:
Last Closed: 2013-02-21 09:45:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0364 0 normal SHIPPED_LIVE openldap bug fix and enhancement update 2013-02-20 20:52:54 UTC

Description Karel Srot 2012-05-03 12:13:39 UTC 
This is a RHEL6 clone of following Fedora bug. We need this fixed because of Bug 719895.

+++ This bug was initially created as a clone of Bug #808464 +++

+++ This bug was initially created as a clone of Bug #804229 +++

...

--- Additional comment from jdennis on 2012-03-19 14:30:38 CET ---

re comment #6

Thanks Jan, yes I too was able to read the tls_m.c code and see what it does. What I was trying to suggest is that either ldap_ld_free() or some of the code in tls_m.c has things occurring in the wrong order, this should be obvious from the attached backtrace. Both Kai and I are suggesting that CERT_DestroyCertificate should not be called after the NSS context it was created from to was destroyed, it's the wrong order of operations.

In other words what is happening is an SSL socket is created using an NSS context (i.e. the NSS context must exist prior to creating the SSL socket). But when the socket is disposed of the order of operations isn't mirrored in reverse. The socket should be disposed of first because it belongs to the NSS context, then the NSS context should be destroyed. But openldap is performing the opposite, it's destroying the NSS context first and then the socket.

So it seems to me that openldap got this wrong due to one or both of the following: 

In ldap_ld_free() it first calls ldap_int_tls_destroy() which via the tls function pointers will call tlsm_ctx_free destroying the NSS context. Then later ldap_ld_free() calls ber_sockbuf_free() which via the tls function pointers calls NSS to close the socket. This is the wrong order of operations.

So either ldap_int_tls_destroy() needs to be moved after ber_sockbuf_free() or what's performed in the tls functions exported by tls_m.c need to be modified it guarantees the right order of operations.

Make sense now?

--- Additional comment from jvcelak on 2012-03-19 16:01:22 CET ---

(In reply to comment #7)
> Thanks Jan, yes I too was able to read the tls_m.c code and see what it does.

Sorry, I was trying to help.

> In other words what is happening is an SSL socket is created using an NSS
> context (i.e. the NSS context must exist prior to creating the SSL socket). But
> when the socket is disposed of the order of operations isn't mirrored in
> reverse. The socket should be disposed of first because it belongs to the NSS
> context, then the NSS context should be destroyed. But openldap is performing
> the opposite, it's destroying the NSS context first and then the socket.

True.

> So either ldap_int_tls_destroy() needs to be moved after ber_sockbuf_free() or
> what's performed in the tls functions exported by tls_m.c need to be modified
> it guarantees the right order of operations.

I have just quickly scanned OpenSSL and GnuTLS backends, and it seems that this change would be possible without harming the other backends. As for OpenSSL, I found some references that closing the connection (SSL_Shutdown) should appear before cleaning up the resources (SSL_CTX_free). Which is the same case. I'm not very sure about GnuTLS. But the current order is illogical IMO.

--- Additional comment from jvcelak on 2012-04-12 12:00:54 EDT ---

I submitted the patch for this issue upstream:
http://www.openldap.org/its/index.cgi?findid=7241

--- Additional comment from jvcelak on 2012-04-17 03:33:34 EDT ---

*** Bug 812974 has been marked as a duplicate of this bug. ***
Comment 1 Jan Vcelak 2012-06-27 16:21:28 UTC 
The patch was accepted upstream.
Comment 5 Jan Vcelak 2012-09-25 16:10:08 UTC 
Resolved in: openldap-2.4.23-29.el6
Comment 11 errata-xmlrpc 2013-02-21 09:45:42 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0364.html
Note You need to log in before you can comment on or make changes to this bug.