Bug 753639
Summary: | sssd_nss crashes when passed invalid UTF-8 for the username in getpwnam() | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ola Thoresen <redhat> | ||||
Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 16 | CC: | jamescape777, jhrozek, sbose, sgallagh, ssorce | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | abrt_hash:7be47f80fa1ecea9caea7480a1a73663c2dea891 | ||||||
Fixed In Version: | sssd-1.6.4-1.fc16 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 753842 (view as bug list) | Environment: | |||||
Last Closed: | 2012-05-30 14:16:04 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 753842, 758168 | ||||||
Attachments: |
|
Description
Ola Thoresen
2011-11-13 22:33:29 UTC
Can you attach the core file as well? I'd like to check if the DBus connection was still alive (!= NULL) when sssd_nss crashed. Also, is this the only crash? Was there any sssd_be crash by chance? Could you also include your (sanitized) sssd.conf? It seems from the logs that "be" did not crash, but was shut down (by systemd?) after nss had crashed a few times: As you can see, sssd was running fine for a few hours, then stared crashing repeatedly: Nov 13 16:06:41 poseidon sssd[pam]: Starting up Nov 13 22:35:44 poseidon abrt[19152]: saved core dump of pid 1027 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2011-11-13-22:35:44-1027 (1048576 bytes) Nov 13 22:35:45 poseidon sssd[nss]: Starting up Nov 13 22:36:05 poseidon abrt[19227]: saved core dump of pid 19159 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2011-11-13-22:36:05-19159 (946176 bytes) Nov 13 22:36:06 poseidon sssd[nss]: Starting up Nov 13 22:36:14 poseidon abrt[19267]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 22:36:15 poseidon sssd[nss]: Starting up Nov 13 22:36:23 poseidon abrt[19289]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 22:36:24 poseidon sssd[nss]: Starting up Nov 13 22:36:24 poseidon abrt[19291]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:04:43 poseidon sssd[be[default]]: Shutting down Nov 13 23:04:44 poseidon sssd[pam]: Shutting down Nov 13 23:04:44 poseidon sssd: Starting up Nov 13 23:04:44 poseidon systemd[1]: Failed to read PID file /var/run/sssd.pid after start. The service might be broken. Nov 13 23:04:44 poseidon sssd[be[default]]: Starting up Nov 13 23:04:45 poseidon sssd[nss]: Starting up Nov 13 23:04:45 poseidon sssd[pam]: Starting up Nov 13 23:05:41 poseidon abrt[23635]: saved core dump of pid 23454 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2011-11-13-23:05:40-23454 (1069056 bytes) Nov 13 23:05:42 poseidon sssd[nss]: Starting up Nov 13 23:05:44 poseidon abrt[23662]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:05:45 poseidon sssd[nss]: Starting up Nov 13 23:05:51 poseidon abrt[23680]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:05:52 poseidon sssd[nss]: Starting up Nov 13 23:05:54 poseidon abrt[23692]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:05:55 poseidon sssd[nss]: Starting up Nov 13 23:05:57 poseidon abrt[23700]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:07:00 poseidon sssd[be[default]]: Shutting down This was going on (requiring a manual restart after the shutdowns) for about 30 minutes, and it has been running fine again since then: (timestamps are CET, so that means it was last restarted about 16 hours ago) Nov 13 23:38:02 poseidon abrt[30619]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:38:03 poseidon sssd[nss]: Starting up Nov 13 23:38:04 poseidon abrt[30637]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:38:05 poseidon sssd[nss]: Starting up Nov 13 23:38:10 poseidon abrt[30666]: saved core dump of pid 30638 (/usr/libexec/sssd/sssd_nss) to /var/spool/abrt/ccpp-2011-11-13-23:38:10-30638 (946176 bytes) Nov 13 23:38:11 poseidon sssd[nss]: Starting up Nov 13 23:38:12 poseidon abrt[30692]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:38:13 poseidon sssd[nss]: Starting up Nov 13 23:38:14 poseidon abrt[30700]: not dumping repeating crash in '/usr/libexec/sssd/sssd_nss' Nov 13 23:39:01 poseidon sssd[be[default]]: Shutting down Nov 13 23:39:01 poseidon sssd[pam]: Shutting down Nov 13 23:39:01 poseidon systemd[1]: Failed to read PID file /var/run/sssd.pid after start. The service might be broken. Nov 13 23:39:01 poseidon sssd: Starting up Nov 13 23:39:01 poseidon sssd[be[default]]: Starting up Nov 13 23:39:01 poseidon sssd[pam]: Starting up Nov 13 23:39:01 poseidon sssd[nss]: Starting up Created attachment 533549 [details]
coredump
[domain/default] sssd.conf is quite simple (but I do use LDAP) debug_level = 5 ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=nytt,dc=no krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://localhost/ ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt ldap_default_bind_dn = cn=config ldap_default_authtok = XXXXXXXXXXX [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] Ok, I've traced the problem. What's happening is that some client app is passing us a username for getpwnam() that contains invalid UTF-8. Internally, when we try to pass this to the data provider over the D-BUS protocol, libdbus is failing the test _dbus_check_is_valid_utf8("ad\351la\357d"). We probably need to sanitize the requests earlier in the process, so that users that will never be valid (such as this) are just kicked out. Upstream ticket: https://fedorahosted.org/sssd/ticket/1088 If that's correct, it is rather important, as any network-enabled service can then be used to DoS any server, by just providing an invalid username... Thanks for a the fast repsonse. Fortunately, it's not really a DoS as the SSSD auto-restarts the NSS responder. It's still a serious crash issue though. Thanks for helping us identify it! Package: sssd-1.6.3-1.fc16 Architecture: x86_64 OS Release: Fedora release 16 (Verne) Comment ----- Seems to happen randomly This bug happens quite often, and it will make sssd stop working (until restarted manually). Not every time, but a few times a day no users can log in until we issue systemctl sssd.service restart We have identified a fix upstream, but the fix appears to be also revealing another latent bug in the code. It will take another day or two to get a fix out. Thank you for the bug report. sssd-1.6.4-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/sssd-1.6.4-1.fc16 Package sssd-1.6.4-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.6.4-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-17349/sssd-1.6.4-1.fc16 then log in and leave karma (feedback). sssd-1.6.4-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. I just got this crash a minute ago with 1.8.1-8 from F16 updates-testing. (In reply to comment #16) > I just got this crash a minute ago with 1.8.1-8 from F16 updates-testing. Unlikely to be the exact same crash. Can you file a bug with ABRT? I did, it marked it as a dup of this bug. Can you attach the backtrace to this ticket? That's very serious if we regressed this somehow. Reopening. Re-closing. We haven't gotten any new information for two months. |