REDHAT-BUG-2479271: Medium severity redhat/sssd vulnerability

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Access-Control Bypass: shadowExpire=0 Not Treated as Expired in LDAP Shadow Expire Check: an LDAP account marked with shadowExpire=0 can still pass SSSD's shadow-based expiration check and continue authenticating in affected configurations. Requirements to exploit: The attacker needs valid credentials for the affected LDAP account, and the deployment must explicitly enable the LDAP shadow-expire path with accessprovider = ldap, ldapaccessorder including expire, and ldapaccountexpirepolicy = shadow; directory-side controls that independently reject the account would reduce or prevent the observed impact. Component affected: sssd-2.12.0-1.el10, LDAP access-control expire path in src/providers/ldap/sdapaccess.c, sdapaccountexpiredshadow() Version affected: sssd-2.12.0-1.el10 when configured with accessprovider = ldap, ldapaccessorder including expire, and ldapaccountexpirepolicy = shadow Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N - 5.4 (MEDIUM) AV:N - Reachable through remote authentication services that rely on PAM/SSSD in affected deployments. AC:L - The bypass follows directly from a single comparison in the shadow-expire check. PR:L - Exploitation requires valid credentials for the expired account. UI:N - No separate user interaction is required once the attacker attempts authentication. S:U - The flaw affects the same authorization scope that evaluates account expiry. C:L - It can preserve unauthorized access to information available to the expired account. I:L - It bypasses intended account-expiration enforcement and can preserve access that should have been revoked. A:N - No direct service outage or denial-of-service condition is established. Impact: Moderate. This is a real access-control bypass that can allow continued use of an account after administrators intended it to be expired, but it is configuration-dependent, requires valid account credentials, and does not demonstrate unauthenticated compromise, code execution, or privilege escalation beyond the affected account. Under Red Hat's severity guidance, that is more consistent with Moderate than Important. Embargo: no Reason: The issue depends on a specific LDAP shadow-expiry configuration and an already valid account, and affected deployments can mitigate immediately by avoiding shadowExpire=0 or enforcing expiry on the directory side. Acknowledgement: Aisle Research Vulnerability Details: In the LDAP access-control expire path, sdapaccountexpiredshadow() only denies the account when spexpire > 0: c today = (long) (time(NULL) / (60 60 24)); if (spexpire > 0 && today >= spexpire) { ret = pamaddresponse(pd, SSSPAMSYSTEMINFO, sizeof(SHADOWEXPIREMSG), (const uint8t ) SHADOWEXPIREMSG); if (ret != EOK) { DEBUG(SSSDBGCRITFAILURE, "pamaddresponse failed.\n"); } return ERRACCOUNTEXPIRED; } stringtoshadowpwdays() accepts 0 as a valid parsed value and uses -1 as the no-expiration sentinel, so 0 is not filtered out as an unset value. Because the access check only expires values strictly greater than 0, shadowExpire=0 falls through and access is granted instead of denied. A related LDAP authentication path checks spexpire != -1, which treats 0 as expired and highlights the inconsistency in how the shadow expiration value is handled. Steps to reproduce: 1. Configure an SSSD domain with accessprovider = ldap, ldapaccessorder = expire, and ldapaccountexpirepolicy = shadow. 2. Ensure the target LDAP user has shadowExpire: 0 and otherwise valid authentication credentials. 3. Authenticate to a PAM service backed by SSSD as that user. 4. Observe that access is granted in the affected configuration instead of failing with an expired-account result such as ERRACCOUNTEXPIRED or PAMACCTEXPIRED. Mitigation: Until a fix is available, do not rely on shadowExpire=0 to expire accounts in deployments using ldapaccountexpirepolicy = shadow. Use a positive past day value for shadowExpire, or enforce account disablement or expiration through directory-side controls that do not depend solely on this client-side check. Proposed Fix: The minimal correction is to treat 0 as expired and keep -1 as the only non-expiring sentinel in this code path. diff diff --git a/src/providers/ldap/sdapaccess.c b/src/providers/ldap/sdapaccess.c — a/src/providers/ldap/sdapaccess.c +++ b/src/providers/ldap/sdapaccess.c @@ -420,7 +420,7 @@ static errnot sdapaccountexpiredshadow(struct pamdata pd, if (spexpire > 0 && today >= spexpire) { + if (spexpire >= 0 && today >= spexpire) { ret = pamaddresponse(pd, SSSPAMSYSTEMINFO, sizeof(SHADOWEXPIREMSG), (const uint8t ) SHADOWEXPIREMSG);

------ This report was generated using AI technology. Always review AI-generated content prior to use