Bug 808464 - invalid order of TLS shutdown operations
invalid order of TLS shutdown operations
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
16
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Jan Vcelak
Fedora Extras Quality Assurance
:
: 812974 (view as bug list)
Depends On: 804229 812974
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-30 09:29 EDT by Jan Vcelak
Modified: 2013-03-03 20:30 EST (History)
5 users (show)

See Also:
Fixed In Version: openldap-2.4.31-3.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 804229
Environment:
Last Closed: 2012-07-17 13:21:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Vcelak 2012-03-30 09:29:37 EDT
+++ This bug was initially created as a clone of Bug #804229 +++

...

--- Additional comment from jdennis@redhat.com 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@redhat.com 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.
Comment 1 Jan Vcelak 2012-04-12 12:00:54 EDT
I submitted the patch for this issue upstream:
http://www.openldap.org/its/index.cgi?findid=7241
Comment 2 Jan Vcelak 2012-04-17 03:33:34 EDT
*** Bug 812974 has been marked as a duplicate of this bug. ***
Comment 3 Jan Vcelak 2012-06-27 09:12:06 EDT
Resolved in openldap-2.4.31-3.fc17
Comment 4 Fedora Update System 2012-06-27 09:17:07 EDT
openldap-2.4.31-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openldap-2.4.31-3.fc17
Comment 5 Fedora Update System 2012-06-27 12:06:33 EDT
openldap-2.4.26-8.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/openldap-2.4.26-8.fc16
Comment 6 Fedora Update System 2012-06-27 23:33:07 EDT
Package openldap-2.4.31-3.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.31-3.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10000/openldap-2.4.31-3.fc17
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2012-07-17 13:21:56 EDT
openldap-2.4.31-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2012-07-17 13:26:44 EDT
openldap-2.4.26-8.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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