Bug 622583 - CVE-2010-2940 sssd: allows null password entry to authenticate against LDAP [fedora-all]
Summary: CVE-2010-2940 sssd: allows null password entry to authenticate against LDAP [...
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 625122 CVE-2010-2940
TreeView+ depends on / blocked
Reported: 2010-08-09 19:52 UTC by Ted Brunell
Modified: 2010-09-08 16:29 UTC (History)
7 users (show)

Fixed In Version: sssd-1.2.1-27.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 625122 (view as bug list)
Last Closed: 2010-09-02 04:01:14 UTC
Type: ---

Attachments (Terms of Use)
sssd.conf (529 bytes, text/plain)
2010-08-16 17:42 UTC, Ted Brunell
no flags Details
system-auth (1.15 KB, text/plain)
2010-08-16 17:53 UTC, Ted Brunell
no flags Details
sssd_default.log (133.90 KB, application/octet-stream)
2010-08-18 13:55 UTC, Ted Brunell
no flags Details
sssd_pam.log (28.67 KB, application/octet-stream)
2010-08-18 13:56 UTC, Ted Brunell
no flags Details

Description Ted Brunell 2010-08-09 19:52:16 UTC
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 15:46:40 UTC
This sounds like an SSSD problem

Comment 2 Stephen Gallagher 2010-08-13 16:00:46 UTC
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

Comment 3 Ray Strode [halfline] 2010-08-13 16:15:02 UTC
Ted, did you use authconfig to set things up or edit system-auth manually?

Comment 5 Stephen Gallagher 2010-08-13 17:35:29 UTC
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 6 Ted Brunell 2010-08-16 17:42:00 UTC
Created attachment 438994 [details]

Comment 7 Stephen Gallagher 2010-08-16 17:49:13 UTC
Ted, please attach

This is likely to be the source of the issue, not SSSD.

Comment 8 Ted Brunell 2010-08-16 17:53:35 UTC
Created attachment 438999 [details]

Comment 9 Stephen Gallagher 2010-08-16 17:59:21 UTC
Comment on attachment 438999 [details]

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 18:01:10 UTC
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 19:41:51 UTC
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 12 Ted Brunell 2010-08-18 13:55:49 UTC
Created attachment 439390 [details]

Comment 13 Ted Brunell 2010-08-18 13:56:37 UTC
Created attachment 439391 [details]

Comment 14 Stephen Gallagher 2010-08-18 14:24:36 UTC
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).

Comment 15 Ted Brunell 2010-08-18 15:40:23 UTC
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.


Comment 16 Stephen Gallagher 2010-08-18 15:57:12 UTC
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 16:35:07 UTC
sssd-1.2.2-21.fc13 has been submitted as an update for Fedora 13.

Comment 18 Fedora Update System 2010-08-24 16:35:15 UTC
sssd-1.2.2-20.fc12 has been submitted as an update for Fedora 12.

Comment 19 Stephen Gallagher 2010-08-24 16:37:25 UTC
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 16:38:49 UTC
sssd-1.3.0-30.fc14 has been submitted as an update for Fedora 14.

Comment 21 Fedora Update System 2010-08-24 18:11:17 UTC
sssd-1.2.1-27.el5 has been submitted as an update for Fedora EPEL 5.

Comment 22 Fedora Update System 2010-08-24 23:02:27 UTC
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 12:45:09 UTC
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 04:01:04 UTC
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 20:41:39 UTC
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 20:44:30 UTC
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 16:29:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.