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

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: Out-of-Bounds Write in SSSD NFS idmap Plugin (sssnfsclient.c) on memcache hit: destination buffer length is checked and ENOBUFS is set, but memcpy() still copies the full cached user or group name into an undersized caller buffer. Requirements to exploit: The NFS idmap plugin from this SRPM must be in use, rpc.idmapd must be configured with Method = sss, and the memcache path must be enabled (memcache = true, the documented default for the plugin). Exploitation then requires a uidtoname or gidtoname lookup that hits memcache and returns a cached pwname or grname longer than the caller-supplied len. The available source does not establish the caller's buffer-sizing policy, so real-world exploitability depends on external caller and deployment behavior. Component affected: sssd-2.12.0-1.el10, NFS libnfsidmap plugin implementation in src/sssclient/nfs/sssnfsclient.c, specifically getuserfrommc() and getgroupfrommc(), reachable from sssnfsuidtoname() and sssnfsgidtoname(). Version affected: sssd-2.12.0-1.el10; reachable when the NFS idmap plugin is built and rpc.idmapd uses Method = sss with memcache = 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:L/I:L/A:H - 6.1 (MEDIUM) AV:L - The issue is established in local plugin usage on a system running the SSSD NFS idmap path; remote exploitability is not demonstrated by the available evidence. AC:H - Triggering requires a specific buffer-length mismatch in an external caller while the memcache path is enabled and hit by lookup traffic. PR:L - A successful attack typically assumes at least an authenticated foothold or equivalent ability to influence relevant identity data and trigger lookups on the affected host. UI:N - No separate user interaction is required once the vulnerable lookup path is reachable. S:U - The memory corruption occurs within the security scope of the idmap process using this plugin. C:L - Limited disclosure from process memory cannot be ruled out once corruption occurs, but broader disclosure is not established. I:L - The out-of-bounds write can alter adjacent process memory, although reliable controlled modification is not shown. A:H - Memory corruption in the lookup path can crash or destabilize the idmap process handling these requests. Impact: Moderate. This is a real out-of-bounds write, but it does not fit Red Hat's Important or Critical categories on the available evidence because easy remote exploitation and reliable system compromise are not established. Exploitability depends on a specific build and runtime configuration, use of the SSSD NFS idmap plugin, the memcache-backed lookup path, and a caller-supplied buffer that is shorter than the cached name. That aligns more closely with Red Hat's Moderate rating for flaws that can affect confidentiality, integrity, or availability under certain circumstances or in less common configurations. The current evidence does not support claiming reliable privilege escalation or code execution from this flaw alone. Embargo: no Reason: The issue appears to be Moderate and configuration-dependent, and there is a straightforward mitigation by disabling the vulnerable memcache path until a fix is available. Acknowledgement: Aisle Research Vulnerability Details: In both getuserfrommc() and getgroupfrommc(), the code detects that the cached reply is larger than the destination buffer and sets rc = ENOBUFS, but it does not stop before copying. As a result, a memcache hit with pwnamelen > len or grnamelen > len still executes memcpy() and writes past the end of the caller buffer. c pwnamelen = strlen(pwd.pwname) + 1; if (pwnamelen > len) { IDMAPLOG(0, ("%s: reply too long; pwnamelen=%lu, len=%lu", func, pwnamelen, len)); rc = ENOBUFS; } memcpy(name, pwd.pwname, pwnamelen); c grnamelen = strlen(grp.grname) + 1; if (grnamelen > len) { IDMAPLOG(0, ("%s: reply too long; grnamelen=%lu, len=%lu", func, grnamelen, len)); rc = ENOBUFS; } memcpy(name, grp.grname, grnamelen); The affected code is at src/sssclient/nfs/sssnfsclient.c:179-185 and src/sssclient/nfs/sssnfsclient.c:220-226. The trigger path is sssnfsuidtoname() -> getuserfrommc() and sssnfsgidtoname() -> getgroupfrommc(). The unsafe write inside the plugin is direct and unconditional once an oversized memcache result is returned. The exact sizing policy for len is external to these functions, so practical exploitability depends on caller behavior. Steps to reproduce: 1. Build with ASan (-fsanitize=address) and include the NFS idmap plugin (BUILDNFSIDMAP path). 2. Configure rpc.idmapd to use the SSSD plugin (Method = sss) and keep memcache = true (default in sssrpcidmapd.5.xml). 3. Ensure memcache has a user or group name longer than the destination buffer supplied by the caller. 4. Trigger uidtoname or gidtoname resolution so the memcache path is used. 5. At the memcpy() sites above, verify pwnamelen > len or grnamelen > len and observe the out-of-bounds write or ASan report. Mitigation: If an immediate fix is not available, set memcache = false for the SSSD rpc.idmapd plugin so lookups avoid getuserfrommc() and getgroupfrommc(), which are the vulnerable paths. If that is not acceptable, avoid using Method = sss for rpc.idmapd until a fixed build is available. Proposed Fix: Abort the memcache-hit path before memcpy() when the returned name does not fit in the caller buffer. diff diff --git a/src/sssclient/nfs/sssnfsclient.c b/src/sssclient/nfs/sssnfsclient.c @@ -179,10 +179,11 @@ static int getuserfrommc(char name, sizet len, uidt uid) if (pwnamelen > len) { IDMAPLOG(0, ("%s: reply too long; pwnamelen=%lu, len=%lu", func, pwnamelen, len)); rc = ENOBUFS; + goto done; } IDMAPLOG(1, ("found uid %i in memcache", uid)); memcpy(name, pwd.pwname, pwnamelen); @@ -220,10 +221,11 @@ static int getgroupfrommc(char name, sizet len, idt gid) if (grnamelen > len) { IDMAPLOG(0, ("%s: reply too long; grnamelen=%lu, len=%lu", func, grnamelen, len)); rc = ENOBUFS; + goto done; } IDMAPLOG(1, ("found gid %i in memcache", gid)); memcpy(name, grp.grname, grnamelen); ------ This report was generated using AI technology. Always review AI-generated content prior to use