Upstream reports that the MIT krb5 kadmind daemon incorrectly accepts authentications to two-component server principals whose first component is a left substring of "kadmin" or whose realm is a left prefix of the default realm. An attacker who possess the key of a particularly named principal (such as "kad/root") could impersonate any user to kadmind and perform administrative actions as that user. When kadmind receives a request using the RPCSEC_GSS authentication flavor, it queries the GSS-API security context for the server principal name and attempts to verify that it is a two-component principal name where the first component is "kadmin", the second component is not "history", and the realm is the default realm. The validation function incorrectly uses strcmp() to compare the length-counted principal name components against null-terminated C strings for "kadmin", "history", and the default realm. These comparisons erroneously succeed for left substrings of the of the desired C strings, so for example a first principal name component of "ka" would be accepted. kadmind can receive authentications to any server principal entry in the Kerberos database (excluding entries with either the DISALLOW_SVR or DISALLOW_ALL_TIX flags set). If the database contains an erroneously matching principal entry such as "ka/x", and an attacker knows the key for that entry, the attacker can conduct an escalation of privilege attack by forging tickets from any client principal name to that server principal. By picking a client principal name with administrative privileges, the attacker could perform arbitrary administrative operations on the Kerberos database. Suggested patch to fix this issue, as well as CVE-2014-5352, CVE-2014-9421 and CVE-2014-9423 is attached to https://bugzilla.redhat.com/show_bug.cgi?id=1179856
Acknowledgements: Red Hat would like to thank the MIT Kerberos project for reporting this issue.
According to MIT kadmind is vulnerable in all released versions of MIT krb5.
External References: http://web.mit.edu/Kerberos/advisories/MITKRB5-SA-2015-001.txt
Created krb5 tracking bugs for this issue: Affects: fedora-all [bug 1188869]
Upstream commit: https://github.com/krb5/krb5/commit/6609658db0799053fbef0d7d0aa2f1fd68ef32d8
Statement: Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:0439 https://rhn.redhat.com/errata/RHSA-2015-0439.html
krb5-1.11.5-18.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Ganesh from comment #10) > RHEL 6 is never mentioned on this Bug. Customer saw that these affect RHEL 6 > however. Do we have plan to release a fix for 6? It's part of krb5-1.10.3-35.el6_6 (RHEL6.6.z) ...
> This issue has been addressed in the following products: > > Red Hat Enterprise Linux 7 > > Via RHSA-2015:0439 https://rhn.redhat.com/errata/RHSA-2015-0439.html It's been a week since the fix for RHEL7 was published and still no mention of RHEL6. Is it in-process?(In reply to errata-xmlrpc from comment #9)
(In reply to Chris Cumbaa from comment #13) > > This issue has been addressed in the following products: > > > > Red Hat Enterprise Linux 7 > > > > Via RHSA-2015:0439 https://rhn.redhat.com/errata/RHSA-2015-0439.html > > It's been a week since the fix for RHEL7 was published and still no mention > of RHEL6. Is it in-process? See comment #12 ...
krb5-1.12.2-14.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
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