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: kpasswd set-password path bypasses `+lockdown_keys`  
(`KRB5_KDB_LOCKDOWN_KEYS`) checks: authenticated requesters with delegated  
`OP_CPW` authorization can reset protected principals through the RFC3244  
kpasswd path even though the equivalent kadmind RPC path rejects the same  
operation.
Requirements to exploit: An attacker needs network reachability to the  
packaged kpasswd service, a valid authenticated principal, and  
authorization equivalent to the `c` / `OP_CPW` permission for a target  
principal marked `+lockdown_keys`. The practically relevant cross-principal  
case depends on ACL or auth-plugin configuration granting that delegated  
right.
Component affected: `krb5-1.21.3-8.el10_0`, `src/kadmin/server/misc.c`  
(`schpw_util_wrapper()`), reachable from the RFC3244 set-password handling  
in `src/kadmin/server/schpw.c`.
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: unknown.
CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L - 6.7 (MEDIUM)
AV:N - The vulnerable interface is the network-reachable kpasswd  
set-password service.
AC:L - Once the requester has the necessary authorization, exploitation  
is a normal RFC3244 set-password request with no race or unusual  
environmental requirement.
PR:H - The meaningful non-self exploit path requires an authenticated  
principal with delegated change-password authorization for the protected  
target, typically via `kadm5.acl` or an auth plugin.
UI:N - No separate user interaction is required beyond the attacker's  
own authenticated request.
S:U - The flaw changes authorization behavior inside the same Kerberos  
administrative security boundary.
C:H - Resetting a protected principal to an attacker-chosen password can  
give the requester effective control over that principal's secrets and any  
access tied to it.
I:H - The flaw defeats a protection explicitly intended to block  
password changes for locked-down principals.
A:L - A successful password reset can also disrupt legitimate use of the  
affected principal until recovery.
Impact: Moderate. The flaw can have serious consequences if the target is a  
sensitive locked-down principal, but exploitation depends on an  
authenticated requester already holding delegated `c` / `OP_CPW` rights or  
equivalent auth-plugin approval for that principal. Under Red Hat severity  
guidance, that makes this a meaningful security bypass with configuration-  
and privilege-dependent reachability, which is better aligned with Moderate  
than with an easily exploited Important or Critical issue.
Embargo: no
Reason: The issue requires authenticated, policy-dependent delegated  
privilege and has straightforward operational mitigations, such as not  
granting `c` rights over `+lockdown_keys` principals and restricting  
kpasswd exposure.
Acknowledgement: Aisle Research
Vulnerability Details: This path is not limited to self-service password  
changes. The RFC3244 set-password handling accepts an explicit target  
principal and passes that target into `schpw_util_wrapper()`. In the  
available code, `schpw_util_wrapper()` authorizes `OP_CPW` and then  
immediately calls the password-change utility, but it does not enforce  
`KRB5_KDB_LOCKDOWN_KEYS` on the target principal:
```c
if (auth(handle->context, OP_CPW, client, target,
NULL, NULL, NULL, NULL, 0)) {
ret = kadm5_chpass_principal_util(server_handle,
target,
new_pw, ret_pw,
msg_ret, msg_len);
}
```
By contrast, the kadmind RPC change-password handlers check the lockdown  
attribute first and convert `KADM5_PROTECT_KEYS` into an authorization  
failure:
```c
ret->code = check_lockdown_keys(handle, arg->princ);
if (ret->code != KADM5_OK) {
if (ret->code == KADM5_PROTECT_KEYS) {
...
ret->code = KADM5_AUTH_CHANGEPW;
}
}
```
The documented behavior of `+lockdown_keys` is that `chpass` and `extract`  
operations are denied for principals with this attribute. Based on the  
available code, no compensating lockdown check is evident in the lower  
password-change utility path before the password update occurs. As a  
result, when ACL or auth-plugin rules authorize `OP_CPW` for a non-self  
target, the kpasswd set-password path can reset a `+lockdown_keys`  
principal that the RPC path would reject.
Steps to reproduce:
1. Create test principals and mark the victim principal as locked down:
`kadmin.local: addprinc -pw victimpw victim`
`kadmin.local: addprinc -pw attackerpw attacker`
`kadmin.local: modprinc +lockdown_keys victim`
2. Grant the attacker change-password permission on the victim in  
`kadm5.acl`, for example:
`attacker@REALM c victim@REALM`
Restart `kadmind` after changing the ACL.
3. Obtain attacker credentials:
`kinit attacker@REALM`
4. Submit an RFC3244 set-password request naming `victim@REALM` as the  
target, using a client path that calls `krb5_set_password()` or  
`krb5_set_password_using_ccache()`.
5. Observe that the password change succeeds through the kpasswd path. A  
successful case is logged as a `setpw request ... by attacker ... for  
victim: success` event.
6. As a control, perform the equivalent RPC password change for the same  
target, for example `kadmin cpw -pw ... victim`, using the same attacker  
authorization. This path is denied because the RPC handler maps  
`KADM5_PROTECT_KEYS` to `KADM5_AUTH_CHANGEPW`.
Mitigation: Until a fix is available, do not grant delegated `c` / `OP_CPW`  
rights over principals marked `+lockdown_keys`, restrict or disable the  
kpasswd set-password service where delegated set-password is not needed,  
and monitor for successful `setpw request` log entries targeting protected  
principals.
Proposed Fix: Mirror the existing RPC-side lockdown check inside  
`schpw_util_wrapper()` before calling `kadm5_chpass_principal_util()`.
```diff
diff --git a/src/kadmin/server/misc.c b/src/kadmin/server/misc.c
index 1234567..89abcde 100644
— a/src/kadmin/server/misc.c
+++ b/src/kadmin/server/misc.c
@@ -10,6 +10,20 @@
#include "auth.h"
#include "net-server.h"
+/* Mirror lockdown enforcement used by kadmind RPC stubs. */
+static kadm5_ret_t
+check_lockdown_keys_local(kadm5_server_handle_t handle, krb5_principal  
princ)
+{
+    kadm5_principal_ent_rec rec;
+    kadm5_ret_t ret;
+
+    ret = kadm5_get_principal(handle, princ, &rec, KADM5_ATTRIBUTES);
+    if (ret)
+        return ret;
+    ret = (rec.attributes & KRB5_KDB_LOCKDOWN_KEYS) ? KADM5_PROTECT_KEYS :  
0;
+    kadm5_free_principal_ent(handle, &rec);
+    return ret;
+}
+
kadm5_ret_t
schpw_util_wrapper(void *server_handle,
krb5_principal client,
@@ -41,6 +55,14 @@ schpw_util_wrapper(void *server_handle,
if (ret != 0)
return ret;
}
+
+    ret = check_lockdown_keys_local(handle, target);
+    if (ret == KADM5_PROTECT_KEYS) {
+        strlcpy(msg_ret, "Unauthorized request", msg_len);
+        return KADM5_AUTH_CHANGEPW;
+    } else if (ret != KADM5_OK) {
+        return ret;
+    }
if (auth(handle->context, OP_CPW, client, target,
NULL, NULL, NULL, NULL, 0)) {
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use