Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 75143

Summary: app-crypt/mit-krb5: heap buffer overflow in libkadm5srv
Product: Gentoo Security Reporter: Matthias Geerdsen (RETIRED) <vorlon>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: major CC: aliz, christophe, jaervosz, rphillips
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard: B1 [glsa]
Package list:
Runtime testing required: ---
Description Flags
mit-krb5-1.3.6-ppc64.patch none

Description Matthias Geerdsen (RETIRED) gentoo-dev 2004-12-21 01:00:40 UTC

                 MIT krb5 Security Advisory 2004-004

Original release: 2004-12-20

Topic: heap buffer overflow in libkadm5srv

Severity: serious


The MIT Kerberos 5 administration library (libkadm5srv) contains a
heap buffer overflow in password history handling code which could be
exploited to execute arbitrary code on a Key Distribution Center (KDC)
host.  The overflow occurs during a password change of a principal
with a certain password history state.  An administrator must have
performed a certain password policy change in order to create the
vulnerable state.  (See MITIGATING FACTORS below.)

No exploits are known to exist at this time, though a public
discussion of the bug took place during the first weeks of December
2004, containing sufficient detail that someone could infer how to
perform an attack.  Exploitation of this vulnerability is believed to
be difficult, due to the limited extent of the overflow.


An authenticated user, not necessarily one with administrative
privileges, could execute arbitrary code on the KDC host, compromising
an entire Kerberos realm.  [CAN-2004-1189]


* Typically, only a principal satisfying the following conditions can
  trigger the buffer overflow upon password change:

  + have changed its password fewer times than the history count in
    its password policy

  + had its password policy's history count subsequently reduced to
    equal the number of times it has changed its password

* There are other means of producing the vulnerable state, though they
  are significantly more complex and much less likely.  All of these
  other methods involve a reduction of the password history count in a
  password policy.

* A workaround exists (see FIXES).


* KDC software on all releases of MIT krb5, up to and including
  krb5-1.3.5.  The vulnerable library is libkadm5srv.  Programs which
  use the vulnerable functionality of the library include:

  + kadmind (administration daemon)

  + kadmin.local (KDC-local administration client)

  + kadmind4 (krb4 compatibility administration daemon)


* WORKAROUND: Until your KDC programs and libraries have been patched,
  do not decrease the password history count on any policy in your
  Kerberos realm.  Also, if you have already decreased the password
  history count on a policy at some point in the past, you should
  raise it to the maximum value that it has had in the past.

* The upcoming krb5-1.4 release (currently in beta test) will contain
  fixes for this problem.  The krb5-1.4-beta3 release contains fixes
  for this problem.

* The upcoming krb5-1.3.6 patch release contains fixes for this

* Apply the following patch to src/lib/kadm5/srv/svr_principal.c, and
  recompile the affected libraries and binaries.  This patch was
  generated against krb5-1.3.5, and may apply, with some offset, to
  earlier releases.

  This patch may also be found at:

  The associated detached PGP signature is at:

