REDHAT-BUG-2478449: High severity redhat/krb5 vulnerability
AIONLYREPORT package: krb5-1.21.3-8.el100 ------ Summary: RPCSECGSS Auth-Flavor Switching Causes Unbounded Per-Connection Memory Leak (Unauthenticated DoS): switching a persistent TCP connection from RPCSECGSS to AUTHNONE, AUTHUNIX, or AUTHSHORT can orphan heap-backed auth state and let an unauthenticated remote client exhaust server memory. Requirements to exploit: The attacker must be able to reach a service built from krb5-1.21.3-8.el100 that uses the src/lib/rpc GSS-RPC server path over a long-lived TCP connection with RPCSECGSS enabled. No prior authentication or user interaction is required. Component affected: krb5-1.21.3-8.el100 GSS-RPC server authentication lifecycle in src/lib/rpc, notably svcdoxprt() in svc.c, gssrpcauthenticate() in svcauth.c, gssrpcsvcauthgss() in svcauthgss.c, and the non-GSS handlers in svcauthnone.c and svcauthunix.c. Version affected: krb5-1.21.3-8.el100 (reachable when a service from this SRPM exposes the GSS-RPC server path over persistent TCP with RPCSECGSS enabled) 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:N/UI:N/S:U/C:N/I:N/A:H - 7.5 (HIGH) AV:N - The attack is performed by sending RPC traffic over the network to an exposed service. AC:L - Once the affected TCP GSS-RPC path is reachable, alternating auth flavors on one connection is straightforward and repeatable. PR:N - The leak can be triggered before successful authentication is established. UI:N - No user interaction is required. S:U - The impact is limited to the vulnerable service's own security scope. C:N - No confidentiality impact is demonstrated. I:N - No integrity impact is demonstrated. A:H - Repetition can drive unbounded memory growth until the service becomes unavailable or is terminated. Impact: Important. The demonstrated effect is an unauthenticated remote denial of service through memory exhaustion on a network-reachable service, which aligns with Red Hat's Important rating for remote DoS. It is not Critical because no system compromise or confidentiality/integrity impact is shown, and reachability depends on a deployment exposing the affected RPCSECGSS TCP path. Embargo: no Reason: This is an availability-only issue with configuration-dependent reachability, and administrators can reduce exposure by restricting access to the affected service. The available evidence does not show code execution or silent data compromise that would strongly justify delayed public disclosure. Acknowledgement: Aisle Research Vulnerability Details: The issue is a lifecycle mismatch for xprt->xpauth. gssrpcsvcauthgss() allocates heap-backed SVCAUTH/GSS private state and stores it on the transport. svcdoxprt() intentionally preserves RPCSECGSS auth handles across requests, but later non-GSS authenticators overwrite the same pointer with the static &svcauthnone handle without first calling SVCAUTHDESTROY(). After the overwrite, the original heap object is no longer reachable and leaks until process exit. In src/lib/rpc/svcauthgss.c, RPCSECGSS authentication attaches per-connection auth state to the transport: c if (rqst->rqxprt->xpauth == NULL || rqst->rqxprt->xpauth == &svcauthnone) { ... auth->svcahops = &svcauthgssops; SVCAUTHPRIVATE(auth) = gd; rqst->rqxprt->xpauth = auth; } In src/lib/rpc/svc.c, non-GSS auth handles are nulled at request teardown, while GSS handles are intentionally retained: c } else if ((xprt->xpauth != NULL) && (xprt->xpauth->svcahops != &svcauthgssops)) { xprt->xpauth = NULL; } In src/lib/rpc/svcauthnone.c, and likewise in gssrpcsvcauthunix() and gssrpcsvcauthshort(), a later non-GSS request overwrites the transport pointer: c rqst->rqxprt->xpauth = &svcauthnone; An unauthenticated client can therefore keep one TCP connection open, send an RPCSECGSS INIT or CONTINUEINIT request to allocate xpauth, then switch to AUTHNONE, AUTHUNIX, or AUTHSHORT on the same connection to orphan that state. Repeating the sequence causes monotonic heap/RSS growth bounded only by available memory. The available evidence supports availability impact only. Steps to reproduce: 1. Run a service built from krb5-1.21.3-8.el100 that uses the src/lib/rpc server stack over TCP with RPCSECGSS enabled. 2. Keep a single TCP connection open to the service. 3. Send one RPCSECGSS request on that connection, such as INIT or CONTINUEINIT, so gssrpcsvcauthgss() allocates xpauth. 4. On the same connection, send a request using AUTHNONE, AUTHUNIX, or AUTHSHORT so xpauth is overwritten. 5. Repeat steps 3 and 4 in a loop. 6. Observe monotonic memory growth in the server process; repeated switching can eventually exhaust memory and make the service unavailable. Mitigation: Restrict network access to affected GSS-RPC services to trusted clients until a fix is available. Deployments that do not expose the vulnerable TCP GSS-RPC path or do not enable RPCSECGSS are not reachable through this issue. If memory growth is observed, restart the affected service to reclaim leaked memory. Proposed Fix: Centralize cleanup in gssrpcauthenticate() before dispatching to non-RPCSECGSS authenticators so auth-flavor switching cannot orphan the previous heap allocation. diff diff --git a/src/lib/rpc/svcauth.c b/src/lib/rpc/svcauth.c — a/src/lib/rpc/svcauth.c +++ b/src/lib/rpc/svcauth.c @@ -38,6 +38,7 @@ / #include <gssrpc/rpc.h> +extern struct svcauthops svcauthgssops; / Server side authenticators are called from authenticate by @@ -92,6 +93,14 @@ gssrpcauthenticate( rqst->rqxprt->xpverf.oalength = 0; credflavor = rqst->rqcred.oaflavor; nodispatch = FALSE; + + / Drop stale RPCSECGSS auth state if client switches flavor. / + if (rqst->rqxprt->xpauth != NULL && + rqst->rqxprt->xpauth->svcahops == &svcauthgssops && + credflavor != RPCSECGSS) { + SVCAUTHDESTROY(rqst->rqxprt->xpauth); + rqst->rqxprt->xpauth = NULL; + } + for (i = 0; i < svcauthnum; i++) { if (credflavor == svcauthsw[i].flavor && svcauthsw[i].authenticator != NULL) {
------ This report was generated using AI technology. Always review AI-generated content prior to use
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Do not enable RPCSEC_GSS on deployments where it is not required.
src/lib/rpc GSS-RPC server path RPCSEC_GSS = disabled - Compensating control
Restrict network access to affected GSS-RPC services to trusted clients.
- Operational
If memory growth is observed, restart the affected service to reclaim leaked memory.