Hash: SHA1

             AUSCERT External Security Bulletin Redistribution

                    MIT krb5 Security Advisory 2015-001
                              4 February 2015


        AusCERT Security Bulletin Summary

Product:           krb5
Publisher:         MIT
Operating System:  UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Administrator Compromise        -- Existing Account      
                   Execute Arbitrary Code/Commands -- Existing Account      
                   Denial of Service               -- Existing Account      
                   Access Confidential Data        -- Remote/Unauthenticated
Resolution:        Patch/Upgrade
CVE Names:         CVE-2014-9423 CVE-2014-9422 CVE-2014-9421

Original Bulletin: 

- --------------------------BEGIN INCLUDED TEXT--------------------

Hash: SHA1


MIT krb5 Security Advisory 2015-001
Original release: 2015-02-03
Last update: 2015-02-03

Topic: Vulnerabilities in kadmind, libgssrpc, gss_process_context_token

CVE-2014-5352: gss_process_context_token() incorrectly frees context


CVSSv2 Base Score:      9.0

Access Vector:          Network
Access Complexity:      Low
Authentication:         Single
Confidentiality Impact: Complete
Integrity Impact:       Complete
Availability Impact:    Complete

CVSSv2 Temporal Score:  7.0

Exploitability:         Proof-of-Concept
Remediation Level:      Official Fix
Report Confidence:      Confirmed

CVE-2014-9421: kadmind doubly frees partial deserialization results

CVSSv2 Base Score:      9.0
CVSSv2 Temporal Score:  7.0

CVE-2014-9422: kadmind incorrectly validates server principal name

CVSSv2 Base Score:      6.1
CVSSv2 Temporal Score:  4.8

CVE-2014-9423: libgssrpc server applications leak uninitialized bytes

CVSSv2 Vector: AV:N/AC:L/Au:N/C:P/I:N/A:N/E:H/RL:OF/RC:C
CVSSv2 Base Score:      5.0
CVSSv2 Temporal Score:  4.4


The MIT krb5 team has discovered four vulnerabilities affecting
kadmind.  Some of these vulnerabilities may also affect server
applications which use the gssrpc library or the
gss_process_context_token() function.  These are implementation
vulnerabilities, not vulnerabilities in the Kerberos protocol.

CVE-2014-5352: 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().

CVE-2014-9421: If the MIT krb5 kadmind daemon receives invalid XDR
data from an authenticated user, it may perform use-after-free and
double-free memory access violations while cleaning up the partial
deserialization results.  Other libgssrpc server applications may also
be vulnerable if they contain insufficiently defensive XDR functions.

CVE-2014-9422: 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.

CVE-2014-9423: libgssrpc applications including kadmind output four or
eight bytes of uninitialized memory to the network as part of an
unused "handle" field in replies to clients.


CVE-2014-5352: An authenticated attacker could cause a vulnerable
application (including kadmind) to crash or to execute arbitrary code.
Exploiting a double-free event to execute arbitrary code is believed
to be difficult.

CVE-2014-9421: An authenticated attacker could cause kadmind or other
vulnerable server application to crash or to execute arbitrary code.
Exploiting a double-free event to execute arbitrary code is believed
to be difficult.

CVE-2014-9422: 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.

CVE-2014-9423: An attacker could attempt to glean sensitive
information from the four or eight bytes of uninitialized data output
by kadmind or other libgssrpc server application.  Because MIT krb5
generally sanitizes memory containing krb5 keys before freeing it, it
is unlikely that kadmind would leak Kerberos key information, but it
is not impossible.


CVE-2014-5352: 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.

CVE-2014-9421: kadmind is vulnerable in all released versions of MIT
krb5.  Third-party server applications using libgssrpc are vulnerable
if they enable the AUTH_GSSAPI authentication flavor and contain
insufficiently defensive XDR functions.

CVE-2014-9422: kadmind is vulnerable in all released versions of MIT

