[2777] in Kerberos-V5-bugs
krb5-kdc/464: V4 compat code in KDC does not respect all V5 admin restrictions
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Aug 27 16:58:28 1997
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, kenh@cmf.nrl.navy.mil
Date: Wed, 27 Aug 1997 16:57:24 -0400 (EDT)
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
>Number: 464
>Category: krb5-kdc
>Synopsis: The V4 compat code in the KDC doesn't respect V5 admin restrictions
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Aug 27 16:58:01 EDT 1997
>Last-Modified:
>Originator: Ken Hornstein
>Organization:
Navel Research Lab
>Release: 1.0pl1
>Environment:
System: SunOS nexus 4.1.4 3 sun4m
Architecture: sun4
>Description:
The V5 KDC can also server V4 requests (and in fact, that's the default
when you build it). The V4 compat code in the KDC is taken close to
verbatum from the V4 KDC. However, since there are many new fields in
the V5 database, the V4 compat code hasn't been made aware of them.
The result is that you can have a principal locked out of Kerberos 5,
but still able to get tickets using the V4 compat code.
>How-To-Repeat:
Let a user's password expire or set DISALLOW_ALL_TIX on their flag;
observe they can still get V4 tickets.
>Fix:
This patch seems to fix all of the problems that I could find.
Index: kdc/kerberos_v4.c
===================================================================
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 kerberos_v4.c
--- kerberos_v4.c 1997/06/02 21:54:08 1.1.1.1
+++ kerberos_v4.c 1997/08/27 20:36:54
@@ -420,7 +420,16 @@
*/
v4_time = (entries.max_life + MIN5 - 1) / MIN5;
principal->max_life = v4_time > HR21 ? HR21 : (unsigned char) v4_time;
- principal->exp_date = (unsigned long) entries.expiration;
+
+ /*
+ * This is weird, but the intent is that the expiration is the minimum
+ * of the principal expiration and key expiration
+ */
+ principal->exp_date = (unsigned long)
+ entries.expiration && entries.pw_expiration ?
+ min(entries.expiration, entries.pw_expiration) :
+ (entries.pw_expiration ? entries.pw_expiration :
+ entries.expiration);
/* principal->mod_date = (unsigned long) entries.mod_date; */
/* Set the master key version to 1. It's not really useful because all keys
* will be encrypted in the same master key version, and digging out the
@@ -428,7 +437,12 @@
/* principal->kdc_key_ver = entries.mkvno; */
principal->kdc_key_ver = 1;
principal->key_version = pkey->key_data_kvno;
- principal->attributes = 0;
+ /*
+ * This is slightly bogus, but the current set of flags that we
+ * are interested in _will_ fit into a 16-bit short. The KDC
+ * code doesn't use the attributes flag for anything else, AFAIK.
+ */
+ principal->attributes = entries.attributes & 0xffff;
/* set up v4 format of each date's text: */
for ( date = &principal->exp_date, text = principal->exp_date_txt;
@@ -899,7 +913,32 @@
p->key_high = p->key_low = 0;
hang();
}
-
+
+ /*
+ * Check our V5 stuff first.
+ */
+
+ /*
+ * Does the principal have REQUIRES_PWCHANGE set?
+ */
+
+ if (isflagset(p->attributes, KRB5_KDB_REQUIRES_PWCHANGE)) {
+ lt = klog(L_ERR_SEXP, "V5 REQUIRES_PWCHANGE set "
+ "\"%s\" \"%s\"", p_name, instance);
+ return KERB_ERR_NAME_EXP;
+ }
+
+ /*
+ * Does the principal have DISALLOW_ALL_TIX set?
+ */
+
+ if (isflagset(p->attributes, KRB5_KDB_DISALLOW_ALL_TIX)) {
+ lt = klog(L_ERR_SEXP, "V5 DISALLOW_ALL_TIX set: "
+ "\"%s\" \"%s\"", p_name, instance);
+ /* Not sure of a better error to return */
+ return KERB_ERR_NAME_EXP;
+ }
+
/*
* if more than one p_name, pick one, randomly create a session key,
* compute maximum lifetime, lookup authorizations if applicable,
>Audit-Trail:
>Unformatted:
