8.107. krb5

Security Fixes

CVE-2013-1418, CVE-2013-6800

It was found that if a KDC served multiple realms, certain requests could cause the setup_server_realm() function to dereference a NULL pointer. A remote, unauthenticated attacker could use this flaw to crash the KDC using a specially crafted request.

CVE-2014-4344

A NULL pointer dereference flaw was found in the MIT Kerberos SPNEGO acceptor for continuation tokens. A remote, unauthenticated attacker could use this flaw to crash a GSSAPI-enabled server application.

CVE-2014-4345

A buffer overflow was found in the KADM5 administration server (kadmind) when it was used with an LDAP back end for the KDC database. A remote, authenticated attacker could potentially use this flaw to execute arbitrary code on the system running kadmind.

CVE-2014-4341, CVE-2014-4342

Two buffer over-read flaws were found in the way MIT Kerberos handled certain requests. A remote, unauthenticated attacker who is able to inject packets into a client or server application's GSSAPI session could use either of these flaws to crash the application.

CVE-2014-4343

A double-free flaw was found in the MIT Kerberos SPNEGO initiators. An attacker able to spoof packets to appear as though they are from an GSSAPI acceptor could use this flaw to crash a client application that uses MIT Kerberos.

Bug Fixes

BZ#922884

Previously, when connecting to a Key Distribution Center (KDC) over a Transmission Control Protocol (TCP) socket, the Kerberos client library was unable to detect cases when the server prematurely terminated the connection. Consequently, the client could stall, repeatedly attempting to read data from the closed connection's socket descriptor. This bug has been fixed, the client library now correctly detects connection failure and the processing continues as expected.

BZ#1070244

Previously, when called to accept ticket-based authentication from a client, a server was able to decrypt a ticket which was encrypted with one encryption type (for example, des-cbc-crc) as long as its keytab contained a key of a sufficiently-compatible encryption type (for example, des-cbc-md5). Due to a regression, servers became unable to verify client tickets in these cases unless the encryption types were identical. With this update, a backported fix has been introduced to restore the aforementioned behavior. As a result, servers now verify clients' tickets when the key distribution center (KDC) issues a ticket using an encryption type with sufficient compatibility.

BZ#965721

Prior to this update, on systems which were configured to use the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension, issuing the "kinit -k" command to obtain credentials using keys in a keytab could fail if the "pkinit_identities" variable was set in the /etc/krb5.conf file. The problem occurred when the directive resolved to a smart card protected by a PIN or to an encrypted PEM or PKCS#12 format file. The client's PKINIT plug-in could attempt to prompt the user for a password or smart card PIN, which the kinit utility was unable to handle. Consequently, the kinit utility terminated unexpectedly with a segmentation fault. A patch has been applied, the PKINIT plug-in now checks that the invoking application provides a way to prompt for passwords and smart card PINs before attempting to prompt the user for them, and kinit no longer crashes in this scenario.

BZ#1055329

Prior to this update, the libkrb5 library sometimes attempted to free already freed memory when encrypting credentials intended for delegation. As a consequence, the calling process terminated unexpectedly with a segmentation fault. With this update, libkrb5 frees memory correctly, which allows the credentials to be encrypted appropriately, preventing the crash.

BZ#1026721

Previously, using the ksu command without the "-n" or "-e" options caused ksu to discard the information about which principals were authorized to use it, as specified in the target user's .k5users file. Consequently, an "authorization failed" error message was displayed, even if the configuration indicated that user was authorized. This bug has been fixed and ksu no longer returns the incorrect error message in this situation.

BZ#1113652

Previously, when using Domain Name System (DNS) to locate KDCs while following referrals, if the Kerberos client library determined that it needed to locate a master KDC for a given realm along a referral path, it attempted to contact only master KDCs for any realms further along that path. As a consequence, an attempt to get credentials could fail if the client library needed to follow referrals from one realm to another and one of the realms contacted along the way did not have its master KDCs specifically named in DNS. A patch has been applied and the described problem no longer occurs.

BZ#1009389

The init script that launches the KDC runs a diagnostic helper first, attempting to diagnose a common upgrade-related error. Previously, when the default realm was configured only in the /etc/sysconfig/krb5kdc configuration file and not in the /etc/krb5.conf file, the realm was not passed to the helper. As a consequence, the attempt to start the KDC failed with an error message. With this update, the default realm set in /etc/sysconfig/krb5kdc file is correctly passed to the helper and the KDC is correctly started.

BZ#1059730

Prior to this update, when attempting to locate Kerberos servers using the DNS service location, the Kerberos client library did not correctly recognize all return codes from the resolver libraries. Consequently, the client library misinterpreted certain non-fatal return codes as fatal errors, and failed to locate any servers. A patch has been applied, the client library interprets the return codes correctly, and locating servers now works as expected.

BZ#1087068

Due to a regression, when using the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) with multiple object identifiers (OID), the server applications did not always respond to clients using the same OID that the clients had specified. As a consequence, GSSAPI clients that attempted to use mechanisms which can be identified using more than one OID could fail to authenticate to such servers. With this update, when generating replies to clients, the GSSAPI library uses the OID specified by the client in its request, and client authentication no longer fails in this scenario.