An unauthenticated LDAP client (anonymous bind or SASL ANONYMOUS) can create a self-managed OTP token entry with empty ipaTokenOwner/managedBy attributes, which satisfy 389 Directory Server's SELFDN ACI evaluator against the anonymous bind's own empty DN (see companion 389-ds flaw for that underlying defect). FreeIPA's self-managed-token ACI (install/share/default-aci.ldif) does not restrict which other attributes may be added, allowing the client to inject a Kerberos principal and password. Combined with a canonical-principal mismatch and, on older releases, a password-expiration-bypass, this produces genuine, reusable FreeIPA administrator Kerberos credentials. On SID-enabled deployments, the anonymously-readable ipaNTSecurityIdentifier attribute lets the attacker also obtain a PAC-bearing TGT, extending access to HTTP/Dogtag.

Independently reproduced twice against a stock, unmodified freeipa/freeipa-server:almalinux-10 (FreeIPA 4.13.1) install — most recently from a client with zero prior access (no ticket, no local presence, network reachability only). Verified beyond the PoC's own output via klist -f, ldapwhoami -Y GSSAPI (returned genuine admin DN), ldapcompare (confirmed cn=admins membership), and a real admin-only write/delete (ipa user-add / ipa user-del).

Reported by Gia Bui (Calif.io) via PSIRTSUPT-21812; see linked ticket for full technical writeup, reporter PoC, and reproduction logs.

A flaw was found in FreeIPA. The trust-fetch-domains command, used to refresh Active Directory trust topology, is gated only by the read-level ACI on the trust object (System: Read Trust Information, granted to any authenticated IPA user by default) rather than a trust-administration-level permission. Any authenticated, non-privileged IPA user can therefore invoke ipa trust-fetch-domains, which calls a root-owned oddjobd/D-Bus helper (install/oddjob/com.redhat.idm.trust-fetch-domains.in). When the caller supplies --admin/--password, the helper calls kinitpassword() against a caller-chosen --server using attacker-supplied credentials, with no cross-check that they belong to the real trusted AD forest, then accepts whatever forest-trust topology (domain names, NetBIOS names, SIDs) that attacker-controlled server returns via ipaserver/dcerpc.py's fetchdomains()/discovertrustinstance(). This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by trust.addnewdomainsfromtrust(). The authorization gap itself (an unprivileged, non-admin user's request reaching the root-owned helper's execution with no ACI rejection) was reproduced dynamically in an isolated sandbox against ipa-server-4.13.5, confirmed against a negative control (an unrelated admin-only operation was correctly rejected in the same session). The exploiting principal holds zero delegated privilege — this is not a case of a narrow administrative delegation being used beyond its intended scope.

A flaw was found in FreeIPA. A remote, unauthenticated attacker can exploit a vulnerability in the /ipa/i18nmessages endpoint by sending an arbitrarily large request body. This can cause the service to consume excessive memory, leading to memory exhaustion, degraded responsiveness, and a denial of service (DoS) condition.

A flaw was reported [1] in FreeIPA 4.0/4.1 where users could log in using only the OTP value. This arose because ipapwdauthentication() successfully determined that an empty password was invalid, but 389 itself would see this as an anonymous bind.

This will be fixed in the next release [2]. As support for OTP is not available in earlier versions, only FreeIPA >= 4.0 is affected.

[1] https://fedorahosted.org/freeipa/ticket/4690 [2] https://www.redhat.com/archives/freeipa-devel/2014-November/msg00068.html

Acknowledgements:

Red Hat would like to thank FreeIPA upstream for reporting this issue.

Statement:

This issue did not affect the versions of IPA as shipped with Red Hat Enterprise Linux 5, 6, or 7 as they did not include support for OTP.

Sumit Bose discovered that FreeIPA's directory server (dirsrv) would segfault if an unauthenicated user attempted to connect to it with a missing username/dn. According to RFC 3062, connecting without specifying the username/dn is valid.

Acknowledgements:

This issue was discovered by Sumit Bose of Red Hat.