I plan to change the status of this bug for 12.04 (precise) and 14.04 (trusty) to Won't Fix. In this comment I want to explain why I came to this decision.
This bug had CVE-2013-4449 linked to it. I don't think that this CVE is relevant because the patch proposed in this bug doesn't resolve the issue mentioned in the description of this CVE. I proved that by using the following repro script: http://pastebin.ubuntu.com/10764620/ This script is derived from the repro case provided in the debian bug for CVE-2013-4449: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729367#22 [!] Please note that this CVE can be reliably reproduced only on multicore machine (e.g. you can't use m1.small cloud instance). Some form of race condition takes place and your chances are much higher on multicore. When CVE-2013-4449 is resolved this script should print 'Finished' at the end of execution. When CVE is still here it prints 'No server found on localhost:389 <attempt>'. 'No server found' means that slapd crashed and can't be accessed via network and '<attempt>' is a number of iteration when slapd crashed (it usually takes from 3 to 15 iterations because some form of race condition needs to take place). WITH and WITHOUT the proposed patch I get 'No server found' message on 12.04 (precise) and 14.04 (trusty). It means that patch doesn't fix CVE-2013-4449. Patch doesn't fix CVE-2013-4449 but it still can fix the issue mentioned in the bug description (incorrect cipher suite string leads to a crash). That's true but I don't think that we want to update 12.04 (precise) and 14.04 (trusty). ANY update may lead to unpredictable regressions (see https://wiki.ubuntu.com/StableReleaseUpdates) and the profit of patching should exceed the amount of potential issues it may create. OpenLDAP is an important infrastructural component and we need to have a very good reason to update it. I don't see such a reason. Client may crash itself by passing incorrect cipher suite to the API. While that's sad, it doesn't crash slapd itself and doesn't create any inconveniences to other users. This looks like a good fix for a development release but not stable release. Please let me know if you have any objections or additional information about this bug. We're open to discussion and can re-open this bug if needed. Thanks to Jouko Orava and others for opening this bug and taking part in the discussion. ** Bug watch added: Debian Bug tracker #729367 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729367 ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-4449 -- 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: In Progress Status in openldap source package in Trusty: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
