FreeIPA supports the Kerberos PKINIT protocol extension (RFC 4556). PKINIT enables a client to authenticate to the KDC using an X.509 certificate and the corresonding private key, rather than a passphrase or keytab. FreeIPA uses mapping rules to map a certificate presented during a PKINIT authentication request to the corresponding principal. The mapping filter is vulnerable to LDAP filter injection. The search result can be influenced by values in the certificate, which may be attacker controlled. In the most extreme case, an attacker could gain control of the admin account, leading to full domain takeover.
FreeIPA is not vulnerable in its default configuration.
The problem is in libssscertmap, which is part of SSSD. FreeIPA servers use this library in ipakdb Kerberos plugin implementation.
The issue was introduced in SSSD 1.15.3 (when libssscertmap was introduced) and resolved in SSSD 2.3.1.
A vulnerability was found in sssd where, if a user was configured with no home directory set, sssd would return '/' (the root directory) instead of '' (the empty string / no home directory). This could impact services that restrict the user's filesystem access to within their home directory through chroot().
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.
Sebastian Krahmer discovered that it was possible to make sssd hang forever inside a loop in the pamparseindatav2() function of SSSD's PAM responder by using a carefully crafted packet to sssd. This could be exploited by a local attacker to crash sssd and prevent other legitimate users from logging into the system.
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer for reporting this issue.
A flaw was introduced in SSSD 1.5.0 that, under certain conditions, would have sssd overwrite a cached password with the filename of the kerberos credential store (defined by krb5ccachetemplate in sssd.conf). This could allow an attacker to gain access to an account without knowing the password if they knew the cached-credential string.
This flaw does not affect earlier versions of SSSD that did not have support for automatic ticket renewal services.
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.
The Simple Access Provider in System Security Services Daemon (SSSD) 1.9.0 through 1.9.4, when the Active Directory provider is used, does not properly enforce the simpledenygroups option, which allows remote authenticated users to bypass intended access restrictions.
A flaw was found in sssd Group Policy Objects implementation. When the GPO is not readable by SSSD due to a too strict permission settings on the server side, SSSD will allow all authenticated users to login instead of denying access.
sssd versions from 1.13.0 to before 2.0.0 did not properly restrict access to the infopipe according to the "alloweduids" configuration parameter. If sensitive information were stored in the user directory, this could be inadvertently disclosed to local attackers.
The UNIX pipe which sudo uses to contact SSSD and read the available sudo rules from SSSD has too wide permissions, which means that anyone who can send a message using the same raw protocol that sudo and SSSD use can read the sudo rules available for any user.