Red Hat Bugzilla – Bug 667349
Obfuscated passwords can kill LDAP provider if OpenLDAP uses NSS.
Last modified: 2016-10-10 12:34:39 EDT
Created attachment 471836 [details] sssd_LDAP.log Description of problem: If the obfuscated password cannot be decrypted, e.g. because by accident the clear text password was entered, the LDAP provider will die if TLS/SSL are used for id operations. Version-Release number of selected component (if applicable): sssd-1.5.1-0.2010122318git375e3e4.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure SSSD for native LDAP, make sure to use TLS/SSL for id operations. (refer "Additional info" section for config) 2. Set "ldap_default_authtok_type = obfuscated_password" 3. Set "ldap_default_authtok" to a random value or a correctly encoded wrong password. 4. Restart sssd. 5. Observe /var/log/messages Actual results: * LDAP provider opens a TLS/SSL connection to the server * LDAP provider fails to decrypt the password * LDAP provider dies while trying to close the connection In /var/log/messages: Jan 5 02:24:13 ibm-hs22-01 sssd[pam]: Shutting down Jan 5 02:24:13 ibm-hs22-01 sssd[nss]: Shutting down Jan 5 02:24:13 ibm-hs22-01 sssd[be[LDAP]]: Shutting down Jan 5 02:24:13 ibm-hs22-01 kernel: sssd_be[655]: segfault at 28 ip 00000031ff269e40 sp 00007fffa60c2db8 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:13 ibm-hs22-01 abrt[681]: saved core dump of pid 655 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-1294212253-655.new/coredump (1904640 bytes) Jan 5 02:24:13 ibm-hs22-01 abrtd: Directory 'ccpp-1294212253-655' creation detected Jan 5 02:24:13 ibm-hs22-01 abrtd: New crash /var/spool/abrt/ccpp-1294212253-655, processing Jan 5 02:24:14 ibm-hs22-01 sssd: Starting up Jan 5 02:24:15 ibm-hs22-01 sssd[be[LDAP]]: Starting up Jan 5 02:24:15 ibm-hs22-01 sssd[nss]: Starting up Jan 5 02:24:15 ibm-hs22-01 sssd[pam]: Starting up Jan 5 02:24:15 ibm-hs22-01 kernel: sssd_be[760]: segfault at 28 ip 00000031ff269e40 sp 00007fffab079758 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:15 ibm-hs22-01 abrt[763]: not dumping repeating crash in '/usr/libexec/sssd/sssd_be' Jan 5 02:24:16 ibm-hs22-01 sssd[be[LDAP]]: Starting up Jan 5 02:24:16 ibm-hs22-01 kernel: sssd_be[764]: segfault at 28 ip 00000031ff269e40 sp 00007fff64565c38 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:16 ibm-hs22-01 abrt[765]: not dumping repeating crash in '/usr/libexec/sssd/sssd_be' Jan 5 02:24:17 ibm-hs22-01 sssd[be[LDAP]]: Starting up Jan 5 02:24:17 ibm-hs22-01 kernel: sssd_be[792]: segfault at 28 ip 00000031ff269e40 sp 00007fff2b3c1f68 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:17 ibm-hs22-01 abrt[793]: not dumping repeating crash in '/usr/libexec/sssd/sssd_be' Jan 5 02:24:17 ibm-hs22-01 abrt[828]: saved core dump of pid 761 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-1294212257-761.new/coredump (770048 bytes) Jan 5 02:24:17 ibm-hs22-01 abrtd: Directory 'ccpp-1294212257-761' creation detected Jan 5 02:24:18 ibm-hs22-01 sssd[nss]: Starting up Jan 5 02:24:18 ibm-hs22-01 abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1294207718-32374) Jan 5 02:24:18 ibm-hs22-01 abrtd: Deleting crash ccpp-1294212257-761 (dup of ccpp-1294207718-32374), sending dbus signal Jan 5 02:24:19 ibm-hs22-01 sssd[be[LDAP]]: Starting up Jan 5 02:24:19 ibm-hs22-01 kernel: sssd_be[840]: segfault at 28 ip 00000031ff269e40 sp 00007fff7dcbf188 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:19 ibm-hs22-01 abrt[841]: saved core dump of pid 840 (/usr/libexec/sssd/sssd_be) to /var/spool/abrt/ccpp-1294212259-840.new/coredump (1822720 bytes) Jan 5 02:24:19 ibm-hs22-01 abrtd: Directory 'ccpp-1294212259-840' creation detected Jan 5 02:24:19 ibm-hs22-01 abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1294207715-32373) Jan 5 02:24:19 ibm-hs22-01 abrtd: Deleting crash ccpp-1294212259-840 (dup of ccpp-1294207715-32373), sending dbus signal Jan 5 02:24:20 ibm-hs22-01 sssd[nss]: Starting up Jan 5 02:24:21 ibm-hs22-01 sssd[be[LDAP]]: Starting up Jan 5 02:24:21 ibm-hs22-01 kernel: sssd_be[844]: segfault at 28 ip 00000031ff269e40 sp 00007fffe6292fd8 error 4 in libnss3.so[31ff200000+133000] Jan 5 02:24:21 ibm-hs22-01 abrt[845]: not dumping repeating crash in '/usr/libexec/sssd/sssd_be' Jan 5 02:24:22 ibm-hs22-01 sssd[nss]: Starting up Jan 5 02:24:24 ibm-hs22-01 sssd[nss]: Starting up Expected results: LDAP provider should not die while trying to close the connection. Additional info: Relevant section of sssd.conf: [domain/LDAP] ldap_tls_reqcert = never ldap_id_use_start_tls = False cache_credentials = False ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_cacert = /etc/openldap/cacerts/cacert.asc debug_level = 9 min_id = 1000 ldap_uri = ldaps://myldap.server.com:636 enumerate = True ldap_schema = rfc2307 ldap_default_bind_dn = uid=puser1,ou=People,dc=example,dc=com ldap_default_authtok_type = obfuscated_password ldap_default_authtok = Secret123
Upstream ticket: https://fedorahosted.org/sssd/ticket/762
Giving devel_ack. Crash bugs must be fixed.
sssd service starts up successfully with no crashes in /var/log/messages. Relevant sssd.conf: [domain/LDAP] ldap_uri = ldaps://sssdldap.redhat.com:636 cache_credentials = true enumerate = False entry_cache_timeout = 5400 ldap_tls_reqcert = never ldap_id_use_start_tls = False ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_cacert = /etc/openldap/cacerts/cacert.asc debug_level = 9 min_id = 1000 ldap_schema = rfc2307 ldap_default_bind_dn = uid=puser1,ou=People,dc=example,dc=com ldap_default_authtok_type = obfuscated_password ldap_default_authtok = Secret123 Relevant /var/log/messages: Mar 9 04:42:10 sun-v40z-01 sssd[be[default]]: Shutting down Mar 9 04:42:11 sun-v40z-01 sssd: Starting up Mar 9 04:42:12 sun-v40z-01 sssd[be[LDAP]]: Starting up Mar 9 04:42:12 sun-v40z-01 sssd[be[default]]: Starting up Mar 9 04:42:13 sun-v40z-01 sssd[be[LDAP]]: Starting up Mar 9 04:42:14 sun-v40z-01 sssd[be[LDAP]]: Starting up Mar 9 04:42:15 sun-v40z-01 sssd[be[LDAP]]: Starting up Mar 9 04:42:16 sun-v40z-01 sssd[be[LDAP]]: Starting up Mar 9 04:42:17 sun-v40z-01 sssd[nss]: Starting up Mar 9 04:42:17 sun-v40z-01 sssd[pam]: Starting up Mar 9 04:42:18 sun-v40z-01 sssd[nss]: Starting up Mar 9 04:42:19 sun-v40z-01 sssd[pam]: Starting up Mar 9 04:42:20 sun-v40z-01 sssd[nss]: Starting up Mar 9 04:42:21 sun-v40z-01 sssd[pam]: Starting up Mar 9 04:42:22 sun-v40z-01 sssd[nss]: Starting up Mar 9 04:42:23 sun-v40z-01 sssd[pam]: Starting up Mar 9 04:42:24 sun-v40z-01 sssd[nss]: Starting up Mar 9 04:42:25 sun-v40z-01 sssd[pam]: Starting up Verified: sssd-1.5.1-13.el6.x86_64
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0560.html
Not sure if this is linked, I have seen this issue in With the following OpenLDAP packages installed and OpenLDAP configured with SSL/TLS support, I'm able to obtain a crash every time I run a Nessus PCI scan against the system. openldap-2.4.40-9.el7_2.x86_64 nss-3.21.0-9.el7_2.x86_64 https://bugs.centos.org/view.php?id=11191 Do you have a fix for this ? Regards, Alan