Hide Forgot
Upstream reports that in the MIT krb5 libgssapi_krb5 library, after gss_process_context_token() is used to process a valid context deletion token, the caller is left with a security context handle containing a dangling pointer. Further uses of this handle will result in use-after-free and double-free memory access violations. libgssrpc server applications such as kadmind are vulnerable as they can be instructed to call gss_process_context_token(). The krb5 mechanism implementation of gss_process_context_token(), upon successfully validating a deletion token, frees the security context structure. This behavior is incorrect as the API has no way to alert the caller that the security context was deleted. The application is left with a valid pointer to a mechglue security context structure, containing a dangling pointer to a freed krb5 security context structure. Any further use of this handle will result in a use-after-free violation and eventually a double-free when the handle is deleted with gss_delete_sec_context(). This vulnerability could theoretically lead to the execution of malicious code, but that is believed to be difficult. Applications which call gss_process_context_token() are believed to be rare, but the server code in the old flavor of libgssrpc GSS-API authentication can be induced to call gss_process_context_token(). In release krb5-1.9 and earlier, the krb5 GSS mechanism contained pointer validation code which should prevent subsequent dereferences of the freed pointer. In these earlier releases, the vulnerability is believed to be limited to a memory leak because gss_delete_sec_context() will not free the mechglue security context structure. Suggested path to fix this vulnerability as well as CVE-2014-9421, CVE-2014-9422 and CVE-2014-9423 is attached.
Created attachment 977438 [details] krb5.patch This patch is against release krb5-1.13. It will apply to krb5-1.12 and krb5-1.11 with some fuzz if the t_prf.c hunk is removed, and to krb5-1.10 if the mglueP.h hunk is also removed.
Acknowledgements: Red Hat would like to thank the MIT Kerberos project for reporting this issue. The MIT Kerberos project acknowledges Nico Williams for assisting with the analysis of CVE-2014-5352.
According to MIT, kadmind in all released versions of MIT krb5 is vulnerable. Third-party server applications using libgssrpc from all releases of MIT krb5 are vulnerable if they enable the AUTH_GSSAPI authentication flavor. Third-party client and server applications using GSS-API libraries from all releases of MIT krb5 are vulnerable if they directly call gss_process_context_token(). Such applications are believed to be rare. Releases krb5-1.9 and prior may be less vulnerable due to pointer validation code within the krb5 GSS-API mechanism; applications using those releases may instead only experience a memory leak
Created attachment 979243 [details] Backport of krb5.patch to krb5-1.12.2-final
Created attachment 979249 [details] Backport of krb5.patch to krb5-1.11.5-final
Created attachment 979263 [details] Backport of krb5.patch to krb5-1.10.7-final
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/82dc33da50338ac84c7b4102dc6513d897d0506a
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.
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