It was reported that if a privileged user randomized the keys for a service principal, the old key would be returned to them. This could lead to ticket forgery attacks on the service in question.
This issue has been fixed in upstream version 1.13. Red Hat Enterprise Linux 6 and 7 are affected.
Full details from the upstream report:
"" An authenticated remote attacker can retrieve the current keys for a service principal when generating a new set of keys for that principal. The attacker needs to be authenticated as a user who has the elevated privilege for randomizing the keys of other principals.
Normally, when a Kerberos administrator randomizes the keys of a service principal, kadmind returns only the new keys. This prevents an administrator who lacks legitimate privileged access to a service from forging tickets to authenticate to that service. If the "keepold" flag to the kadmin randkey RPC operation is true, kadmind retains the old keys in the KDC database as intended, but also unexpectedly returns the old keys to the client, which exposes the service to ticket forgery attacks from the administrator.
A mitigating factor is that legitimate clients of the affected service will start failing to authenticate to the service once they begin to receive service tickets encrypted in the new keys. The affected service will be unable to decrypt the newly issued tickets, possibly alerting the legitimate administrator of the affected service. ""
Upstream patch:
https://github.com/krb5/krb5/commit/af0ed4df4dfae762ab5fb605f5a0c8f59cb4f6ca
References:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8018
plugins/kdb/ldap/libkdbldap/ldapprincipal2.c in MIT Kerberos 5 (aka krb5) 1.12.x and 1.13.x before 1.13.1, when the KDC uses LDAP, allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) by creating a database entry for a keyless principal, as demonstrated by a kadmin "addprincipal -nokey" or "purgekeys -all" command.
MIT Kerberos 5 (aka krb5) through 1.13.1 incorrectly expects that a krb5readmessage data field is represented as a string ending with a '\0' character, which allows remote attackers to (1) cause a denial of service (NULL pointer dereference) via a zero-byte version string or (2) cause a denial of service (out-of-bounds read) by omitting the '\0' character, related to appl/useruser/server.c and lib/krb5/krb/recvauth.c.
The krb5gssprocesscontexttoken function in lib/gssapi/krb5/processcontexttoken.c in the libgssapikrb5 library in MIT Kerberos 5 (aka krb5) through 1.11.5, 1.12.x through 1.12.2, and 1.13.x before 1.13.1 does not properly maintain security-context handles, which allows remote authenticated users to cause a denial of service (use-after-free and double free, and daemon crash) or possibly execute arbitrary code via crafted GSSAPI traffic, as demonstrated by traffic to kadmind.
The (1) kadm5createprincipal3 and (2) kadm5modifyprincipal functions in lib/kadm5/srv/svrprincipal.c in kadmind in MIT Kerberos 5 (aka krb5) 1.12.x and 1.13.x before 1.13.4 and 1.14.x before 1.14.1 allow remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) by specifying KADM5POLICY with a NULL policy name.
The kdcpreauth modules in MIT Kerberos 5 (aka krb5) 1.12.x and 1.13.x before 1.13.2 do not properly track whether a client's request has been validated, which allows remote attackers to bypass an intended preauthentication requirement by providing (1) zero bytes of data or (2) an arbitrary realm name, related to plugins/preauth/otp/main.c and plugins/preauth/pkinit/pkinitsrv.c.
The processdbargs function in plugins/kdb/ldap/libkdbldap/ldapprincipal2.c in the LDAP KDB module in kadmind in MIT Kerberos 5 (aka krb5) through 1.13.4 and 1.14.x through 1.14.1 mishandles the DB argument, which allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted request to modify a principal.