touch-packages team mailing list archive

[Ryan Tandy <1103353@xxxxxxxxxxxxxxxxxx>]

On Fri, Apr 10, 2015 at 04:30:32PM -0000, Harry Coin wrote:
>Steps to reproduce:
>1) Install older version that used openssl.
>2) Set up a cipher suite of any sort.
>3) Validate ldaps operation.
>4) "upgrade" using current version built against gnutls.
>5) Notice slapd won't start, complaining of double free, upgrade fails.

The nit-picker in me feels compelled to point out that the 
openssl→gnutls change invalidating existing TLSCipherSuite settings 
actually was dealt with, sort of:

http://anonscm.debian.org/cgit/pkg-
openldap/openldap.git/commit/?id=327fcec47c59ccb7de65747327730eabc5656969

(This would have been applied when upgrading to hardy.)

However, in 2.4.14 the cipher suite parser used for gnutls was changed, 
but this time there was no such upgrade handling:

http://www.openldap.org/its/?findid=6251
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256

AFAIK the latter change, not the former, would have introduced this when 
upgrading to jaunty (or for LTS users, from hardy to lucid).

FWIW, upstream explicitly documents in ldap.conf(5) that TLSCipherSuite 
settings are implementation dependent, and that openssl and gnutls 
ciphersuite strings are not compatible. Even after fixing the 
double-free, a manual "reconfigure ciphersuites for gnutls" step is 
required in the upgrade steps listed above...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1103353

Title:
  Invalid GnuTLS cipher suite strings causes libldap to crash

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Precise:
  Won't Fix
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap package in Debian:
  Fix Released

Bug description:
  If the cipher suite string is unacceptable to GnuTLS, libldap_r-2.4
  crashes due to a double free. GnuTLS is extremely picky about the
  cipher suite strings it accepts; as a first measure, try LDAP cipher
  suite string "SECURE256" or "NORMAL". If that stops the crash, then
  you have encountered this bug.

  Typically, the crash report begins with something like

  *** glibc detected *** APPLICATION: double free or corruption (!prev)
  /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc68cff0b96]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(+0x38769)[0x7fc68bb13769]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(+0x3570e)[0x7fc68bb1070e]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(ldap_pvt_tls_init_def_ctx+0x1d)[0x7fc68bb108ed]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(+0x35965)[0x7fc68bb10965]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(+0x35a6d)[0x7fc68bb10a6d]
  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2(ldap_int_tls_start+0x5d)[0x7fc68bb1149d]

  The actual double free happens 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.

  The root cause of the double free is lack of GnuTLS return value
  checks when calling gnutls_priority*() functions. The code simply
  assumes they succeed, and when GnuTLS fails to provide a valid context
  due to those failures, ldap_int_tls_init_ctx() tries to free the
  never-fully-initialized context.

  A simple fix is to create GnuTLS security contexts using the
  configured cipher suite string, instead of "NORMAL" as
  openldap/libraries/libldap/tls_g.c now does. If the cipher suite
  string is invalid, then do not create the context at all. This is
  caught earlier in ldap_int_tls_init_ctx(), and avoids the crash.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/+subscriptions