(ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string

[jouko.orava@iki.fi]

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.