A flaw was found in the System Security Services Daemon (SSSD). The pampasskeychildreaddata() function within the PAM passkey responder fails to properly handle raw bytes received from a pipe. Because the data is treated as a NUL-terminated C string without explicit termination, it results in an out-of-bounds read when processed by functions like snprintf(). A local attacker could potentially trigger this vulnerability by initiating a crafted passkey authentication request, causing the SSSD PAM responder to crash, resulting in a local Denial of Service (DoS).

A flaw was found in sssd. When authenticating with a YubiKey, the SSSD PAM responder can crash due to a use-after-free vulnerability, where a memory pointer is incorrectly handled. A local attacker could exploit this flaw by manipulating smartcard or YubiKey contents, leading to a denial of service that disrupts authentication. This vulnerability also presents a potential for privilege escalation, although it is difficult to exploit.

A race condition flaw was found in sssd where the GPO policy is not consistently applied for authenticated users. This may lead to improper authorization issues, granting or denying access to resources inappropriately.

A flaw was found in SSSD. A local attacker can exploit this vulnerability by sending a specially crafted request to the autofs responder UNIX socket. Due to improper buffer offset calculation during request parsing, the service performs an out-of-bounds memory read. This flaw can cause the autofs responder process to crash, resulting in a denial of service (DoS).

A flaw was found in sssd. A local user can cause a Denial of Service (DoS) by exhausting the responder service's available file descriptors (system handles used for open connections). By opening and maintaining many concurrent connections to a responder socket while continuing to queue new connection attempts, an attacker can trigger an unthrottled retry loop. This condition leads to high CPU utilization and stalls the service, preventing legitimate identity and authentication requests from being processed.

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().

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.

sssctlruncommand() is a wrapper for running commands via a shell, using glibc's system() function call. sssctlcacheexpire() and sssctllogsfetch() allow user provided arguments, and pass them to sssctlruncommand() sssctl is limited to root user, however, if an administrator allows unprivileged users to provide arguments to the command (e.g.: via sudo), this could be used to elevate privileges via a shell injection.

Although there are no known default configuration where this flaw could be exploited, the admin could have manually created sudo rules to let regular users use sssctl commands, or could be tricked into running a specially crafted sssctl command.

References:

https://sssd.io/release-notes/sssd-2.6.0.html

It was found that sssd's sysdbsearchuserbyupnres() function before 1.16.0 did not sanitize requests when querying its local cache and was vulnerable to injection. In a centralized login environment, if a password hash was locally cached for a given user, an authenticated attacker could use this flaw to retrieve it.

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.

It was discovered that sssd versions prior to 2.0.0 did not properly restrict access to the infopipe according to the "alloweduids" parameter. If sensitive information were stored in the user directory, this could be inadvertently disclosed to local attackers.

A flaw was found in SSSD (System Security Services Daemon). A local attacker with privileges to connect to the PAM (Pluggable Authentication Modules) responder socket can send a specially crafted protocol request. If the pamappservices configuration is enabled and the service item is omitted from the request, a NULL pointer dereference can occur. This vulnerability leads to a denial of service, causing the PAM responder to crash and disrupt authentication services.

A flaw was found in sssd. A local unprivileged user could send a specially crafted request with a zero-length body to the Network Security Services (NSS) responder. This could lead to a denial-of-service condition, causing the NSS responder to become unstable or terminate. This vulnerability affects the availability of the system responder.

A flaw was found in SSSD. When configured with the LDAP access provider and ldapaccessorder including ppolicy or lockout, a fail-open condition in the LDAP ppolicy access check can occur if a user lookup returns zero results. This can incorrectly return success and cache an allow decision, permitting continued authorization for a deleted or deprovisioned user. A remote attacker with prior valid account context could exploit this to maintain access to information and potentially make limited modifications to resources that should no longer be available.

