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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Local DoS in PAM GSSAPI flow via stale clictx->statectx pointer (UAF pattern): a successful GSSAPI context completion frees cached per-connection state without clearing the connection pointer, so a later same-socket SSSGSSAPISECCTX request can terminate the PAM responder and disrupt authentication availability. Requirements to exploit: Local access to a system running the affected package, PAM GSSAPI enabled for at least one service, and the ability to drive a GSSAPI exchange to successful context establishment and then send another SSSGSSAPISECCTX request on the same responder connection. Component affected: sssd-2.12.0-1.el10, src/responder/pam/pamsrvgssapi.c, gssapigetstate(), pamcmdgssapisecctxdone() Version affected: sssd-2.12.0-1.el10 when the PAM responder GSSAPI flow is enabled for at least one service 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:H/PR:L/UI:N/S:U/C:N/I:N/A:H - 4.9 (MEDIUM) AV:L - Exploitation requires local access to the PAM responder socket/protocol. AC:H - The vulnerable path depends on PAM GSSAPI being enabled and on reaching successful context establishment on the same connection before sending another SSSGSSAPISECCTX request. PR:L - The described attack model requires a low-privileged local account. UI:N - No separate victim interaction is required once the attacker can issue the protocol requests. S:U - The impact is limited to the PAM responder's security scope. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - A successful trigger can terminate the responder and deny PAM authentication service until it is restarted. Impact: Moderate. This issue can cause a meaningful availability failure for PAM authentication in affected deployments, but it is local, configuration-dependent, and tied to the successful GSSAPI completion path on the same connection. Under Red Hat's guidance, that is more consistent with Moderate than Important because it is not an easy remote DoS and does not demonstrate confidentiality or integrity compromise. Embargo: no Reason: The issue is local, setup-dependent, and availability-only, with straightforward operational mitigation and no demonstrated confidentiality or integrity impact. Acknowledgement: Aisle Research Vulnerability Details: The PAM responder caches per-connection GSSAPI state in clictx->statectx and reuses it on later requests: c static struct gssapistate gssapigetstate(struct clictx clictx, const char username, struct sssdomaininfo domain) { struct gssapistate state; state = tallocgettype(clictx->statectx, struct gssapistate); if (state != NULL) { return state; } ... clictx->statectx = state; return state; } That cached state is later freed on the callback completion path: c static void pamcmdgssapisecctxdone(struct teventreq req) { ... done: DEBUG(SSSDBGTRACEFUNC, "Returning [%d]: %s\n", ret, sssstrerror(ret)); if (ret == EOK) { ssspacketseterror(pctx->creq->out, EOK); } else { ssscmdsenderror(state->clictx, ret); } ssscmddone(state->clictx, state); } Based on the available code, ssscmddone(state->clictx, state) frees state but does not clear clictx->statectx, leaving a stale per-connection pointer behind. A subsequent SSSGSSAPISECCTX request on the same socket re-enters gssapigetstate() and consults clictx->statectx again. In builds where talloc detects the freed chunk as invalid, this can abort the responder and cause a local denial of service against PAM authentication. The synchronous error path in pamcmdgssapisecctx() ends with ssscmddone(clictx, NULL) and, based on the available code, does not appear to be the vulnerable free. The stale-pointer condition appears tied to the successful callback completion path. Steps to reproduce: 1. Configure PAM GSSAPI for at least one service, for example by including a test service in pamgssapiservices. 2. Connect as a local user to the PAM responder socket and issue SSSGSSAPIINIT. 3. Send SSSGSSAPISECCTX tokens until context establishment succeeds and the callback completion path is reached. 4. Keep the same socket open and send one additional SSSGSSAPISECCTX request. 5. Observe responder crash or abort behavior consistent with stale clictx->statectx reuse in gssapigetstate(). Mitigation: If an immediate code fix is not possible, disable PAM GSSAPI for affected services or otherwise prevent use of the PAM responder's GSSAPI flow. Restarting the PAM responder can restore service after a crash, but it does not remove the underlying bug. Proposed Fix: Clear clictx->statectx before freeing state in pamcmdgssapisecctxdone(). diff diff --git a/src/responder/pam/pamsrvgssapi.c b/src/responder/pam/pamsrvgssapi.c — a/src/responder/pam/pamsrvgssapi.c +++ b/src/responder/pam/pamsrvgssapi.c @@ -1060,6 +1060,10 @@ static void pamcmdgssapisecctxdone(struct teventreq req) ssscmdsenderror(state->clictx, ret); } + if (state->clictx->statectx == state) { + state->clictx->statectx = NULL; + } + ssscmddone(state->clictx, state); } Equivalent hardening in gssapistatedestructor() is also reasonable. ------ This report was generated using AI technology. Always review AI-generated content prior to use