AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Local OOB Read in NSS Service Request Parsers  
(`sss_nss_protocol_parse_svc_name` / `sss_nss_protocol_parse_svc_port`):  
malformed local service lookup requests can force parser reads beyond the  
declared packet body length and may crash the NSS responder.
Requirements to exploit: Ability to run a local process that can connect to  
the NSS responder UNIX socket and send a crafted `SSS_NSS_GETSERVBYNAME` or  
`SSS_NSS_GETSERVBYPORT` request. In common NSS responder setups this is  
reachable by unprivileged local clients; deployments with stricter socket  
permissions or explicit UID restrictions reduce exposure.
Component affected: `sssd-2.12.0-1.el10` NSS responder,  
`src/responder/nss/nss_protocol.c`, `sss_nss_protocol_parse_svc_name()`,  
`sss_nss_protocol_parse_svc_port()`
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 attack requires local access to the NSS responder UNIX socket  
rather than remote network reachability.
AC:L - constructing the malformed request body is straightforward and  
does not require special timing or heap shaping.
PR:N - in common NSS responder deployments, an unprivileged local client  
can reach the socket and submit the request; tighter ACLs would reduce  
exposure.
UI:N - no user interaction is required once the attacker can connect  
locally.
S:U - the effect is confined to the SSSD responder process and its own  
security scope.
C:N - the available evidence shows an invalid read, but not a returned  
or otherwise usable memory disclosure.
I:N - no integrity impact has been demonstrated.
A:L - the bug can trigger invalid reads and plausibly crash the  
responder, but reliability is not established and may depend on allocator  
layout.
Impact: Low. Under the currently established facts, this is a local-only  
parser bug and the demonstrated effect is an out-of-bounds read with  
limited, non-deterministic availability impact in the NSS responder. The  
available evidence does not show privilege escalation, arbitrary code  
execution, or reliable disclosure of protected data. Under Red Hat's  
guidance, that best fits Low impact.
Embargo: no
Reason: The currently established impact is a local responder-side  
invalid read with at most limited denial-of-service potential. Given the  
low severity, straightforward validation fix, and absence of demonstrated  
confidentiality or integrity impact, embargoed handling does not appear  
necessary.
Acknowledgement: Aisle Research
Vulnerability Details: This is an input-validation flaw in the NSS  
responder service-query parsing path. `sss_nss_protocol_parse_svc_name()`  
assumes the body contains two consecutive NUL-terminated strings within the  
declared body length. For a malformed `GETSERVBYNAME` request whose body is  
only `b"a\x00"` (`blen == 2`), the first scan stops at `body[1]`, and the  
second scan immediately evaluates `body[i + 1]` as `body[2]`, which is  
outside the declared body.
```c
sss_packet_get_body(pctx->creq->in, &body, &blen);
/* If not terminated fail. */
if (body[blen - 1] != '\0') {
DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n");
return EINVAL;
}
/* Calculate service name length. */
for (i = 0, name_len = 0; body[i] != '\0'; i++) {
name_len++;
}
/* Calculate protocol name length, use index from previous cycle. */
for (protocol_len = 0; body[i + 1] != '\0'; i++) {
protocol_len++;
}
```
`sss_nss_protocol_parse_svc_port()` similarly trusts that the request body  
is large enough to contain the fixed-size port and padding fields plus a  
trailing protocol string. It advances the body pointer by `2 *  
sizeof(uint16_t) + sizeof(uint32_t)` without first checking that `blen` is  
large enough, and then scans for a NUL terminator from the advanced pointer.
```c
sss_packet_get_body(pctx->creq->in, &body, &blen);
/* If not terminated fail. */
if (body[blen - 1] != '\0') {
DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n");
return EINVAL;
}
SAFEALIGN_COPY_UINT16(&port, body, NULL);
port = ntohs(port);
/* Move behind the port and padding to get the protocol. */
body = body + 2 * sizeof(uint16_t) + sizeof(uint32_t);
/* Calculate protocol name length. */
for (protocol_len = 0, i = 0; body[i] != '\0'; i++) {
protocol_len++;
}
```
These parsers are reachable through the `SSS_NSS_GETSERVBYNAME` and  
`SSS_NSS_GETSERVBYPORT` command handlers. Under ASan or Valgrind, the  
malformed requests above produce invalid-read reports in the parser path.  
On non-instrumented builds, responder termination is plausible but not  
fully deterministic because the read may remain inside allocator slack  
rather than fault immediately.
Steps to reproduce:
1. Build and run SSSD with ASan, or run the NSS responder under Valgrind,  
so the invalid read is reported deterministically.
2. Connect to the NSS responder UNIX socket, typically  
`/var/lib/sss/pipes/nss`.
3. Send one packet with the normal 16-byte SSSD header (`len`, `cmd`,  
`status`, `reserved`) followed by a malformed service lookup body.
4. For `SSS_NSS_GETSERVBYNAME` (`0x00A1`), use body `b"a\x00"` so only one  
NUL-terminated string is present.
5. For `SSS_NSS_GETSERVBYPORT` (`0x00A2`), use an 8-byte body such as  
`b"\x00\x50\x00\x00\x00\x00\x00\x00"` so the parser advances past the  
declared body and then scans for a terminator.
6. Observe the invalid read in `sss_nss_protocol_parse_svc_name()` or  
`sss_nss_protocol_parse_svc_port()` in the sanitizer or Valgrind output. A  
crash is possible, but may not occur on every run without instrumentation.
Mitigation: Restrict access to the NSS responder UNIX socket to trusted  
local clients where feasible. Deployments that already enforce tighter  
socket permissions or explicit UID restrictions reduce exposure, but the  
parser bug remains until bounds checks are added.
Proposed Fix: Reject zero-length or undersized bodies before dereferencing  
or advancing into the request, and bound each string scan by the declared  
body length.
```diff
diff --git a/src/responder/nss/nss_protocol.c  
b/src/responder/nss/nss_protocol.c
— a/src/responder/nss/nss_protocol.c
+++ b/src/responder/nss/nss_protocol.c
@@ -270,6 +270,10 @@ sss_nss_protocol_parse_svc_name(struct cli_ctx  
*cli_ctx,
sss_packet_get_body(pctx->creq->in, &body, &blen);
+    if (blen == 0) {
+        return EINVAL;
+    }
+
/* If not terminated fail. */
if (body[blen - 1] != '\0') {
DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n");
@@ -277,12 +281,20 @@ sss_nss_protocol_parse_svc_name(struct cli_ctx  
*cli_ctx,
}
/* Calculate service name length. */
   for (i = 0, name_len = 0; body[i] != '\0'; i++) {
+    for (i = 0, name_len = 0; i < blen && body[i] != '\0'; i++) {
          name_len++;
      }


+    if (i >= blen || i + 1 >= blen) {
+        return EINVAL;
+    }
+
/* Calculate protocol name length, use index from previous cycle. */
   for (protocol_len = 0; body[i + 1] != '\0'; i++) {
+    for (protocol_len = 0; (i + 1) < blen && body[i + 1] != '\0'; i++) {
          protocol_len++;
      }
+
+    if (i + 1 >= blen) {
+        return EINVAL;
+    }
@@ -326,6 +338,10 @@ sss_nss_protocol_parse_svc_port(struct cli_ctx  
*cli_ctx,


sss_packet_get_body(pctx->creq->in, &body, &blen);
+    if (blen < (2 * sizeof(uint16_t) + sizeof(uint32_t) + 1)) {
+        return EINVAL;
+    }
+
/* If not terminated fail. */
if (body[blen - 1] != '\0') {
DEBUG(SSSDBG_CRIT_FAILURE, "Body is not null terminated\n");
@@ -336,10 +352,15 @@ sss_nss_protocol_parse_svc_port(struct cli_ctx  
*cli_ctx,
/* Move behind the port and padding to get the protocol. */
body = body + 2 * sizeof(uint16_t) + sizeof(uint32_t);
+    blen -= 2 * sizeof(uint16_t) + sizeof(uint32_t);
/* Calculate protocol name length. */
   for (protocol_len = 0, i = 0; body[i] != '\0'; i++) {
+    for (protocol_len = 0, i = 0; i < blen && body[i] != '\0'; i++) {
          protocol_len++;
      }
+
+    if (i >= blen) {
+        return EINVAL;
+    }
```


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