A flaw was found in SSSD's IdP authentication provider. The evalaccesstokenbuf() function in src/providers/idp/idpautheval.c compares the authenticated user's OIDC subject identifier against the requested user's stored SYSDBUUID using strncmp() with the authenticated identifier's length as the count. This performs a prefix comparison rather than an exact match. An attacker whose complete IdP identifier is a strict prefix of a target user's identifier can authenticate as the target, gaining full access to the target's account, files, groups, and local authorization. With Keycloak's built-in LDAP provider (Import Users disabled), the identifier format f:<federationid>:<username> naturally produces prefix relationships for usernames like 'admin' and 'administrator'. No victim credential, interaction, or administrative role is required.

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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local Out-of-Bounds Read in PAM v1 Parser (pamparseindata) Causing Potential DoS: a local client that negotiates protocol v1 and sends an empty or truncated PAM request body can trigger an out-of-bounds read and may terminate the PAM responder, resulting in local denial of service. Requirements to exploit: Local access to the PAM responder UNIX socket, the ability to negotiate protocol v1 with SSSGETVERSION, and the ability to send a malformed SSSPAMAUTHENTICATE request body. No user interaction is required. If a deployment restricts PAM socket access more tightly than common configurations, practical exploitability is reduced. Component affected: sssd-2.12.0-1.el10 PAM responder in src/responder/pam/pamsrvcmd.c, function pamparseindata() Version affected: sssd-2.12.0-1.el10 Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.9 (LOW) AV:L - The issue is reachable only from a local client that can connect to the PAM responder UNIX socket. AC:L - Triggering the flaw requires only a malformed protocol v1 request body such as an empty or truncated message. PR:N - The vulnerable parser path itself does not require prior authentication, and common PAM socket deployments allow local clients to reach it; stricter socket ACLs would reduce practical risk. UI:N - No human interaction is needed once local socket access is available. S:U - The impact remains within the PAM responder's own security scope. C:N - The available evidence shows an out-of-bounds read, but not disclosure of sensitive data. I:N - No data modification, privilege gain, or integrity impact is established. A:L - The demonstrated outcome is potential local denial of service, but the available evidence does not show a consistently reliable high-impact crash in every malformed-input case. Impact: Moderate. This is a real local memory-safety flaw in a security-sensitive authentication responder, and malformed v1 requests can affect service availability. However, the available evidence supports local denial of service only, with no demonstrated confidentiality or integrity impact, and the failure appears less than maximally reliable, which places it below Red Hat's Important classification. Embargo: no Reason: The issue is local-only, the demonstrated impact is limited to availability, and the remediation is straightforward. Based on Red Hat guidance, this does not appear to require embargoed handling. Acknowledgement: Aisle Research Vulnerability Details: In the PAM responder's protocol v1 parser, pamparseindata() computes last = blen - 1 before validating blen, then repeatedly dereferences body[end++] without first proving end < blen. This creates two supported failure modes: blen == 0 underflows last to SIZEMAX, and truncated v1 string fields can advance end to or beyond the end of the supplied body before the terminator check occurs. c static int pamparseindata(struct pamdata pd, uint8t body, sizet blen) { sizet start; sizet end; sizet last; int ret; last = blen - 1; end = 0; / user name / for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; pd->logonname = (char ) &body[start]; ... } The same unchecked body[end++] pattern is then repeated while parsing service, tty, ruser, and rhost. Protocol version 1 remains registered, and the request dispatch path still selects pamparseindata() when v1 is negotiated, so the vulnerable parser remains reachable through the PAM responder. Based on the available evidence, the expected security effect is an out-of-bounds read that may cause responder termination or restart behavior depending on build hardening and runtime supervision; code execution, data disclosure, and privilege escalation are not established. Steps to reproduce: 1. Build or run the package with ASAN enabled, or run the PAM responder under a debugger. 2. Connect to the PAM responder UNIX socket, typically /var/lib/sss/pipes/pam in standard deployments. 3. Send SSSGETVERSION (0x0001) with body uint32(1) to negotiate protocol v1. 4. On the same connection, send SSSPAMAUTHENTICATE (0x00F1) with either an empty body (blen == 0) or a truncated v1 body that omits one or more required '\0' terminators. 5. Observe an ASAN invalid read or responder termination/restart behavior, depending on build and runtime conditions. Mitigation: Restrict local access to the PAM responder UNIX socket to trusted users where operationally possible. If protocol v1 requests can be avoided in the affected environment, that reduces exposure, but there is no complete mitigation short of patching the v1 parser to reject zero-length and truncated inputs before any out-of-bounds dereference occurs. Proposed Fix: Reject zero-length bodies before evaluating blen - 1, and check end >= blen before each body[end] dereference while parsing the v1 NUL-terminated fields. diff diff --git a/src/responder/pam/pamsrvcmd.c b/src/responder/pam/pamsrvcmd.c index 0000000..1111111 100644 — a/src/responder/pam/pamsrvcmd.c +++ b/src/responder/pam/pamsrvcmd.c @@ -475,6 +475,11 @@ static int pamparseindata(struct pamdata pd, sizet last; int ret; + / Prevent sizet underflow and invalid first dereference / + if (blen == 0) { + return EINVAL; + } + last = blen - 1; end = 0; @@ -482,27 +487,42 @@ static int pamparseindata(struct pamdata pd, / user name / for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->logonname = (char ) &body[start];

for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->service = (char ) &body[start];

for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->tty = (char ) &body[start];

for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->ruser = (char ) &body[start];

for (start = end; end < last; end++) if (body[end] == '\0') break; if (body[end++] != '\0') return EINVAL; + if (end >= blen || body[end] != '\0') return EINVAL; + end++; pd->rhost = (char ) &body[start];

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

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.