Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 564304 (CVE-2015-2695) - <app-crypt/mit-krb5-1.13.2-r2: multiple vulnerabilities (CVE-2015-{2695,2696,2697})
Summary: <app-crypt/mit-krb5-1.13.2-r2: multiple vulnerabilities (CVE-2015-{2695,2696,...
Status: RESOLVED FIXED
Alias: CVE-2015-2695
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [glsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-28 08:22 UTC by Agostino Sarubbo
Modified: 2016-11-20 22:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-10-28 08:22:22 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=1275871:

The SPNEGO mechanism currently replaces its context handle with the
mechanism context handle upon establishment, under the assumption that
most GSS functions are only called after context establishment.  This
assumption is incorrect, and can lead to aliasing violations for some
programs.  Maintain the SPNEGO context structure after context
establishment and refer to it in all GSS methods.  Add initiate and
opened flags to the SPNEGO context structure for use in
gss_inquire_context() prior to context establishment.

CVE-2015-2695:

In MIT krb5 1.5 and later, applications which call
gss_inquire_context() on a partially-established SPNEGO context can
cause the GSS-API library to read from a pointer using the wrong type,
generally causing a process crash.  This bug may go unnoticed, because
the most common SPNEGO authentication scenario establishes the context
after just one call to gss_accept_sec_context().  Java server
applications using the native JGSS provider are vulnerable to this
bug.  A carefully crafted SPNEGO packet might allow the
gss_inquire_context() call to succeed with attacker-determined
results, but applications should not make access control decisions
based on gss_inquire_context() results prior to context establishment.

External References:
https://github.com/krb5/krb5/commit/b51b33f2bc5d1497ddf5bd107f791c101695000d


From https://bugzilla.redhat.com/show_bug.cgi?id=1275869:

The IAKERB mechanism currently replaces its context handle with the
krb5 mechanism handle upon establishment, under the assumption that
most GSS functions are only called after context establishment.  This
assumption is incorrect, and can lead to aliasing violations for some
programs.  Maintain the IAKERB context structure after context
establishment and add new IAKERB entry points to refer to it with that
type.  Add initiate and established flags to the IAKERB context
structure for use in gss_inquire_context() prior to context
establishment.

CVE-2015-2696:

In MIT krb5 1.9 and later, applications which call
gss_inquire_context() on a partially-established IAKERB context can
cause the GSS-API library to read from a pointer using the wrong type,
generally causing a process crash.  Java server applications using the
native JGSS provider are vulnerable to this bug.  A carefully crafted
IAKERB packet might allow the gss_inquire_context() call to succeed
with attacker-determined results, but applications should not make
access control decisions based on gss_inquire_context() results prior
to context establishment.

External references:
https://github.com/krb5/krb5/commit/e04f0283516e80d2f93366e0d479d13c9b5c8c2a


From https://bugzilla.redhat.com/show_bug.cgi?id=1275863:

In build_principal_va(), use k5memdup0() instead of strdup() to make a
copy of the realm, to ensure that we allocate the correct number of
bytes and do not read past the end of the input string.  This bug
affects krb5_build_principal(), krb5_build_principal_va(), and
krb5_build_principal_alloc_va().  krb5_build_principal_ext() is not
affected.

CVE-2015-2697:

In MIT krb5 1.7 and later, an authenticated attacker may be able to
cause a KDC to crash using a TGS request with a large realm field
beginning with a null byte.  If the KDC attempts to find a referral to
answer the request, it constructs a principal name for lookup using
krb5_build_principal() with the requested realm.  Due to a bug in this
function, the null byte causes only one byte be allocated for the
realm field of the constructed principal, far less than its length.
Subsequent operations on the lookup principal may cause a read beyond
the end of the mapped memory region, causing the KDC process to crash.

External reference:
https://github.com/krb5/krb5/commit/f0c094a1b745d91ef2f9a4eae2149aac026a5789


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Eray Aslan gentoo-dev 2015-10-29 04:45:50 UTC
Arches, please test and mark stable
=app-crypt/mit-krb5-1.13.2-r2
Target Keywords = alpha amd64 arm ~arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86
Comment 2 Jeroen Roovers gentoo-dev 2015-10-29 06:50:34 UTC
Stable for PPC64.
Comment 3 Jeroen Roovers gentoo-dev 2015-10-29 07:05:44 UTC
Stable for HPPA.
Comment 4 Agostino Sarubbo gentoo-dev 2015-10-29 11:43:14 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2015-10-29 11:43:38 UTC
x86 stable
Comment 6 Tobias Klausmann gentoo-dev 2015-11-01 14:43:39 UTC
Stable on alpha.
Comment 7 Markus Meier gentoo-dev 2015-11-03 19:20:52 UTC
arm stable
Comment 8 Agostino Sarubbo gentoo-dev 2015-11-04 14:28:14 UTC
ppc stable
Comment 9 Agostino Sarubbo gentoo-dev 2015-11-05 10:59:49 UTC
sparc stable
Comment 10 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2015-11-07 23:24:34 UTC
ia64 stable
Comment 11 Yury German Gentoo Infrastructure gentoo-dev Security 2015-12-23 22:59:29 UTC
Arches and Maintainer(s), Thank you for your work.

GLSA Vote: Yes

New GLSA Request filed.
Comment 12 GLSAMaker/CVETool Bot gentoo-dev 2016-11-20 22:13:23 UTC
This issue was resolved and addressed in
 GLSA 201611-14 at https://security.gentoo.org/glsa/201611-14
by GLSA coordinator Aaron Bauman (b-man).