Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:31707
HistoryFeb 11, 2015 - 12:00 a.m.

MITKRB5-SA-2015-001 Vulnerabilities in kadmind, libgssrpc, gss_process_context_token

2015-02-1100:00:00
vulners.com
24

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MITKRB5-SA-2015-001

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
VU#540092

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

CVSSv2 Vector: AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C

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 Vector: AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C
CVSSv2 Base Score: 9.0
CVSSv2 Temporal Score: 7.0

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

CVSSv2 Vector: AV:N/AC:H/Au:S/C:P/I:P/A:C/E:POC/RL:OF/RC:C
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

SUMMARY

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.

IMPACT

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.

AFFECTED SOFTWARE

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
krb5.

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

FIXES

REFERENCES

This announcement is posted at:

http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2015-001.txt

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

    http://web.mit.edu/kerberos/advisories/index.html

The main MIT Kerberos web page is at:

    http://web.mit.edu/kerberos/index.html

CVSSv2:

http://www.first.org/cvss/cvss-guide.html
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

CVE:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5352
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9421
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9422
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9423

ACKNOWLEDGMENTS

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

CONTACT

The MIT Kerberos Team security contact address is
<[email protected]>. 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 <[email protected]>

DETAILS

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
structure.

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
function.

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
uninitialized.

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.

REVISION HISTORY

2015-02-03 original release

Copyright (C) 2015 Massachusetts Institute of Technology
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVNEaFQy6CFdfg3LfAQK72A/+JtpygNYT6rHCncSiWpK9fPu6LCZ0IQdr
GFb+PCo7QRk967yaXdiujYWyUExcVdT8HGoFwHn7u3pYIuNGUrmVrV6H5Q1alV6S
nhMRSgEmF5wRqJ7iuy4KWsuxHLx1+I1t5KWIukdCme9hGWSjMxwHn1s1tkWARWY2
GDdCbfwVvf5W98ohwz0GNxvlR62oERFk8YzfWvTHGUs6kGCnqX1gFUNFZdqlMHvl
x4VuAMpUl7ORAx/SUtxYsufXsZ/n4Zms6T/GkVeUDryp6NEY9ylZk/ZJ2SxzmlK6
9Cg/bNcOxjA33pyvrn/rOr8OM3BWzXfmOYJVi2aHTZKpx7lnvyZkWxArfX1evxlJ
jsbtM1BEXGbxoMPdCLlR3PWI9+EO+X79xUA/WDoQfgCL8wtZr9xJkNiN1TGXjfN1
9Q7dOwurSCJ5eVMynM3vuhGrJB6ivI8xs0HRpbUuM2lScCr6SJOSYlmfEwxwfPMO
l6lw/msWn24s60hX5vw3dEA4lMgR9rNt+otLp8q1UIqe4but/pYXlMCNc3U+Hwwc
qISMllUvC9mty/0SOEqyBZhxdOu+6+snz0dEb8Ti8Ti2Kik7vjlNdb7vj6t2rZBa
ku70qQsRvK8e1zZfPnoF9q5wa42kjqlYjO6N1qDOKIC8oznYwlbG9Zp4gbqai+v9
q5dcHtQeLDk=
=vKP0
-----END PGP SIGNATURE-----

Related for SECURITYVULNS:DOC:31707