Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2010-2940 sssd: allows null password entry to authenticate against LDAP [fedora-all]|
|Product:||[Fedora] Fedora||Reporter:||Ted Brunell <ted.brunell>|
|Component:||sssd||Assignee:||Stephen Gallagher <sgallagh>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||jhrozek, rstrode, sbose, security-response-team, sgallagh, ssorce, vdanen|
|Fixed In Version:||sssd-1.2.1-27.el5||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||625122 (view as bug list)||Environment:|
|Last Closed:||2010-09-02 00:01:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||625122, 625189|
Description Ted Brunell 2010-08-09 15:52:16 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:
Comment 1 Ray Strode [halfline] 2010-08-13 11:46:40 EDT
This sounds like an SSSD problem
Comment 2 Stephen Gallagher 2010-08-13 12:00:46 EDT
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
Comment 3 Ray Strode [halfline] 2010-08-13 12:15:02 EDT
Ted, did you use authconfig to set things up or edit system-auth manually?
Comment 5 Stephen Gallagher 2010-08-13 13:35:29 EDT
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.
Comment 7 Stephen Gallagher 2010-08-16 13:49:13 EDT
Ted, please attach /etc/pam.d/system-auth This is likely to be the source of the issue, not SSSD.
Comment 9 Stephen Gallagher 2010-08-16 13:59:21 EDT
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
Comment 10 Ted Brunell 2010-08-16 14:01:10 EDT
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.
Comment 11 Stephen Gallagher 2010-08-16 15:41:51 EDT
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.
Comment 14 Stephen Gallagher 2010-08-18 10:24:36 EDT
According to these logs: (Tue Aug 17 09:56:27 2010) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x865590], connected, 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).
Comment 15 Ted Brunell 2010-08-18 11:40:23 EDT
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.
Comment 16 Stephen Gallagher 2010-08-18 11:57:12 EDT
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.
Comment 17 Fedora Update System 2010-08-24 12:35:07 EDT
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
Comment 18 Fedora Update System 2010-08-24 12:35:15 EDT
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
Comment 19 Stephen Gallagher 2010-08-24 12:37:25 EDT
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.
Comment 20 Fedora Update System 2010-08-24 12:38:49 EDT
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
Comment 21 Fedora Update System 2010-08-24 14:11:17 EDT
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
Comment 22 Fedora Update System 2010-08-24 19:02:27 EDT
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
Comment 23 Stephen Gallagher 2010-08-25 08:45:09 EDT
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.
Comment 24 Fedora Update System 2010-09-02 00:01:04 EDT
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.
Comment 25 Fedora Update System 2010-09-02 16:41:39 EDT
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.
Comment 26 Fedora Update System 2010-09-02 16:44:30 EDT
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.
Comment 27 Fedora Update System 2010-09-08 12:29:47 EDT
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.