System Security Services Daemon (SSSD) before 1.0.1, when the krb5 authprovider is configured but the KDC is unreachable, allows physically proximate attackers to authenticate, via an arbitrary password, to the screen-locking program on a workstation that has any user's Kerberos ticket-granting ticket (TGT); and might allow remote attackers to bypass intended access restrictions via vectors involving an arbitrary password in conjunction with a valid TGT.

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 pamenv.so auth sufficient pamfprintd.so auth sufficient pamunix.so nullok auth sufficient pamsss.so usefirstpass auth requisite pamsucceedif.so uid >= 500 quiet auth required pamdeny.so

account required pamunix.so brokenshadow account sufficient pamsss.so account sufficient pamlocaluser.so account sufficient pamsucceedif.so uid < 500 quiet account required pampermit.so

password requisite pamcracklib.so tryfirstpass retry=3 password sufficient pamunix.so sha512 shadow nullok useauthtok password sufficient pamsss.so usefirstpass password required pamdeny.so

session optional pamkeyinit.so revoke session required pamlimits.so session [success=1 default=ignore] pamsucceedif.so service in crond quiet useuid session sufficient pamunix.so session required pamsss.so

sssd configuration:

[services] description = Local Service Configuration activeServices = nss, pam reconnectionretries = 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. sssuseradd -u 1000 -h /home/myuser -b /bin/bash myuser 6. from a remote machine ssh to the sssd client machine sssh myuser 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.

Multiple out-of-buffer bounds read flaws were found in the way autofs and ssh service responders of sssd, a System Security Services Daemon, performed parsing of SSSD packet values. An attacker could provide a specially-crafted packet that, when processed by the autofs or ssh service responders of sssd would lead to sssd server crash (temporary denial of service).

This issue was found by Florian Weimer of Red Hat Product Security Team.

A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD, System Security Services Daemon, performed copying and removal of (user) directory trees.A local attacker, with permissions to write into directory of the victim, being actively / currently copied / removed via the sssd daemon facility, could use this flaw to conduct symbolic link attacks, leading to their ability to alter / remove directories outside of originally intended, to be modified, directory tree.

This issue was found by Florian Weimer of Red Hat Product Security Team.