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. 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. 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. 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.
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
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
Ted Brunell reported that SSSD, when authenticating against an LDAP server that allows unauthenticated binds, would authenticate users providing an empty password to any service using pamauthenticate (such as the GNOME screensaver). This could allow a local or remote attacker to gain access to an account without knowing the victim's password.
This flaw can only be exploited if the directory server allows unauthenticated binds, because the directory server will return that the bind was successful if no password is provided.
Acknowledgements:
Red Hat would like to thank Ted Brunell for reporting this issue.
A flaw was found in SSSD version 1.9.0. The SSSD's access-provider logic causes the result of the HBAC rule processing to be ignored in the event that the access-provider is also handling the setup of the user's SELinux user context.
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.