Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 523506 (CVE-2014-5351) - <app-crypt/mit-krb5-1.13: current keys returned when randomizing the keys for a service principal (CVE-2014-5351)
Summary: <app-crypt/mit-krb5-1.13: current keys returned when randomizing the keys for...
Alias: CVE-2014-5351
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa]
Depends on:
Reported: 2014-09-23 07:48 UTC by Agostino Sarubbo
Modified: 2014-12-31 14:56 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2014-09-23 07:48:42 UTC
From ${URL} :

An authenticated remote attacker can retrieve the current keys for a
service principal when generating a new set of keys for that
principal.  The attacker needs to be authenticated as a user who has
the elevated privilege for randomizing the keys of other principals.

Normally, when a Kerberos administrator randomizes the keys of a
service principal, kadmind returns only the new keys.  This prevents
an administrator who lacks legitimate privileged access to a service
from forging tickets to authenticate to that service.  If the
"keepold" flag to the kadmin randkey RPC operation is true, kadmind
retains the old keys in the KDC database as intended, but also
unexpectedly returns the old keys to the client, which exposes the
service to ticket forgery attacks from the administrator.

A mitigating factor is that legitimate clients of the affected service
will start failing to authenticate to the service once they begin to
receive service tickets encrypted in the new keys.  The affected
service will be unable to decrypt the newly issued tickets, possibly
alerting the legitimate administrator of the affected service.

Upstream patch:


@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 Yury German Gentoo Infrastructure gentoo-dev 2014-10-05 20:15:28 UTC
This is Fixed in version: 1.13 (currently in testing)

@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 2 Eray Aslan gentoo-dev 2014-10-31 15:58:51 UTC
Arches, please test and mark stable =app-crypt/mit-krb5-1.13.  Thank you.

Target Keywords="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Comment 3 Myckel Habets 2014-11-01 11:34:23 UTC
I guess this has to be STABLEREQ, not KEYWORDREQ.
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2014-11-02 14:05:31 UTC
Stable for HPPA.
Comment 5 Markus Meier gentoo-dev 2014-11-08 11:44:30 UTC
arm stable
Comment 6 Agostino Sarubbo gentoo-dev 2014-11-08 18:08:53 UTC
amd64 stable
Comment 7 Agostino Sarubbo gentoo-dev 2014-11-08 18:10:18 UTC
x86 stable
Comment 8 Agostino Sarubbo gentoo-dev 2014-11-10 13:45:33 UTC
ppc stable
Comment 9 Agostino Sarubbo gentoo-dev 2014-11-10 13:52:38 UTC
ppc64 stable
Comment 10 Agostino Sarubbo gentoo-dev 2014-11-11 10:37:36 UTC
ia64 stable
Comment 11 Tobias Klausmann (RETIRED) gentoo-dev 2014-11-20 13:32:10 UTC
Stable on alpha.
Comment 12 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-11-23 19:02:02 UTC
sparc stable

GLSA vote: yes.

@maintainers, please cleanup.
Comment 13 GLSAMaker/CVETool Bot gentoo-dev 2014-11-23 19:05:32 UTC
CVE-2014-5351 (
  The kadm5_randkey_principal_3 function in lib/kadm5/srv/svr_principal.c in
  kadmind in MIT Kerberos 5 (aka krb5) before 1.13 sends old keys in a
  response to a -randkey -keepold request, which allows remote authenticated
  users to forge tickets by leveraging administrative access.
Comment 14 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-12-28 17:26:42 UTC
Added to existing glsa draft
Comment 15 GLSAMaker/CVETool Bot gentoo-dev 2014-12-31 14:56:07 UTC
This issue was resolved and addressed in
 GLSA 201412-53 at
by GLSA coordinator Mikle Kolyada (Zlogene).