Bug 514057 (CVE-2009-2410)

Summary: CVE-2009-2410 If internal sssd user has no password set, the user can ssh to the sssd client with any supplied password
Product: [Fedora] Fedora Reporter: Jenny Galipeau <jgalipea>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 11CC: bressers, jhrozek, sbose, security-response-team, sgallagh, ssorce
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.4.1-3.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-29 17:32:10 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Patch to ensure proper return from password check
none
Patch to ensure proper return from password check none

Description Jenny Galipeau 2009-07-27 15:15:09 EDT
Description of problem:
If a user is added to the SSSD BE database, but no password is set.  The user can ssh to the SSSD configured client and enter any password and get in.  

TESTED CONFIGURATION

system-auth configuration:

auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok
auth        sufficient    pam_sss.so use_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_sss.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok use_authtok
password    sufficient    pam_sss.so use_first_pass
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_unix.so
session     required      pam_sss.so


sssd configuration:

[services]
description =  Local Service Configuration
activeServices = nss, pam
reconnection_retries = 3

[services/nss]
description = NSS Responder Configuration
filterGroups = root
filterUsers = root
debug-level = 4

[services/dp]
description = Data Provider Configuration
debug-level = 4

[services/pam]
description = PAM Responder Configuration

[services/monitor]
description = Service Monitor Configuration

[domains]
description = Domains served by SSSD
domains = LOCAL

[domains/LOCAL]
description = LOCAL Users domain
enumerate = 1
minId = 1000
maxId = 1010
legacy = FALSE
magicPrivateGroups = TRUE
provider = local

Version-Release number of selected component (if applicable):
sssd-0.4.1-1.fc11.i586

How reproducible:
always

Steps to Reproduce:
1. yum install sssd
2. edit system-auth (as above) and nsswitch.conf as required
3. modify /etc/sssd/sssd.conf as above
4. service start sssd
5. sss_useradd -u 1000 -h /home/myuser -b /bin/bash myuser
6. from a remote machine ssh to the sssd client machine
   sssh myuser@hostname.com
7. at password prompt enter anything you would like

Actual results:
ssh session is successful and user allowed machine access

Expected results:
password to be denied, user not allowed machine access

Additional info:

If you subsequently set the user password on the sssd client machine
 (passwd myuser)
a bad password denies access and the correct password allows access.
Comment 1 Stephen Gallagher 2009-07-28 07:51:15 EDT
Ok, this is a bit of a tricky bug to reproduce. The described behavior is unique to i586 (it does not occur on x86_64 systems).

Furthermore the bug only occurs when running the sssd daemonized (with the -D option). It does not manifest when running in debug mode.

Further investigation is needed.
Comment 2 Stephen Gallagher 2009-07-28 09:50:44 EDT
Created attachment 355410 [details]
Patch to ensure proper return from password check

Ok, I've tracked down the issue here. In the LOCAL authentication check, we evaluate whether the LOCAL backend has a password set for the user. It looks like there was a copy-paste error that resulted in us returning early from the authentication evaluation with a success code instead of an error code. I have now corrected it so that we explicitly set the return code to LDB_ERR_NO_SUCH_ATTRIBUTE when the password is missing.

Could someone from the security response team please review the attached patch? It should apply cleanly against the SSSD 0.4.1 SRPM sources in CVS.
Comment 3 Stephen Gallagher 2009-07-28 11:04:38 EDT
Created attachment 355424 [details]
 Patch to ensure proper return from password check

Replacing old patch with new one that lists CVE in the commit message.
Comment 4 Stephen Gallagher 2009-07-29 07:54:47 EDT
Built in Koji, submitted for stable.

http://koji.fedoraproject.org/koji/buildinfo?buildID=124518
Comment 5 Fedora Update System 2009-07-29 17:32:04 EDT
sssd-0.4.1-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.