Bug 1193939 (CVE-2014-5355)

Summary: CVE-2014-5355 krb5: unauthenticated denial of service in recvauth_common() and others
Product: [Other] Security Response Reporter: Vasyl Kaigorodov <vkaigoro>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: bbaranow, bmaxwell, cdewolf, csutherl, dandread, darran.lofthouse, dknox, dpal, drieden, fnasser, jason.greene, jawilson, jboss-set, jclere, jdoyle, jplans, kerberos-dev-list, lgao, mbabacek, myarboro, nalin, nathaniel, pgier, pkis, psakar, pslavice, rsvoboda, sbose, twalsh, vtunka, weli
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
It was found that the krb5_read_message() function of MIT Kerberos did not correctly sanitize input, and could create invalid krb5_data objects. A remote, unauthenticated attacker could use this flaw to crash a Kerberos child process via a specially crafted request.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-20 05:44:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1200906, 1204210, 1204211, 1205850    
Bug Blocks: 1179866, 1193283, 1193941, 1210268    

Description Vasyl Kaigorodov 2015-02-18 15:26:46 UTC
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

Comment 2 Stefan Cornelius 2015-03-11 15:40:59 UTC
Created krb5 tracking bugs for this issue:

Affects: fedora-all [bug 1200906]

Comment 3 Stefan Cornelius 2015-03-11 16:05:58 UTC
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.

Comment 7 errata-xmlrpc 2015-04-09 05:09:39 UTC
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

Comment 8 errata-xmlrpc 2015-11-19 05:13:05 UTC
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