CVE-2014-9423: Server software (including third-party applications)
using libgssrpc from release krb5-1.11 and later are vulnerable.


* Upcoming releases in the krb5-1.11, krb5-1.12, and krb5-1.13 series
  will contain fixes for these issues.

* The patch for krb5-1.13.x is available at


  A PGP-signed patch is available at


* The patch for krb5-1.12.x is available at


  A PGP-signed patch is available at


* The patch for krb5-1.11.x is available at


  A PGP-signed patch is available at



This announcement is posted at:


This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:


The main MIT Kerberos web page is at:






Thanks to Nico Williams for helping with analysis of CVE-2014-5352.


The MIT Kerberos Team security contact address is
<krbcore-security@mit.edu>.  When sending sensitive information,
please PGP-encrypt it using the following key:

pub   3072R/760FCCD9 2015-01-06 [expires: 2016-02-01]
      Key fingerprint = 00D9 5731 89FA AC2D D72E  6319 BD1E A606 760F CCD9
uid     MIT Kerberos Team Security Contact <krbcore-security@mit.edu>


CVE-2014-5352: gss_process_context_token() incorrectly frees context

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

CVE-2014-9421: kadmind doubly frees partial deserialization results

libgssrpc applications use the XDR serialization format.  XDR data is
serialized, deserialized, and freed using an application function,
often generated by the rpcgen command.  If an application receives
incorrectly serialized data from the client, the XDR function will
return false to report a deserialization failure, perhaps leaving
behind partial deserialization results.  To avoid a memory leak, these
partial results must be freed with another invocation of the XDR

In a server application, this cleanup is performed automatically by
svc_getargs().  If the AUTH_GSSAPI authentication flavor is used, the
cleanup is also erroneously performed by the internal unwrap function,
so the XDR function is invoked twice to clean up the partial results.

XDR functions can be defensive about being invoked twice for cleanup
by assigning pointer values to NULL after freeing them.  Most XDR
functions do this, but the XDR functions within libkadm5 for principal
names and tag-length data do not.  When these functions are invoked
twice by libgssrpc to clean up a value, the second invocations perform
use-after-free and double-free memory access violations.  These XDR
functions are only exposed to an authenticated attacker.  This
vulnerability could theoretically lead to the execution of malicious
code, but that is believed to be difficult.

Client applications are not believed to be vulnerable because
clnt_call() and client stub functions do not free partial
deserialization results.

CVE-2014-9422: kadmind incorrectly validates server principal

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.

CVE-2014-9423: libgssrpc servers output uninitialized bytes

RFC 2203 defines structures for the RPCSEC_GSS authentication flavor.
The rpc_gss_init_res structure which conveys responses to the client
contains an opaque "handle" field which is supposed to be used to
identify the GSS-API security context.  The client mirrors this field
back to the server in the "handle" field of rpc_gss_cred_vers_1_t in
subsequent requests.

The MIT krb5 implementation of RPCSEC_GSS does not use the handle to
find the GSS-API context, but it still provides a handle value to the
client.  To provide this value, it copies the first eight or sixteen
bytes out of the GSS-API security context handle.  (The number of
bytes depends on the platform's pointer size; it is eight bytes on a
32-bit platform and sixteen bytes on a 64-bit platform.)

In release krb5-1.11, an unused "interposer" field was added to the
mechglue GSS security context structure as the second pointer field.
Because this field is unused, it remains uninitialized, so the second
half of the bytes copied from the GSS security context handle are

The contents of the uninitialized bytes could contain any heap data
previously freed by the application or any library it uses.  The MIT
Kerberos libraries and kadmind are generally careful to zero out
sensitive data such as Kerberos key data before freeing it, but there
is nevertheless a risk of leakage of a small amount of sensitive data
to the network.


2015-02-03      original release

Copyright (C) 2015 Massachusetts Institute of Technology
Version: GnuPG v1


- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:


Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
Comment: http://www.auscert.org.au/render.html?it=1967