It was reported [1] that, within the kadmin protocol, the access controls for getstrings/setstring were insufficient; anyone with global list privileges could get or modify string attributed on any principal.

It was also noted that the exposure depends on how generous the kadmind acl was with list permissions and whether or not string attributes were used in deployment (and noting that nothing in the core code uses them yet).

This has been fixed upstream [2] and in Fedora [3].

[1] http://krbdev.mit.edu/rt/Ticket/Display.html?user=guest&pass=guest&id=7093 [2] http://src.mit.edu/fisheye/changelog/krb5/?cs=25704 [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=300840

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 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.