Red Hat Bugzilla – Bug 622583
CVE-2010-2940 sssd: allows null password entry to authenticate against LDAP [fedora-all]
Last modified: 2010-09-08 12:29:56 EDT
Description of problem: I have several F13 boxes installed and authenticating via LDAP to CentOS Directory Server. When the screen is manually locked (System->Lock Screen), the screen can be unlocked without the use of a password - just hit enter. This same setup is working fine with Fedora12 x86_64 Version-Release number of selected component (if applicable): Fedora 13 x86_64 (Stock - no updates) CentOS Direcotry Server ver 8.0 How reproducible: All Fedora 13 boxes are having this problem. Steps to Reproduce: 1. Install F13 2. Configure LDAP authentication with SSSD enabled. 3. Lock Screen manually Actual results: Screeen unlocks allowing the user who hit enter access to the desktop. Expected results: Unlocking requires a password to be entered before unlocking the screen. Additional info:
This sounds like an SSSD problem
I can't reproduce this issue on my Fedora 13 system. Please identify the version of sssd installed on the system ('rpm -q sssd') along with the contents of /etc/pam.d/gnome-screensaver /etc/pam.d/system-auth /etc/sssd/sssd.conf
Ted, did you use authconfig to set things up or edit system-auth manually?
SSSD 1.2.2 is actually identical to RHEL6's version of SSSD 1.2.1. We just did a new upstream release with the patches we made to RHEL6. However, it's worth noting that the original reporter describes "Fedora 13 x86_64 (Stock - no updates)", which would imply that he's actually running SSSD 1.1.1 for this. So I need to bring up a VM and test that out, to confirm whether there WAS a problem and whether it is incidentally solved in the updates. However, given that this problem isn't present during initial login, and the codepath in SSSD is identical at that point, I'm inclined to believe that there's something wrong in his /etc/pam.d/system-auth file, rather than a bug in SSSD.
Created attachment 438994 [details] sssd.conf
Ted, please attach /etc/pam.d/system-auth This is likely to be the source of the issue, not SSSD.
Created attachment 438999 [details] system-auth
Comment on attachment 438999 [details] system-auth I'm not sure if it's relevant, but you have a typo here: account required pam_unix.so broken shadow That should be broken_shadow
I had to transcribe the file due to security requirements - that is indeed a typo. The systems are installed via a kickstart which contains the following authconfig line and the sssd.conf file that was previously attached. authconfig --enableshadow --enablemd5 --passalgo=md5 --enableldap --enableldapauth --ldapserver=ldaps://ldap.xxx.yyy.zzz --ldapbasedn=dc=xxx,dc=yyy,dc=zzz --enablemkhomedir --updateall --ldaploadcacert=http://www/cacert.asc --enablessd --enablessdauth As a workaround, I found that replacing /lib64/security/pam_sss.so by linking it to pam_ldap.so, the screen lock problem is gone.
I cannot reproduce this issue. I spun up a pristine Fedora 13, x86_64 system, set up SSSD 1.1.1-3 on it and logged in with an LDAP user. I then locked the screen and was not able to unlock it with anything but the correct password. As best I can tell, there's something else going on in your environment, unrelated to SSSD. To make absolutely sure, could you add 'debug_level = 9' to the [pam] and [domain/default] sections of your SSSD and attempt to reproduce the issue. Then please sanitize those logs and attach them, so I can see what is happening.
Created attachment 439390 [details] sssd_default.log
Created attachment 439391 [details] sssd_pam.log
According to these logs: (Tue Aug 17 09:56:27 2010) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x865590], connected[1], ops[0x876f70], ldap[0x863680] (Tue Aug 17 09:56:27 2010) [sssd[be[default]]] [simple_bind_done] (5): Server returned no controls. (Tue Aug 17 09:56:27 2010) [sssd[be[default]]] [simple_bind_done] (3): Bind result: Success(0), (null) SSSD attempted to bind against the LDAP server as expected. The LDAP server replied that the bind attempt was successful. I'd say this bug is on your server, not our client. Install the openldap-clients and try this: ldapsearch -x -H ldaps://ldap.xxx.yyy.zz -b dc=xxx,dc=yyy,dc=zzz -D uid=myaccount,ou=People,dc=xxx,dc=yyy,dc=zzz -w "" uid=myaccount If that returns the myaccount results, then your server is configured to allow unauthenticated binds (and you should report this to your IT department immediately, as it is a security vulnerability).
Yes, the CentOS Directory Servers are configured for unauthenticated binds and has been that way for several years. Saying that the software is behaving properly when unlocking a screen without a password does not make much sense to me. If SSSD encounters an LDAP server that is not secure then it should not make the system that it is running on insecure. Being able to unlock a computer that is running SSSD without entering a password is not a good feature and passing it off as "not our fault" does not make me want to use it. We assumed that all was good with SSSD until one of the users stumbled upon the fact that he can unlock his screen without a password. For what it's worth, pam_ldap properly asks for a password when unlocking the computer using the same LDAP server. It'd be great is pam_sssd behaved in the same manner as pam_ldap in that a password is needed despite the configuration of the LDAP server. I will work on getting unatuthenticaed bind turned off on the Directory Servers and let you know the results. Can being prompted for a password when the LDAP server is allowing unauthenticated binds be passed on as a feature request? I cannot imagine that I am the only person out there running my servers this way. Thanks.
Agreed. We will add a new option to SSSD 'ldap_allow_unauthenticated_bind' which defaults to FALSE. I have opened upstream bug https://fedorahosted.org/sssd/ticket/604 to track this.
sssd-1.2.2-21.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/sssd-1.2.2-21.fc13
sssd-1.2.2-20.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/sssd-1.2.2-20.fc12
Just for the record, contrary to comment #16, we decided upstream that we were not going to make this an option, and instead would disallow zero-length passwords entirely.
sssd-1.3.0-30.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/sssd-1.3.0-30.fc14
sssd-1.2.1-27.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/sssd-1.2.1-27.el5
sssd-1.2.1-27.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update sssd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/sssd-1.2.1-27.el5
For the record, disregard comment #16. We removed this ticket upstream when we realized that this was a security issue so as not to break embargo accidentally.
sssd-1.3.0-30.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.2.2-20.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.2.2-21.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.2.1-27.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.