AI_ONLY_REPORT
package: openssh-10.2p1-10.1.hum1
------
Summary: Heap out-of-bounds read in GSSAPI indicator cleanup: missing  
trailing `NULL` termination in the GSSAPI auth-indicators array allows  
sentinel-based consumers to read past the allocated pointer array and may  
trigger an invalid free during cleanup.
Requirements to exploit: An attacker needs network access to SSH on  
`openssh-10.2p1-10.1.hum1` built with GSSAPI support and deployed with  
`GSSAPIAuthentication yes`; in this tree that option defaults to disabled.  
The Kerberos environment must provide a ticket containing at least one  
authenticated `auth-indicators` value, and execution must then reach either  
the failed `ssh_gssapi_userok()` cleanup path or the `GSSAPIIndicators`  
matching path.
Component affected: `openssh-10.2p1-10.1.hum1`, server-side GSSAPI  
authentication code in `gss-serv.c` (`ssh_gssapi_getindicators()`), with  
sentinel-based consumption in `gss-serv.c` (`ssh_gssapi_userok()`) and  
`gss-serv-krb5.c` (`ssh_gssapi_check_indicators()`)
Version affected: `openssh-10.2p1-10.1.hum1` when built with GSSAPI  
support; remote triggerability additionally requires `GSSAPIAuthentication  
yes` and a Kerberos deployment that supplies authenticated `auth-indicators`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not yet established.
CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L - 3.7 (LOW)
AV:N - the vulnerable path is reachable through network SSH  
authentication traffic.
AC:H - exploitation depends on a GSSAPI-enabled build,  
`GSSAPIAuthentication yes`, a Kerberos ticket carrying authenticated  
`auth-indicators`, and reaching a sentinel-based consumer path.
PR:N - no prior privileges on the target host are required beyond  
initiating the SSH authentication exchange.
UI:N - no separate user interaction is required once the target is  
configured this way.
S:U - the effect is limited to the vulnerable SSH authentication  
component.
C:N - no reliable confidentiality impact is established from the  
available evidence.
I:N - no integrity impact is established from the available evidence.
A:L - the demonstrated consequence is limited to out-of-bounds reads  
that may crash or abort the affected authentication path.
Impact: Moderate. Red Hat classifies easily triggered remote denial of  
service issues as Important, but the trigger conditions here are materially  
narrower: the issue depends on GSSAPI support, non-default SSH  
configuration, Kerberos indicator issuance, and a specific authentication  
control flow. The demonstrated impact is limited to availability loss in  
privileged authentication code, so Moderate is a better fit than Important,  
while remaining above Low because the out-of-bounds iteration is concrete  
rather than merely theoretical.
Embargo: no
Reason: The issue is configuration-dependent, the demonstrated impact  
is limited to availability, and the proposed fix is small and low-risk. A  
normal public fix cycle appears more appropriate than an embargo.
Acknowledgement: Aisle Research
Vulnerability Details: In `ssh_gssapi_getindicators()`, the  
`client->indicators` array is reallocated from `count` to `count + 1`  
elements and the newly added slot is immediately filled with a newly  
allocated string:
```c
client->indicators = xrecallocarray(client->indicators, count, count +  
1, sizeof(char*));
if (client->indicators == NULL) {
fatal("ssh_gssapi_getindicators failed to allocate memory");
}
client->indicators[count] = xmalloc(value.length + 1);
memcpy(client->indicators[count], value.value, value.length);
client->indicators[count][value.length] = '\0';
count++;
```
In this source tree, `xrecallocarray()` wraps `recallocarray()`, which  
zeroes only the newly added region when the allocation grows. Here the  
newly added region is exactly one pointer wide, and that pointer is  
overwritten before `count` is incremented. As a result, once at least one  
authenticated indicator is collected, there is no guaranteed trailing  
`NULL` entry after the last valid element even though later code relies on  
sentinel termination.
Two consumers iterate until `NULL`:
```c
if (gssapi_client.indicators != NULL) {
for (i = 0; gssapi_client.indicators[i] != NULL; i++)
free(gssapi_client.indicators[i]);
free(gssapi_client.indicators);
}
```
```c
for (i = 0; client->indicators[i] != NULL; i++) {
ret = match_pattern_list(client->indicators[i],
options.gss_indicators, 1);
...
}
```
These loops may read beyond the allocated pointer array while searching for  
a terminator. On the `ssh_gssapi_userok()` failure cleanup path, that  
out-of-bounds read may also cause `free()` to be called on a non-owned  
pointer if adjacent heap contents are interpreted as another indicator  
entry. Based on the available evidence, the established security  
consequence is an availability problem; reliable confidentiality or  
integrity impact is not demonstrated.
Steps to reproduce:
1. Build `openssh-10.2p1-10.1.hum1` with GSSAPI support and memory  
sanitizers such as ASan/UBSan.
2. Run `sshd` with `GSSAPIAuthentication yes`.
3. Authenticate with a Kerberos ticket that contains at least one  
authenticated `auth-indicators` name attribute.
4. Trigger a sentinel-based consumer by either causing  
`ssh_gssapi_userok()` to return false, for example through  
principal-to-local-user authorization failure, or by configuring  
`GSSAPIIndicators` so `ssh_gssapi_check_indicators()` iterates the list.
5. Observe a sanitizer-reported read past the end of the `indicators`  
pointer array; depending on heap layout, cleanup may also attempt to free a  
non-owned pointer.
Mitigation: Disabling `GSSAPIAuthentication` removes the remotely reachable  
path. If GSSAPI authentication is required, avoiding `GSSAPIIndicators`  
removes one consumer but does not remove the cleanup path after  
`ssh_gssapi_userok()` failure; the safer temporary mitigation is to  
restrict or disable use of Kerberos tickets carrying authenticated  
`auth-indicators` values until a fix is deployed.
Proposed Fix: Ensure `ssh_gssapi_getindicators()` leaves a dedicated  
trailing `NULL` slot after indicator collection so all sentinel-based  
consumers remain within bounds.
```diff
diff --git a/gss-serv.c b/gss-serv.c
@@
done:
-	/* slot [count] is zeroed by recallocarray, serves as NULL sentinel */
+	/*
+	 * Ensure a trailing NULL sentinel for sentinel-based consumers.
+	 */
+	if (client->indicators != NULL)
+		client->indicators = xrecallocarray(client->indicators,
+		    count, count + 1, sizeof(char *));
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use