AI_ONLY_REPORT
package: sssd-2.12.0-1.el10
------
Summary: Potential HBAC Authorization Bypass via Cross-Domain Shortname  
Collision: in trust-enabled IPA HBAC deployments, a trusted-domain user  
whose shortname collides with an IPA-local user may satisfy user-specific  
HBAC allow rules because both the request identity and the rule identity  
are normalized to shortname-only values before comparison.
Requirements to exploit: IPA HBAC must be in use through SSSD,  
trusted-domain or subdomain users must be evaluated by the IPA HBAC path,  
and an HBAC allow rule must reference an IPA-local user directly by name.  
The attacker must be able to authenticate as a trusted-domain account whose  
shortname collides with that IPA-local user.
Component affected: `sssd-2.12.0-1.el10`; IPA HBAC user matching in  
`src/providers/ipa/ipa_hbac_common.c` (`hbac_ctx_to_eval_request()`,  
`hbac_eval_user_element()`), `src/providers/ipa/ipa_hbac_users.c`  
(`hbac_user_attrs_to_rule()`), and `src/lib/ipa_hbac/hbac_evaluator.c`  
(`hbac_evaluate_element()`)
Version affected: `sssd-2.12.0-1.el10` when deployed with IPA HBAC in a  
trusted-domain or subdomain configuration that evaluates trusted-domain  
users through this path
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:H/I:H/A:N - 7.2 (HIGH)
AV:N - Exploitation occurs through remote authentication paths protected  
by HBAC, such as network service logins handled through PAM and SSSD.
AC:H - Successful exploitation requires a trust-enabled IPA deployment,  
a cross-domain shortname collision, and an HBAC rule that names the  
IPA-local user directly.
PR:L - The attacker must authenticate as a low-privileged trusted-domain  
account with the colliding shortname.
UI:N - No separate victim interaction is required once the attacker can  
attempt authentication.
S:U - The flaw alters the authorization result within the same HBAC  
enforcement scope.
C:H - A successful bypass can expose services or host resources that  
HBAC was intended to keep unavailable to that trusted-domain user.
I:H - The same unauthorized access can permit policy-forbidden actions  
within the protected service or host context.
A:N - The available evidence supports authorization bypass, not a direct  
denial of service.
Impact: Moderate. Successful exploitation can bypass a configured  
authorization boundary and grant unauthorized access to services or hosts  
protected by IPA HBAC, but the issue is materially constrained by  
deployment-specific prerequisites: trusted-domain support must be in use,  
the same shortname must exist across domains, and the affected HBAC rule  
must target the IPA-local user by name. Under Red Hat's severity guidance,  
this is a meaningful security issue, but it is less easily exploited and  
narrower than a broadly reachable Important flaw.
Embargo: no
Reason: The issue is configuration-dependent, requires a colliding  
trusted-domain account plus a matching HBAC policy, and is not broadly  
default-reachable across deployments.
Acknowledgement: Aisle Research
Vulnerability Details: Trusted-domain users are explicitly routed into the  
same IPA HBAC evaluation path, after which both the request user and the  
rule user entry are reduced to shortname-only values by  
`sss_parse_internal_fqname()`, and `hbac_evaluate_element()` compares only  
those reduced names case-insensitively. The helper is documented in-tree to  
accept `shortname@domname` and return the `shortname` portion through  
`_shortname`, so the domain component is discarded before the final  
comparison. As a result, an HBAC rule intended for `admin` can  
also match `admin` if both share the same shortname. The  
visible group-handling logic in this area separately filters non-IPA groups  
before comparison, so the supported finding here is the direct user-name  
path rather than a general group-name collision issue. This is consistent  
with CWE-863 (Incorrect Authorization).
```c
/* src/providers/ipa/ipa_hbac_common.c */
ret = sss_parse_internal_fqname(tmp_ctx, username, &shortname, NULL);
if (ret != EOK) {
ret = ERR_WRONG_NAME_FORMAT;
goto done;
}
users->name = talloc_steal(users, shortname);
...
/* src/providers/ipa/ipa_hbac_users.c */
ret = sss_parse_internal_fqname(tmp_ctx, sysdb_name,
&shortname, NULL);
...
new_users->names[num_users] = talloc_strdup(new_users->names,
shortname);
...
/* src/lib/ipa_hbac/hbac_evaluator.c */
rule_name = (const uint8_t *) rule_el->names[i];
req_name = (const uint8_t *) req_el->name;
/* Do a case-insensitive comparison. */
ret = sss_utf8_case_eq(rule_name, req_name);
```
Steps to reproduce:
1. Configure an IPA environment with SSSD, enable HBAC, and add a trusted  
domain or subdomain so trusted-domain users authenticate through the same  
IPA HBAC path.
2. Create an IPA-local user such as `admin`.
3. Create an HBAC allow rule scoped to a specific host and service that  
allows only that IPA-local user by name.
4. In the trusted domain, create or use a user such as  
`admin` with the same shortname.
5. Attempt authentication to the protected service from  
`admin`.
6. Observe that access is allowed because the HBAC user comparison is  
performed on `admin` versus `admin` after domain stripping.
7. For confirmation, enable SSSD debug logging and verify that the allow  
decision is made by the matching HBAC rule even though the domains differ.
Mitigation: Until a fix is available, audit HBAC rules that directly name  
IPA-local users, identify shortname collisions with trusted domains, and  
remove or rename conflicting accounts or rules where possible. If  
trusted-domain access is not required for the protected services or hosts,  
restrict those logins until domain-qualified matching is implemented.
Proposed Fix: Preserve the internal fully qualified name for both the  
request-side user element and the rule-side user entry so that HBAC user  
matching retains domain identity instead of reducing both sides to  
shortnames.
```diff
diff --git a/src/providers/ipa/ipa_hbac_common.c  
b/src/providers/ipa/ipa_hbac_common.c
— a/src/providers/ipa/ipa_hbac_common.c
+++ b/src/providers/ipa/ipa_hbac_common.c
@@ -396,11 +396,9 @@ hbac_eval_user_element(TALLOC_CTX *mem_ctx,
   ret = sss_parse_internal_fqname(tmp_ctx, username, &shortname, NULL);

   if (ret != EOK) {

       ret = ERR_WRONG_NAME_FORMAT;

       goto done;

   }

   users->name = talloc_steal(users, shortname);
+    users->name = talloc_strdup(users, username);
+    if (users->name == NULL) {
+        ret = ENOMEM;
+        goto done;
+    }


diff --git a/src/providers/ipa/ipa_hbac_users.c  
b/src/providers/ipa/ipa_hbac_users.c
— a/src/providers/ipa/ipa_hbac_users.c
+++ b/src/providers/ipa/ipa_hbac_users.c
@@ -260,10 +260,8 @@ hbac_user_attrs_to_rule(TALLOC_CTX *mem_ctx,
           ret = sss_parse_internal_fqname(tmp_ctx, sysdb_name,

                                           &shortname, NULL);

           if (ret != EOK) {

               DEBUG(SSSDBG_CRIT_FAILURE,

                     "Cannot parse %s, skipping\n", sysdb_name);

               continue;

           }
              new_users->names[num_users] = talloc_strdup(new_users->names,

                                                       shortname);
+                                                        sysdb_name);
+            if (new_users->names[num_users] == NULL) {
+                ret = ENOMEM;
+                goto done;
+            }
```


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