AIONLYREPORT package: ipa-4.13.1-3.el10 ------ Summary: NULL Pointer Dereference in ipa-enrollment Extended Operation (JOINOID) via Missing Request Value: in deployments using the ipa-enrollment SLAPI plugin from ipa-4.13.1-3.el10, a non-anonymous authenticated LDAP client can omit the request value for JOINOID and trigger a NULL pointer dereference in ipajoin(), leading to Directory Server denial of service. Requirements to exploit: Reach a deployment built from ipa-4.13.1-3.el10 where the ipa-enrollment SLAPI plugin is enabled, establish LDAP over a secure channel with SSF greater than 1, authenticate with a non-anonymous account, and send JOINOID without a request value. Component affected: ipa-4.13.1-3.el10: daemons/ipa-slapi-plugins/ipa-enrollment/ipaenrollment.c, ipajoin() via ipaenrollmentextop() handling of JOINOID Version affected: ipa-4.13.1-3.el10 in deployments where the ipa-enrollment SLAPI plugin is built and enabled 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:L/PR:L/UI:N/S:U/C:N/I:N/A:H - 6.5 (MEDIUM) AV:N - The issue is reachable over the network through LDAP when the vulnerable plugin is exposed. AC:L - The trigger is a simple malformed extended operation with the request value omitted. PR:L - ipajoin() rejects anonymous binds before the dereference, so a non-anonymous authenticated account is required. UI:N - No user interaction is needed once the attacker can send the LDAP request. S:U - The impact is limited to the vulnerable directory service component. C:N - No confidentiality impact is established from the available evidence. I:N - No integrity impact is established from the available evidence. A:H - The NULL dereference can crash the process or otherwise deny Directory Server availability, depending on runtime handling. Impact: Important. This issue lets a remote authenticated client directly compromise service availability with low attack complexity by sending a malformed LDAP extended operation. That aligns with Red Hat's Important rating for flaws that allow remote denial of service, while falling short of Critical because exploitation requires authentication and no confidentiality, integrity, or code-execution impact is established. Embargo: no Reason: The established impact is authenticated denial of service only, with no demonstrated confidentiality or integrity exposure, and the remediation is a straightforward server-side input validation change. Acknowledgement: Aisle Research Vulnerability Details: ipaenrollmentextop() routes JOINOID requests into ipajoin() after OID and secure-connection checks. Inside ipajoin(), the code retrieves SLAPIEXTOPREQVALUE and immediately dereferences extopvalue->bvval without verifying that the request value is present: c / Get the ber value of the extended operation / slapipblockget(pb, SLAPIEXTOPREQVALUE, &extopvalue); / We are passed in the FQDN of the host to enroll. Do an internal search and pull that entry. / filter = slapichsmprintf("(fqdn=%s)", extopvalue->bvval);
A non-anonymous authenticated caller that omits the request value can therefore reach a NULL pointer dereference before the function performs its internal search and before later enrollment ACL checks. Other extended operation handlers in the same source tree explicitly reject NULL or empty request values before use, which supports treating this as a reachable malformed-input case rather than a purely theoretical source defect. Based on the available evidence, the security impact established here is denial of service; the exact failure mode may vary with runtime handling. Steps to reproduce: 1. Use a Directory Server deployment built from ipa-4.13.1-3.el10 where the ipa-enrollment SLAPI plugin is enabled. 2. Connect to LDAP over a secure channel such as StartTLS or LDAPS so that the connection has SSF greater than 1. 3. Bind as a non-anonymous authenticated user, then send LDAP extended operation OID 2.16.840.1.113730.3.8.10.3 (JOINOID) with no request value. 4. Observe a server-side crash or equivalent denial-of-service condition when ipajoin() dereferences extopvalue->bvval. Mitigation: Until a fixed package is available, restrict access to the enrollment extended operation to trusted authenticated clients only. Where host enrollment is not required, disabling the ipa-enrollment SLAPI plugin removes this attack surface. These measures reduce exposure but do not correct the missing NULL check. Proposed Fix: Validate extopvalue immediately after slapipblockget() and reject missing or empty request values before building the internal search filter. diff diff --git a/freeipa-4.13.1/daemons/ipa-slapi-plugins/ipa-enrollment/ipaenrollment.c b/freeipa-4.13.1/daemons/ipa-slapi-plugins/ipa-enrollment/ipaenrollment.c @@ -167,6 +167,14 @@ ipajoin(SlapiPBlock pb) / Get the ber value of the extended operation / slapipblockget(pb, SLAPIEXTOPREQVALUE, &extopvalue); + if (extopvalue == NULL || extopvalue->bvval == NULL || extopvalue->bvlen == 0) { + errMesg = "Missing or empty enrollment request value.\n"; + rc = LDAPPROTOCOLERROR; + goto freeandreturn; + } + / We are passed in the FQDN of the host to enroll. Do an internal search and pull that entry. /
------ This report was generated using AI technology. Always review AI-generated content prior to use
Although CVE-2025-4404 fixed the lack of verification for the uniqueness of the LDAP attribute krbCanonicalName in FreeIPA, it doesn't prevent to achieve the same privilege escalation by using the the root kbrcanonicalname.
A flaw was found in the FreeIPA API audit, where it sends the whole FreeIPA command line to journalctl. As a consequence, during the FreeIPA installation process, it inadvertently leaks the administrative user credentials, including the administrator password, to the journal database. In the worst-case scenario, where the journal log is centralized, users with access to it can have improper access to the FreeIPA administrator credentials.
The FreeIPA API audit sends the whole FreeIPA ccommand line to journalctl, as consequence during the FreeIPA installation process inadvertently ends up leaking the administrative user credentials (including the administrator password) to the journal database. On worst case scenario where the journal log is centralized, users with access to it can have improper access to the FreeIPA administrator credentials.
A vulnerability was found in FreeIPA in how the initial implementation of MS-SFU by MIT Kerberos was missing a condition for granting the "forwardable" flag on S4U2Self tickets. Fixing this mistake required adding a special case for the checkallowedtodelegate() function: If the target service argument is NULL, then it means the KDC is probing for general constrained delegation rules and not checking a specific S4U2Proxy request. In FreeIPA 4.11.0, the behavior of ipadbmatchacl() was modified to match the changes from upstream MIT Kerberos 1.20. However, a mistake resulting in this mechanism applies in cases where the target service argument is set AND where it is unset. This results in S4U2Proxy requests being accepted regardless of whether or not there is a matching service delegation rule.
A flaw was found in all ipa versions 4.x.x through 4.8.0. When sending a very long password (>= 1,000,000 characters) to the server, the password hashing process could exhaust memory and CPU leading to a denial of service and the website becoming unresponsive. The highest threat from this vulnerability is to system availability.
ipa 3.0 does not properly check server identity before sending credential containing cookies
A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way the internal function berscanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server.
A flaw was found in FreeIPA versions 4.5.0 and later. Session cookies were retained in the cache after logout. An attacker could abuse this flaw if they obtain previously valid session cookies and can use this to gain access to the session.
A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way that FreeIPA's batch processing API logged operations. This included passing user passwords in clear text on FreeIPA masters. Batch processing of commands with passwords as arguments or options is not performed by default in FreeIPA but is possible by third-party components. An attacker having access to system logs on FreeIPA masters could use this flaw to produce log file content with passwords exposed.
A vulnerability was found in ipa before 4.4. IdM's ca-del, ca-disable, and ca-enable commands did not properly check the user's permissions while modifying CAs in Dogtag. An authenticated, unauthorized attacker could use this flaw to delete, disable, or enable CAs causing various denial of service problems with certificate issuance, OCSP signing, and deletion of secret keys.
DISPUTED FreeIPA 4.x with API version 2.213 allows a remote authenticated users to bypass intended account-locking restrictions via an unlock action with an old session ID (for the same user account) that had been created for an earlier session. NOTE: Vendor states that issue does not exist in product and does not recognize this report as a valid security concern.
Due to a missing permission check, certprofile-mod can be used by an authenticated but unprivileged user to modify certificate profile configuration. This could allow the issuance of certificates with fraudulent subject naming information (allowing the holder of the private key to impersonate another entity), or inappropriate key usage or extended key usage information (use of certificate for unauthorised purposes e.g. code signing).
Affected versions : 4.2 and above (all versions supporting certificate profiles)
Upstream patch : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=fec4c32ff15a96736740cf7d2f713a21af0b227e
The certrevoke command in FreeIPA does not check for the "revoke certificate" permission, which allows remote authenticated users to revoke arbitrary certificates by leveraging the "retrieve certificate" permission.
A flaw was found that allows any unauthenticated party to easily run DoS attack against kerberized services in FreeIPA/IdM realm.
FreeIPA contains MIT KDC as its main component + FreeIPA is using custom database driver for the KDC. As a side-effect of implementation, FreeIPA is enforcing password policies for all principals, including services which do not use "password" but keytab with randomly-generated/strong key.
Default password policy locks an account after 5 unsuccessful authentication attempts for 10 minutes. An attacker can use this to simply lock-out any principal, including system services.
Upstream patch : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=6f1d927467e7907fd1991f88388d96c67c9bff61
Additional dependency : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=73f33569c8893610e246b2f44a7aeaec872b37e6
FreeIPA 4.4.0 allows remote attackers to request an arbitrary SAN name for services.
It was found that FreeIPA fails to check the CA ACLs properly, moreover the SAN name is incorrectly checked for service principals which means someone can request an arbitrary SAN name for services.
The vulnerable code was added in the 4.4.0 release, which is not yet available in Fedora or RHEL.
ipa-kra-install in FreeIPA before 4.2.2 puts the CA agent certificate and private key in /etc/httpd/alias/kra-agent.pem, which is world readable.
alich in the FreeIPA bug tracker reported:
A number of non printable strings can cause FreeIPA to improperly display user data, potentially modifying what is shown to an administrator.
External Reference: https://fedorahosted.org/freeipa/ticket/5153
alich in the FreeIPA bug tracker reported:
A number of non printable strings can cause FreeIPA to improperly display user data, potentially modifying what is shown to an administrator.
External Reference: https://fedorahosted.org/freeipa/ticket/5153
An XSS flaw was reported in FreeIPA 4.x that could allow an administrator with lower privileges (such as sudo rights) to escalate their privileges to full administrator.
Earlier versions of FreeIPA/IPA do not suffer from this flaw.
Statement:
This issue did not affect the versions of IPA as shipped with Red Hat Enterprise Linux 6 or 7 as they do not include the vulerable Web UI code.
An XSS flaw was reported in FreeIPA 4.x that could allow an administrator with lower privileges (such as sudo rights) to escalate their privileges to full administrator.
Earlier versions of FreeIPA/IPA do not suffer from this flaw.
Statement:
This issue did not affect the versions of IPA as shipped with Red Hat Enterprise Linux 6 or 7 as they do not include the vulerable Web UI code.
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.
The client in FreeIPA 2.x and 3.x before 3.1.2 does not properly obtain the Certification Authority (CA) certificate from the server, which allows man-in-the-middle attackers to spoof a join procedure via a crafted certificate.
Cross-site request forgery (CSRF) vulnerability in the management interface in FreeIPA before 2.1.4 allows remote attackers to hijack the authentication of administrators for requests that make configuration changes.
IPA contains a flaw in where installations of freipa/RHEIPA exposed the Master Kerberos Password through anonymous queries.
The Master Kerberos Password is used to encrypt keys, however this flaw does not lead to individual keys being exposed. By itself this flaw has limited scope, but could be combined with a different flaw which could reveal user credentials.