Fedora Account System
Red Hat Associate
Red Hat Customer
AI_ONLY_REPORT package: sssd-2.12.0-1.el10 ------ Summary: Use-After-Free in KCM TGT Renewal (`auth_data->ccname` lifetime mismatch): a deferred KCM renewal callback retains a shallow pointer to `cc->name` after the timer's temporary talloc context is freed, resulting in a local use-after-free read with likely KCM responder denial-of-service impact in affected renewal deployments. Requirements to exploit: An authenticated local user on a host using the KCM responder, with a renewable TGT stored in KCM. Reachability depends on builds with KCM renewal support and deployments configured with `db = secdb` and `tgt_renewal = true`; the user then waits for the normal renewal window. Component affected: `sssd-2.12.0-1.el10`, `src/responder/kcm/kcm_renew.c`, KCM TGT renewal path in `kcm_creds_check_times()` with deferred use in `kcm_renew_tgt()` / `kcm_child_req_setup()`. Version affected: `sssd-2.12.0-1.el10`; reachability depends on builds with KCM renewal support and deployments using the KCM `secdb` backend with `tgt_renewal = true` 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.4 (MEDIUM) AV:L - Exploitation requires local access to a host using the affected KCM responder. AC:H - The vulnerable path is gated by non-default renewal configuration, the `secdb` backend, and renewal timing before the dangling pointer is consumed. PR:L - A regular authenticated local user with access to KCM and a renewable TGT can reach the path in an affected deployment. UI:N - No separate victim interaction is required once the vulnerable configuration is in place. S:U - The impact is confined to the KCM responder's own security scope. C:N - The available evidence does not establish confidentiality impact. I:N - The available evidence does not establish integrity impact. A:H - The demonstrated consequence is service crash or instability in the KCM responder, resulting in denial of service for affected KCM operations. Impact: Moderate. This issue can allow an authenticated local user to cause an availability impact in the KCM responder, but the affected renewal path is disabled by default and appears effectively limited to the `secdb` backend. No reliable confidentiality, integrity, or privilege-escalation impact is established from the available evidence. Under Red Hat's severity guidance, this is more appropriately Moderate than Important because it is a real denial-of-service issue in an opt-in, less easily exploited configuration rather than an easily reached default-path compromise. Embargo: no Reason: The currently supported impact is local denial of service in a configuration-gated feature path, and exposure can be reduced immediately by leaving `tgt_renewal` disabled or disabling renewal where it is enabled. This does not appear to warrant embargo. Acknowledgement: Aisle Research Vulnerability Details: In the KCM TGT renewal path, the renewal context stores a shallow pointer to the credential cache name, but the source object is tied to a temporary talloc context that is later freed before the deferred callback uses the pointer: ```c auth_data->ccname = cc->name; ... talloc_free(tmp_ctx); ... krreq->ccname = talloc_asprintf(krreq, "KCM:%s", auth_data->ccname); ``` `auth_data` is queued to a deferred immediate callback, so its lifetime extends beyond the timer handler. The credential caches being iterated originate from a list allocated under `tmp_ctx`, which is freed after renewal scheduling completes. When the deferred path reaches `kcm_child_req_setup()`, `auth_data->ccname` can already point to released memory. This is consistent with a `CWE-416` use-after-free read and a `CWE-664` lifetime management issue. The available material supports denial of service in the KCM responder; it does not establish reliable confidentiality, integrity, or code-execution impact. Steps to reproduce: 1. Build `sssd-2.12.0-1.el10` with KCM renewal support enabled. 2. Configure the KCM responder to use `db = secdb` and `tgt_renewal = true`. A short renewal interval makes the issue easier to observe. 3. Restart `sssd-kcm`. 4. As an unprivileged local user, acquire a renewable TGT in KCM, for example by using `KRB5CCNAME=KCM:...`. 5. Wait until the renewal window is reached so the timer-driven renewal path executes. 6. Let the renewal timer schedule `kcm_renew_tgt`, then allow the timer handler to finish and free `tmp_ctx`. 7. Run under ASan or Valgrind and observe an invalid read or use-after-free report when `kcm_child_req_setup()` formats `KCM:%s` with `auth_data->ccname`. Mitigation: If KCM ticket renewal is not required, keep `tgt_renewal = false`, which avoids the affected path. On systems currently using KCM renewal, disabling the renewal feature until a fixed build is available reduces exposure. Proposed Fix: Deep-copy `cc->name` into `auth_data` before scheduling the deferred callback, and fail cleanly if that allocation cannot be made. ```diff diff --git a/src/responder/kcm/kcm_renew.c b/src/responder/kcm/kcm_renew.c @@ -579,11 +579,16 @@ static errno_t kcm_creds_check_times(TALLOC_CTX *mem_ctx, auth_data->krb5_ctx = renew_tgt_ctx->krb5_ctx; auth_data->upn = talloc_strdup(auth_data, client_name); auth_data->uid = cc->owner.uid; auth_data->gid = cc->owner.gid; auth_data->ccname = cc->name; + auth_data->ccname = talloc_strdup(auth_data, cc->name); if (auth_data->upn == NULL) { ret = ENOMEM; DEBUG(SSSDBG_CRIT_FAILURE, "Unable to allocate auth_data->upn for renewals\n"); goto done; } + if (auth_data->ccname == NULL) { + ret = ENOMEM; + DEBUG(SSSDBG_CRIT_FAILURE, "Unable to allocate auth_data->ccname for renewals\n"); + goto done; + } ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use