This bugs affects libldap-2.4.-2, at least versions versions 2.4.28 (2.4.28-1.1ubuntu4) and 2.4.31 (2.4.31-1ubuntu2), when compiled against GnuTLS. The bug exists in latest openldap.org upstream versions from 2.4.28 to 2.4.33 at least; probably since they switched from custom parsing the cipher suite for GnuTLS to GnuTLS's own. Based on this upstream report, http://www.openldap.org/its/index.cgi/Incoming?id=6939#themesg
I suspect the bug has existed upstream at least since 2.4.25.
To reproduce, I used a simplified ldapsearch-like program, which connects to an ldap server (ldap:// URIs), then sets the desired priority (cipher suite) based on a command-line parameter, issues StartTLS to secure the connection, then does a simple anonymous search. If the cipher suite is not valid for GnuTLS, the program crashes in libldap_r-2.4-2. The test program is attached for easier bug verification. (Note: You need an LDAP server supporting StartTLS to connect to.)
It seems that in any application that relies on libldap parsing the cipher suite will crash the same way, when the cipher suite is not valid for GnuTLS, and the connection involves StartTLS. This includes at least sssd: put e.g. "ldap_tls_cipher_suite = FOOBAR" and "ldap_id_use_start_tls = True" in sssd.conf, and use an ldap:// URI, and sssd will crash.
Correct cipher suites for GnuTLS are very complex to construct; for example, to allow only AES and CAMELLIA 256-bit ciphers with 160 or 256-bit SHA MACs and RSA key exchange and any compression and any TLS version (excluding SSH3.0), one needs to use "'NONE:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+COMP-ALL:+AES-256-CBC:+CAMELLIA-256-CBC:+RSA:+SHA1:+SHA256".
If the Ubuntu OpenLDAP developers and users can confirm the bug, and that this patch fixes the issue, it would be easier to push the patch upstream. I do not currently use LDAP on my machines, as I only investigated the issue to help a friend. So, it does not matter to me whether the patch is accepted or not, or if the bug is further investigated or not. I'm very willing to help, though.
This bugs affects libldap-2.4.-2, at least versions versions 2.4.28 (2.4.28-1.1ubuntu4) and 2.4.31 (2.4.31-1ubuntu2), when compiled against GnuTLS. The bug exists in latest openldap.org upstream versions from 2.4.28 to 2.4.33 at least; probably since they switched from custom parsing the cipher suite for GnuTLS to GnuTLS's own. Based on this upstream report, www.openldap. org/its/ index.cgi/ Incoming? id=6939# themesg
http://
I suspect the bug has existed upstream at least since 2.4.25.
Based on the symptoms and crash reports, I strongly believe /bugs.launchpad .net/ubuntu/ +source/ openldap/ +bug/1026057 /bugs.launchpad .net/ubuntu/ +source/ libnss- ldap/+bug/ 1090554 bugs.debian. org/cgi- bin/bugreport. cgi?bug= 640384
https:/
https:/
http://
are all the same bug.
To reproduce, I used a simplified ldapsearch-like program, which connects to an ldap server (ldap:// URIs), then sets the desired priority (cipher suite) based on a command-line parameter, issues StartTLS to secure the connection, then does a simple anonymous search. If the cipher suite is not valid for GnuTLS, the program crashes in libldap_r-2.4-2. The test program is attached for easier bug verification. (Note: You need an LDAP server supporting StartTLS to connect to.)
It seems that in any application that relies on libldap parsing the cipher suite will crash the same way, when the cipher suite is not valid for GnuTLS, and the connection involves StartTLS. This includes at least sssd: put e.g. "ldap_tls_ cipher_ suite = FOOBAR" and "ldap_id_ use_start_ tls = True" in sssd.conf, and use an ldap:// URI, and sssd will crash.
Correct cipher suites for GnuTLS are very complex to construct; for example, to allow only AES and CAMELLIA 256-bit ciphers with 160 or 256-bit SHA MACs and RSA key exchange and any compression and any TLS version (excluding SSH3.0), one needs to use "'NONE: +VERS-TLS1. 2:+VERS- TLS1.1: +VERS-TLS1. 0:+COMP- ALL:+AES- 256-CBC: +CAMELLIA- 256-CBC: +RSA:+SHA1: +SHA256" .
If the Ubuntu OpenLDAP developers and users can confirm the bug, and that this patch fixes the issue, it would be easier to push the patch upstream. I do not currently use LDAP on my machines, as I only investigated the issue to help a friend. So, it does not matter to me whether the patch is accepted or not, or if the bug is further investigated or not. I'm very willing to help, though.