touch-packages team mailing list archive

[Oleg Strikov <oleg.strikov@xxxxxxxxxxxxx>]

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