Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

AI_ONLY_REPORT
package: krb5-1.21.3-8.el10_0
------
Summary: PAC verification state confusion in `verify_pac_checksums()` can  
mark failed PAC as authenticated: failed server-checksum handling can set  
`pac->verified = TRUE`, allowing downstream `mspac` consumers to treat  
unverified PAC data as authenticated.
Requirements to exploit: The attacker must be able to present PAC-bearing  
Kerberos traffic that reaches the in-tree `mspac` AP-REQ verification path,  
typically as an authenticated network peer, and must target a deployment  
where downstream code trusts `mspac` exported attributes or the  
`authenticated` flag. The available evidence does not establish a generic  
unauthenticated Kerberos authentication bypass.
Component affected: `krb5-1.21.3-8.el10_0`, `src/lib/krb5/krb/pac.c`,  
`verify_pac_checksums()`, `mspac_verify()`, `mspac_get_attribute()`
Version affected: `krb5-1.21.3-8.el10_0`
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:H/PR:L/UI:N/S:U/C:L/I:L/A:N - 4.2 (MEDIUM)
AV:N - The vulnerable state is reached during network Kerberos PAC  
verification.
AC:H - Exploitation depends on causing a server-checksum verification  
failure while hitting a path that ignores the returned error and later  
trusts the verified/authenticated state.
PR:L - The available evidence suggests the attacker must at least  
participate in Kerberos exchanges as a low-privileged principal, or  
otherwise present crafted PAC-bearing tickets; unauthenticated exploitation  
is not established.
UI:N - No separate user interaction is required once the crafted  
Kerberos traffic is sent.
S:U - The flaw affects trust decisions within the same krb5/PAC  
verification authority.
C:L - Unverified PAC data can be surfaced to consumers as authenticated,  
but broader data disclosure is not established.
I:L - PAC-derived identity or authorization signals can be trusted when  
they should not be, but a general authentication or privilege-escalation  
bypass is not established.
A:N - No direct availability impact is demonstrated.
Impact: Moderate. This issue does not meet Red Hat's Important or Critical  
criteria because the available evidence does not show easy remote  
compromise, broad denial of service, or a general authentication bypass. It  
fits Moderate because exploitation is more difficult and  
deployment-dependent, but it can still lead to integrity or confidentiality  
trust confusion for PAC-consuming applications under certain circumstances.
Embargo: no
Reason: The available evidence supports a Moderate,  
configuration-dependent trust confusion issue rather than easy remote  
system compromise, and the proposed fix is a small, targeted change.
Acknowledgement: Aisle Research
Vulnerability Details: In `verify_pac_checksums()`, the result of server  
checksum verification is stored in `ret`, but control does not immediately  
exit on failure. In the `mspac_verify()` AP-REQ path, `krb5_pac_verify()`  
is called with `privsvr == NULL`, so the function can fall through to  
`pac->verified = TRUE` and then return a non-zero error. `mspac_verify()`  
logs the error but intentionally returns success, with a comment indicating  
that failed verification is only supposed to leave the PAC unverified.  
Later, mspac attribute retrieval uses `pac->verified` both to decide  
whether PAC data exists and to set the `authenticated` result.
```c
if (server != NULL) {
/* Verify the server checksum over the PAC copy. */
ret = verify_checksum(context, pac, KRB5_PAC_SERVER_CHECKSUM,  
server,
KRB5_KEYUSAGE_APP_DATA_CKSUM, &copy);
}
...
pac->verified = TRUE;
cleanup:
free(copy.data);
return ret;
```
```c
ret = krb5_pac_verify(context, pacctx->pac,
req->ticket->enc_part2->times.authtime,
req->ticket->enc_part2->client, key, NULL);
if (ret)
TRACE_MSPAC_VERIFY_FAIL(context, ret);
/*
If the above verification failed, don't fail the whole  
authentication,

just don't mark the PAC as verified.  A checksum mismatch can occur  
if

the PAC was copied from a cross-realm TGT by an ignorant KDC, and  
Apple

macOS Server Open Directory (as of 10.6) generates PACs with no  
server

checksum at all.
      */
     return 0;
```


```c
/* If it didn't verify, pretend it didn't exist. */
if (!pacctx->pac->verified) {
TRACE_MSPAC_DISCARD_UNVERF(context);
return ENOENT;
}
...
if (!ret) {
*authenticated = pacctx->pac->verified;
*complete = TRUE;
}
```
The technical effect supported by the available evidence is PAC  
verification state confusion: an invalid PAC can be exposed to downstream  
mspac consumers as authenticated. The available material does not establish  
a universal Kerberos authentication bypass, and impact depends on a  
deployment actually consuming these PAC attributes or the exported  
authenticated state for security-relevant decisions.
Steps to reproduce:
1. Build `krb5-1.21.3-8.el10_0` with debug symbols or equivalent tracing  
enabled.
2. Create or mutate a PAC so that `KRB5_PAC_SERVER_CHECKSUM` verification  
fails, then load it through the `mspac_import_authdata` path into a request  
context.
3. Exercise AP-REQ processing so `mspac_verify()` calls  
`krb5_pac_verify(context, pacctx->pac, ..., key, NULL)`.
4. Observe that `krb5_pac_verify()` returns a non-zero error and trace  
output reports PAC checksum verification failure, but `mspac_verify()`  
still returns `0`.
5. Query an mspac attribute such as `urn:mspac:logon-info` via  
`mspac_get_attribute()` and inspect the `authenticated` output; it can be  
reported as authenticated because `pac->verified` was set despite the  
failed checksum.
Mitigation: Until a fix is applied, applications that consume  
`mspac`-exported PAC data should not treat the `authenticated` result or  
copied PAC state as authoritative if PAC verification produced an error. If  
PAC-derived attributes influence authorization or identity decisions, fail  
closed on PAC verification failure instead of assuming the library will  
keep `pac->verified` false. No package-level configuration workaround is  
established by the available evidence.
Proposed Fix: Abort verification immediately after a failed server checksum  
so the function cannot set `pac->verified = TRUE` on an error path,  
matching the intended behavior documented in `mspac_verify()`.
```diff
diff --git a/src/lib/krb5/krb/pac.c b/src/lib/krb5/krb/pac.c
— a/src/lib/krb5/krb/pac.c
+++ b/src/lib/krb5/krb/pac.c
@@ -537,6 +537,8 @@ verify_pac_checksums(krb5_context context, const  
krb5_pac pac,
if (server != NULL) {
/* Verify the server checksum over the PAC copy. */
ret = verify_checksum(context, pac, KRB5_PAC_SERVER_CHECKSUM,  
server,
KRB5_KEYUSAGE_APP_DATA_CKSUM, &copy);
+        if (ret)
+            goto cleanup;
}
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use