Index: svr_principal.c
RCS file: /cvs/krbdev/krb5/src/lib/kadm5/srv/svr_principal.c,v
retrieving revision
diff -c -r1.26.2.1 svr_principal.c
*** svr_principal.c	2 Sep 2003 18:58:56 -0000
- --- svr_principal.c	20 Dec 2004 19:47:29 -0000
*** 1017,1022 ****
- --- 1017,1025 ----
+ 	  for (i = adb->old_key_len - 1; i > adb->old_key_next; i--)
+ 	      adb->old_keys[i] = adb->old_keys[i - 1];
+ 	  memset(&adb->old_keys[adb->old_key_next],0,sizeof(osa_pw_hist_ent));
       } else if (adb->old_key_len > pol->pw_history_num-1) {
  	  * The policy must have changed!  Shrink the array.
*** 1039,1048 ****
  		 histp[i] = adb->old_keys[j];
  	     /* Now free the ones we don't keep (the oldest ones) */
! 	     for (i = 0; i < adb->old_key_len - (pol->pw_history_num - 1); i++)
  		 for (j = 0; j < adb->old_keys[KADM_MOD(i)].n_key_data; j++)
  	     free((void *)adb->old_keys);
  	     adb->old_keys = histp;
  	     adb->old_key_len = pol->pw_history_num - 1;
- --- 1042,1053 ----
  		 histp[i] = adb->old_keys[j];
  	     /* Now free the ones we don't keep (the oldest ones) */
! 	     for (i = 0; i < adb->old_key_len - (pol->pw_history_num-1); i++) {
  		 for (j = 0; j < adb->old_keys[KADM_MOD(i)].n_key_data; j++)
+ 		 free(adb->old_keys[KADM_MOD(i)].key_data);
+ 	     }
  	     free((void *)adb->old_keys);
  	     adb->old_keys = histp;
  	     adb->old_key_len = pol->pw_history_num - 1;
*** 1052,1061 ****
- --- 1057,1070 ----
+      if (adb->old_key_next + 1 > adb->old_key_len)
+ 	 adb->old_key_next = 0;
       /* free the old pw history entry if it contains data */
       histp = &adb->old_keys[adb->old_key_next];
       for (i = 0; i < histp->n_key_data; i++)
  	  krb5_free_key_data_contents(context, &histp->key_data[i]);
+      free(histp->key_data);
       /* store the new entry */
       adb->old_keys[adb->old_key_next] = *pw;


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:

CERT VU#948033:

CVE CAN-2004-1189:

        Administration library in MIT Kerberos 5 release krb5-1.3.5
        and earlier has a heap buffer overflow in code which handles
        password history, possibly allowing authenticated attackers to
        execute arbitrary code on a KDC host.


Thanks to Michael Tautschnig for reporting this problem.

Thanks to Chaskiel Grundman and Luke Howard for providing debugging
help on the mailing list.


The vulnerable function is add_to_history() in
src/lib/kadm5/srv/svr_principal.c.  The password history is stored as
a ring buffer, represented as an array of osa_pw_ent_rec, which is
adb->old_keys.  The "next" pointer is an index into the array,
adb->old_key_next, and the length of the array is stored in
adb->old_key_len.  The array is dynamically resized as needed, and
there is no separate head pointer.

The policy's history count is stored in pol->pw_hist_num, but the
actual maximum number of keys stored in adb->old_keys is
pol->pw_hist_num-1, since the "current" key data are also used for
history comparisons when a password change occurs.

The index value adb->old_key_next is permitted to index to a position
one past the end of the array adb->old_keys if adb->old_key_next is
less than pol->pw_hist_num-1.  This out-of-bounds indexing is usually
fixed up when add_to_history() enlarges the array on a subsequent

If pol->pw_hist_num is reduced to adb->old_key_next after a password
change that causes adb->old_key_next to index out of bounds, a
subsequent password change will not run the resizing code, and
add_to_history() will write a password history entry past the end of
the array adb->old_keys.


2004-12-20      original release

Copyright (C) 2004 Massachusetts Institute of Technology
Version: GnuPG v1.2.5 (SunOS)

Comment 1 Matthias Geerdsen (RETIRED) gentoo-dev 2004-12-21 01:02:42 UTC
aliz, rphillips, please provide an updated ebuild with the patches
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2004-12-21 01:58:49 UTC
*** Bug 74449 has been marked as a duplicate of this bug. ***
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2004-12-28 04:54:39 UTC
rphillips/aliz: This is nasty, please patch it asap
Comment 4 Christophe Saout 2004-12-28 11:31:11 UTC
mit-krb5 1.3.6 has been released. This security bug has been fixed. We should *really* upgrade.
Comment 5 Ryan Phillips (RETIRED) gentoo-dev 2004-12-28 22:38:49 UTC
Version 1.3.6 has been commited.  Arches need to test and unmask.

Comment 6 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-12-28 22:47:41 UTC
Thx Ryan.

Arches please test and mark stable.
Comment 7 Markus Rothe (RETIRED) gentoo-dev 2004-12-29 00:27:58 UTC
I get this on ppc64:

--- SNIP ---

checking for socket... yes
checking if DNS Kerberos lookup support should be compiled in... yes
checking for res_search... no
checking for res_search in -lresolv... no
configure: error: Cannot find resolver support routine res_search in -lresolv.

!!! ERROR: app-crypt/mit-krb5-1.3.6 failed.
!!! Function econf, Line 449, Exitcode 1
!!! econf failed

--- SNIP ---

Comment 8 Thierry Carrez (RETIRED) gentoo-dev 2004-12-29 00:43:27 UTC
Markus: can you try the previous stable one (1.3.4-r1) and see if it compiles right ? Just to be sure we're dealing with a regression here, not a missing dep that has always been missing.
Comment 9 Markus Rothe (RETIRED) gentoo-dev 2004-12-29 01:51:58 UTC
1.3.4-r1 compiles and works for me.
Comment 10 Gustavo Zacarias (RETIRED) gentoo-dev 2004-12-29 07:02:18 UTC
sparc stable.
Comment 12 Markus Rothe (RETIRED) gentoo-dev 2004-12-29 12:12:15 UTC
same result... :-(
Comment 13 Hardave Riar (RETIRED) gentoo-dev 2004-12-29 20:48:48 UTC
Stable on mips.
Comment 14 Markus Rothe (RETIRED) gentoo-dev 2004-12-30 00:14:59 UTC
Created attachment 47192 [details, diff]

I'm sorry. I first regenerated the configure scripts and then applied the
patch.. Of cause this has to be the other way around. Now it works. Here is the

This should be tested on other archs, too. If it works, I'll add it arch
independend. otherwise I have to use "use ppc64 && patch ..."
Comment 15 Bryan Ƙstergaard (RETIRED) gentoo-dev 2004-12-30 10:21:49 UTC
Stable on alpha.
Comment 16 Thierry Carrez (RETIRED) gentoo-dev 2004-12-31 01:25:22 UTC
Markus: given that other arches tested without the patch and reported success maybe it's better not to force them to test a new version.

I think the best way to handle this is to submit a 1.3.6-r1 as "~* ppc64" with the patch in "use ppc64 &&"-style and mark it stable on ppc64. Another way of doing it if you feel the patch is useful for everyone is to have it "-* ppc64" with the patch applied to all arches. They will test it in time and unmask -r1 for them if it works, but we can still issue the GLSA as unaffected: >=1.3.6
Comment 17 Markus Rothe (RETIRED) gentoo-dev 2004-12-31 02:10:31 UTC
I've added 1.3.6-r1 and applied the ppc64 using "use ppc64 && .."

Comment 18 Simon Stelling (RETIRED) gentoo-dev 2005-01-01 11:56:05 UTC
amd64 also needs -r1, so i changed the name of the patch and changed use ppc64 && to 64-bit &&. it's stable now on amd64
Comment 19 Sergio Moretto 2005-01-02 02:19:10 UTC
Patch file for 64bit should be called:


as stated in ebuild, but actually is


Comment 20 SpanKY gentoo-dev 2005-01-02 02:32:08 UTC
arm/hppa/ia64/s390 stable

also fixed 64 bit patch name
Comment 21 Lars Weiler (RETIRED) gentoo-dev 2005-01-02 22:41:22 UTC
It compiles on ppc.  But is it normal that ktelnet quits with a segmentation fault?  So, it's not masked stable yet.
Comment 22 Olivier Crete (RETIRED) gentoo-dev 2005-01-03 22:13:35 UTC
sorry for the delay.... x86 stable and happy new year..
Comment 23 Jochen Maes (RETIRED) gentoo-dev 2005-01-05 09:46:10 UTC
stable on ppc
Comment 24 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-01-05 14:05:26 UTC
Thx everyone closing with GLSA 200501-05