A flaw was found in SSSD. The sssnssprotocolfillinitgr() function in the NSS responder (src/responder/nss/nssprotocolgrent.c) pre-allocates the reply packet for all group entries using ssspacketgrow() but does not shrink the packet when groups are skipped (non-POSIX, incomplete, or filtered groups). ssspacketgrow() uses tallocreallocsize(), which does not zero-fill newly allocated memory. The trailing unwritten bytes therefore contain uninitialized heap data from the sssdnss process and are transmitted to the client at the grown packet length. A local attacker can exploit this by sending SSSNSSINITGR (0x0026) requests to the world-writable NSS responder socket (/var/lib/sss/pipes/nss), receiving uninitialized heap content in the reply tail. Through heap grooming (for example, a preceding getpwnam query), the leak can disclose other users' cached directory records and process heap pointers. The leaked data is limited to the sssdnss heap (directory-level information); credentials reside in separate sssdpam and sssdbe processes. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. The sssnssprotocolparseaddr() function in the NSS responder (src/responder/nss/nssprotocol.c) extracts a 32-bit addrlen value from the client request but only validates that the body is at least 8 bytes, without checking that addrlen fits within the remaining packet body. This unvalidated length is passed through to tallocmemdup() in cachereqdatacreate(), which copies addrlen bytes from the small request buffer, causing a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable NSS responder socket (/var/lib/sss/pipes/nss) and sending a SSSNSSGETHOSTBYADDR (0x0053) request with a large addrlen value and a valid address family payload so that inetntop() succeeds. Successful exploitation crashes the sssdnss responder, causing a denial of service for NSS name resolution. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

A flaw was found in SSSD. When configured to use Microsoft Entra ID, search inputs are not properly sanitized before being incorporated into directory query filters. A local user can exploit this vulnerability by submitting a crafted lookup request, manipulating the query logic to cause unauthorized information disclosure from the directory.

A flaw was found in SSSD. In trust-enabled identity management environments, SSSD evaluates Host-Based Access Control (HBAC) rules by stripping domain qualifiers and comparing only short usernames. An authenticated user in a trusted domain who shares the same username as an authorized local account can bypass access policies and gain unauthorized access to protected services or hosts.

A flaw was found in SSSD (System Security Services Daemon). When Identity Provider (IdP) authentication is enabled, pre-authentication requests retain state in memory without being cleared or timed out. A local attacker can repeatedly initiate authentication flows without completing them, causing unbounded memory consumption. This memory exhaustion can lead to a Denial of Service (DoS) by degrading or terminating SSSD authentication services.

A flaw was found in SSSD. A local user can trigger a Denial of Service (DoS) by exploiting a race condition in the autofs responder between asynchronous enumeration completion and map invalidation. By repeatedly sending concurrent map enumeration and invalidation requests, an attacker can cause memory to leak, leading to excessive memory consumption that can disrupt or crash the autofs service.

A flaw was found in sssd. This vulnerability allows a local user to cause a Denial of Service (DoS) by submitting a specially crafted passkey authentication token that lacks null terminators. The authentication service reads past the end of the provided memory buffer, causing the process to crash and disrupting authentication services.

A flaw was found in SSSD. In configurations where the autofs responder service is enabled, memory allocated during successful request processing is not released until the client connection terminates. A local attacker can exploit this vulnerability by maintaining an open connection and repeatedly submitting valid requests, leading to memory exhaustion and a Denial of Service (DoS).

A flaw was found in SSSD. A local user can cause a denial of service (DoS) by disrupting system authentication services. When handling Generic Security Services Application Programming Interface (GSSAPI) authentication in the Pluggable Authentication Module (PAM) responder, cached connection state is freed upon completion without clearing the reference pointer. An attacker can exploit this by sending an additional request over the same connection, causing the service to access invalid memory and unexpectedly terminate.

A flaw was found in SSSD. An unprivileged local user can repeatedly request master automount map updates through the autofs responder due to missing authorization checks. This triggers global cache invalidation and forces repeated lookups to backend directory providers, leading to a Denial of Service (DoS) from degraded automount availability and elevated resource consumption.

A memory leak was found in the sssdpacplugin (sssdpacplugin.so library), which is distributed with the sssdclient package.

Original report with additional details:

https://fedorahosted.org/sssd/ticket/2803

Patch:

https://fedorahosted.org/sssd/attachment/ticket/2803/0001-Fix-memory-leak-in-sssdpacverify.patch

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.

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.

It was reported [1] that SSSD improperly expanded group membership when it encountered a non-POSIX group in the group membership chain. For instance:

user -> posixgroup1 -> nonposixgroup -> posixgroup2

With the group memberships noted above, SSSD should include the user as a member of both posixgroup1 and posixgroup2, however due to the position of the non-POSIX group, SSSD halts processing at it and never reaches posixgroup2, leaving the user as a member of posixgroup1 and not posixgroup2.

SSSD has the capability to set a 'deny' ACL for both users and groups, so in a situation like that illustrated above, if posixgroup2 was present in a 'deny' ACL, the user would be granted access because they are not shown as having membership in the denied group. This could grant unintended access to certain users in an environment where non-POSIX groups are used in addition to POSIX groups.

There is currently no patch to correct this issue.

[1] https://lists.fedorahosted.org/pipermail/sssd-devel/2014-May/019495.html