From upstream commit [1]: """ In MIT krb5, when a server process uses the krb5_recvauth function, an unauthenticated remote attacker can cause a NULL dereference by sending a zero-byte version string, or a read beyond the end of allocated storage by sending a non-null-terminated version string. The example user-to-user server application (uuserver) is similarly vulnerable to a zero-length or non-null-terminated principal name string. The krb5_recvauth function reads two version strings from the client using krb5_read_message(), which produces a krb5_data structure containing a length and a pointer to an octet sequence. krb5_recvauth assumes that the data pointer is a valid C string and passes it to strcmp() to verify the versions. If the client sends an empty octet sequence, the data pointer will be NULL and strcmp() will dereference a NULL pointer, causing the process to crash. If the client sends a non-null-terminated octet sequence, strcmp() will read beyond the end of the allocated storage, possibly causing the process to crash. uuserver similarly uses krb5_read_message() to read a client principal name, and then passes it to printf() and krb5_parse_name() without verifying that it is a valid C string. The krb5_recvauth function is used by kpropd and the Kerberized versions of the BSD rlogin and rsh daemons. These daemons are usually run out of inetd or in a mode which forks before processing incoming connections, so a process crash will generally not result in a complete denial of service. """ [1]: https://github.com/krb5/krb5/commit/102bb6ebf20f9174130c85c3b052ae104e5073ec
Created krb5 tracking bugs for this issue: Affects: fedora-all [bug 1200906]
The problems in the recvauth_common() function appear to be the most interesting ones to us, as this function is called by the krb5_recvauth() function, which in turn is used by a few services supporting krb5 auth. An unauthenticated attacker can use this to crash a server using the krb5_recvauth() function due to e.g. NULL pointer dereference (meaning that arbitrary code execution should not be possible). In the most cases the server will probably do this in a child process, which means that only the child process will crash and the overall service should remain available, which further mitigates this vulnerability.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:0794 https://rhn.redhat.com/errata/RHSA-2015-0794.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:2154 https://rhn.redhat.com/errata/RHSA-2015-2154.html