Skip Menu |
 

Download (untitled) / with headers
text/plain 5.2KiB
From kenh@cmf.nrl.navy.mil Thu Dec 5 22:27:17 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id WAA11216 for <bugs@RT-11.MIT.EDU>; Thu, 5 Dec 1996 22:27:17 -0500
Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP
id AA15013; Thu, 5 Dec 96 22:27:16 EST
Received: from nexus.cmf.nrl.navy.mil (kenh@nexus.cmf.nrl.navy.mil [134.207.10.9]) by ginger.cmf.nrl.navy.mil (8.7.5/8.7.3) with ESMTP id WAA20028 for <krb5-bugs@mit.edu>; Thu, 5 Dec 1996 22:27:16 -0500 (EST)
Received: (kenh@localhost) by nexus.cmf.nrl.navy.mil (8.7.5/8.6.11) id WAA16170; Thu, 5 Dec 1996 22:27:13 -0500 (EST)
Message-Id: <199612060327.WAA16170@nexus.cmf.nrl.navy.mil>
Date: Thu, 5 Dec 1996 22:27:13 -0500 (EST)
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Subject: Lifetime calculation bug in krb524d
X-Send-Pr-Version: 3.2

Show quoted text
>Number: 283
>Category: krb5-misc
>Synopsis: The krb524d can get the lifetime of a V4 ticket wrong
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: krb5-unassigned
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Dec 05 22:28:02 EST 1996
>Last-Modified: Fri Dec 06 14:19:01 EST 1996
>Originator: Ken Hornstein
>Organization:
Naval Research Lab
Show quoted text
>Release: 1.0-development
>Environment:

System: SunOS nexus 4.1.4 1 sun4m
Architecture: sun4

Show quoted text
>Description:

There is a subtle, but nasty bug in the V4 lifetime calculation code in
the 524 ticket converter daemon.

The lifetime that is calculated in the V4 ticket uses a difference between
the current time and the end time as the delta. This is obviously done
so the V4 ticket will last as long as possible (since a V5 lifetime has
the potential for being much longer that will fit into a V4 ticket).

However, the _start_ time of the V4 ticket is the same as the V5 ticket.
This does not present a problem when the start time is the same as the
current time. However, this fails when the current time is much greater
than the ticket start time. For example:

V5 ticket lasts for 10 hours.
5 hours elapse.
You convert it to a V4 ticket (example - you run aklog again becase
you were added to a new PTS group).
The lifetime calculated is 5 hours (since there is 5 hours between the
expiration time and the start time).
However, since 5 hours have already elapsed between the start time and
the current time, the V4 ticket you get back has already expired.

Show quoted text
>How-To-Repeat:

Get a V5 AFS ticket, wait a while, try to convert it to a V4 ticket, and
watch the lifetime be wrong.
Show quoted text
>Fix:

There are two potential fixes:

- Calculate the lifetime based on the difference between the start time and
end time.
- Use the current time as the ticket start time.

The attached patch takes the former approach, but I suspect that the latter
approach might be more useful.

--- krb524/cnv_tkt_skey.c.orig Thu Sep 12 14:31:11 1996
+++ krb524/cnv_tkt_skey.c Thu Sep 12 14:35:42 1996
@@ -111,7 +111,7 @@
}
if ( (server_time+context->clockskew >= v5etkt->times.starttime)
&& (server_time-context->clockskew <= v5etkt->times.endtime)) {
- deltatime = v5etkt->times.endtime - (server_time-context->clockskew);
+ deltatime = v5etkt->times.endtime - v5etkt->times.starttime;
lifetime = deltatime / 300;
/* if (lifetime > 255) lifetime = 255; */
if (lifetime > 127) {
Show quoted text
>Audit-Trail:

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Thu Dec 5 23:15:27 1996
State-Changed-Why: bug fixed


From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: kenh@cmf.nrl.navy.mil
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-misc/283: The krb524d can get the lifetime of a V4 ticket wrong
Date: Thu, 5 Dec 1996 23:18:18 -0500

Since we need to unthaw the release, and this is a particularily serious
krb524 bug, I've fixed your reported bug by applying the following
one-line fix.

As Marc Horowitz pointed out, fixing the start time is better than
fixing the lifetime calculation, because if you have a very long-lived
krb5 ticket (longer than what krb4 supports), you are much more likely
to have a useful V4 ticket if you adjust the start time.

--- cnv_tkt_skey.c 1996/04/09 22:46:22 1.10
+++ cnv_tkt_skey.c 1996/12/06 04:12:07
@@ -161,7 +161,7 @@
(char *) v5etkt->session->contents,
lifetime,
/* issue_data */
- v5etkt->times.starttime,
+ server_time,
sname,
sinst,
v4_skey->contents);

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-misc/283: The krb524d can get the lifetime of a V4 ticket wrong
Date: Fri, 06 Dec 1996 14:18:25 -0500

Show quoted text
>Since we need to unthaw the release, and this is a particularily serious
>krb524 bug, I've fixed your reported bug by applying the following
>one-line fix.

Great! Sorry I didn't send it in until now, but I reported this a number of
months ago, and I thought it was fixed in the current release, until I saw
the sources (I reported it before GNATS was installed).

--Ken
Show quoted text
>Unformatted: