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