In single-realm configurations backed by the LDAP kdb plugin, sending an AS request to the KDC for any realm other than the one it serves will cause a segfault in the KDC. After decoding the client request, setup_server_realm() is called to set various pointers to steer the request processing. If the KDC is configured to serve multiple realms, and the client's request doesn't match any of them, an error is generated and the server drops the request. Otherwise, the request is steered to the single realm, and processing continues. The KDC then attempts to retrieve the client's entry from the realm database. The krb5_ldap_get_principal() function compares the client's name's realm to the realm that's being searched and if they don't match returns a success code with a NULL entry pointer to the caller. The caller checks for an error, and if there is none, it attempts to dereference the entry to pass the entry's principal name to is_local_principal(), and the KDC segfaults. This also happens with the server entry as well, except there the KDC attempts to dereference the server entry to pass it to validate_tgs_request(). In versions prior to 1.9, the lookup returned a count of the number of results found, and if the count wasn't 1, an error was returned, so I don't think it was a problem in older releases. To verify, I tried but couldn't reproduce it with 1.6, 1.7, and 1.8. * krb5_ldap_get_principal() should probably set a non-zero status when is_principal_in_realm() fails * setup_server_realm() could change its behavior when only one realm is configured, but I'm not sure of the intent there Either change should prevent this crash.
* CVE-2011-1527: null pointer dereference in KDC LDAP back end In releases krb5-1.9 and later, the KDC can crash due to a null pointer dereference if configured to use the LDAP back end. A trigger condition is publicly known but not known to be widely circulated. Under certain error conditions, krb5_ldap_get_principal() in the KDC LDAP back end can return success yet leave the client principal entry as a null pointer. Subsequently executed code attempts to dereference this null pointer. An unauthenticated remote attacker can crash a KDC daemon via null pointer dereference if the KDC is configured to use the LDAP back end. (This is not the default configuration.) * CVE-2011-1528: assertion failure in multiple KDC back ends In releases krb5-1.8 and later, the KDC can crash due to an assertion failure. No exploit is known to exist, but there is public evidence that the unidentified trigger condition occurs in the field. In the KDC LDAP back end in releases krb5-1.8 and later, krb5_ldap_lockout_audit() calls assert() with an expression that could be false under as-yet unidentified conditions. A similar problem occurs in the KDC Berkeley DB ("db2") back end in krb5_db2_lockout_audit() in releases krb5-1.8 through krb5-1.8.4. (The db2 back end no longer has this assertion in releases krb5-1.9 and later, and is therefore not vulnerable.) There is a report that the assertion failure occurs in the field, but there is insufficient information to identify the actual vector. An unauthenticated remote attacker can crash a KDC daemon via assertion failure. * CVE-2011-1529: null pointer dereference in multiple KDC back ends In releases krb5-1.8 and later, the KDC can crash due to a null pointer dereference. No exploit is known to exist. In releases krb5-1.8 and later, lookup_lockout_policy() in both the Berkeley DB ("db2") and LDAP KDC back ends fails to check that the principal entry pointer is non-null prior to dereferencing it. This can happen if an error condition such as KRB5KDC_ERR_PREAUTH_FAILED or KRB5KRB_AP_ERR_BAD_INTEGRITY occurs in process_as_req() before it retrieves the principal database entry for the requested client. An unauthenticated remote attacker can crash a KDC daemon via null pointer dereference. Affected Software: * The KDC in krb5-1.9 and later is vulnerable to CVE-2011-1527 when configured with the LDAP back end. Earlier releases had different code that masked this bug and did not crash under these conditions. * The KDC in krb5-1.8 and later is vulnerable to CVE-2011-1528 when configured with the LDAP back end. When configured with the Berkeley DB ("db2") back end, only releases krb5-1.8 through krb5-1.8.4 are vulnerable. * The KDC in krb5-1.8 and later is vulnerable to CVE-2011-1529 when configured with either the Berkeley DB ("db2") or the LDAP back end.
Created attachment 524094 [details] upstream patch for 1.9 http://web.mit.edu/kerberos/advisories/2011-006-patch.txt
Created attachment 524095 [details] upstream patch for 1.8 http://web.mit.edu/kerberos/advisories/2011-006-patch-r18.txt
Statement: Not vulnerable. This issue did not affect the versions of krb5 as shipped with Red Hat Enterprise Linux 4 or 5.
This issue is now public. External References: http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2011-006.txt
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:1379 https://rhn.redhat.com/errata/RHSA-2011-1379.html
MITRE has assigned an additional CVE here: CVE-2011-4151 (breaking up what upstream had called CVE-2011-1528 into two distinct flaws): CVE-2011-1528: The krb5_ldap_lockout_audit function in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.8 through 1.8.4 and 1.9 through 1.9.1, when the LDAP back end is used, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via unspecified vectors, related to the locked_check_p function. CVE-2011-4151: The krb5_db2_lockout_audit function in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.8 through 1.8.4, when the db2 (aka Berkeley DB) back end is used, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via unspecified vectors, a different vulnerability than CVE-2011-1528.
Statement CVE-2011-4151: Not vulnerable. This issue did not affect the versions of krb5 as shipped with Red Hat Enterprise Linux 4, 5 or 6.
krb5-1.9.1-14.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
krb5-1.8.4-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Fedora 16 was fixed in krb5-1.9.1-18.fc16, pushed via mass glibc bug rebuild update: https://admin.fedoraproject.org/updates/FEDORA-2011-15065