Full_Name: Jouko Orava Version: 2.4.28, 2.4.33 OS: Debian/Ubuntu URL: Submission from: (NULL) (82.181.197.37) If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4 crashes in ldap_start_tls_s() due to a double free. See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353 for my original bug submission, including a suggested patch, https://launchpadlibrarian.net/129174364/openldap-ciphersuite.patch and a simple example ldapsearch-like program that can be used to test the issue. This bug is not critical, since using a valid GnuTLS cipher suite does work, for example "NORMAL" or "SECURE256". However, trying to use anything more specific is exceedingly difficult -- basically trial and error, due to applications crashing in libldap with an invalid one. The two other TLS implementations in OpenLDAP are not affected by this bug. The double free occurs in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx(), in the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path. Because the cipher suite string was unacceptable to GnuTLS, the context is either released by GnuTLS or never properly initialized. The error_exit: path tries to release that context, and causes the C library to abort the program as it detects a double free. Simply commenting the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx() masks the issue, but is obviously incorrect (as it affects the two other TLS implementations too). My suggested patch is to use the configured cipher suite string when creating the new TLS context, instead of "NORMAL" as is currently done, in openldap/libraries/libldap/tls_g.c:tlsg_ctx_new(). If there is a problem with the cipher suite priority string, the initial context is torn down, and caught earlier in openldap/libraries/libldap/tls2.c, avoiding the crash. (However, the cipher suite string will be parsed twice.) There seem to be numerous unhandled bug reports in various distributions and applications, including http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg which are quite tricky to investigate, as the actual bug occurs deep in libldap. Only user checks with a patched libldap will prove whether these are actually caused by this bug or not. It is very easy to assume it is an application bug, due to the symptoms and pretty limited circumstances. Recap: libldap + GnuTLS, application using ldap_start_tls, and any cipher suite string not acceptable to GnuTLS will cause libldap to crash due to a double free.
jouko.orava@iki.fi wrote: > Full_Name: Jouko Orava > Version: 2.4.28, 2.4.33 > OS: Debian/Ubuntu > URL: > Submission from: (NULL) (82.181.197.37) > > > If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4 crashes in > ldap_start_tls_s() due to a double free. See > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353 > for my original bug submission, including a suggested patch, > https://launchpadlibrarian.net/129174364/openldap-ciphersuite.patch > and a simple example ldapsearch-like program that can be used to test the > issue. This is now fixed in git master. > > This bug is not critical, since using a valid GnuTLS cipher suite does work, for > example "NORMAL" or "SECURE256". However, trying to use anything more specific > is exceedingly difficult -- basically trial and error, due to applications > crashing in libldap with an invalid one. > > The two other TLS implementations in OpenLDAP are not affected by this bug. > > The double free occurs in > openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx(), in the > ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the error_exit: path. Because > the cipher suite string was unacceptable to GnuTLS, the context is either > released by GnuTLS or never properly initialized. The error_exit: path tries to > release that context, and causes the C library to abort the program as it > detects a double free. > > Simply commenting the ldap_pvt_tls_ctx_free(lo->ldo_tls_ctx); call in the > error_exit: path in openldap/libraries/libldap/tls2.c:ldap_int_tls_init_ctx() > masks the issue, but is obviously incorrect (as it affects the two other TLS > implementations too). > > My suggested patch is to use the configured cipher suite string when creating > the new TLS context, instead of "NORMAL" as is currently done, in > openldap/libraries/libldap/tls_g.c:tlsg_ctx_new(). If there is a problem with > the cipher suite priority string, the initial context is torn down, and caught > earlier in openldap/libraries/libldap/tls2.c, avoiding the crash. (However, the > cipher suite string will be parsed twice.) > > There seem to be numerous unhandled bug reports in various distributions and > applications, including > http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg > which are quite tricky to investigate, as the actual bug occurs deep in libldap. > Only user checks with a patched libldap will prove whether these are actually > caused by this bug or not. It is very easy to assume it is an application bug, > due to the symptoms and pretty limited circumstances. > > Recap: libldap + GnuTLS, application using ldap_start_tls, and any cipher suite > string not acceptable to GnuTLS will cause libldap to crash due to a double > free. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
Hi, This ITS says "fixed in master" and appears to be in 2.5 as well. However 2.4 seems to still be affected. Is this fix a candidate for 2.4? thanks, Ryan
--On April 9, 2014 at 1:55:26 AM +0000 ryan@nardis.ca wrote: > Hi, > > This ITS says "fixed in master" and appears to be in 2.5 as well. > However 2.4 seems to still be affected. Is this fix a candidate for 2.4? It will be in 2.4.40 and is now in RE24. Thanks for catching that. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed