[2565] in Kerberos-V5-bugs
krb5-misc/283: Lifetime calculation bug in krb524d
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Thu Dec 5 22:28:20 1996
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: 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
>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: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Dec 05 22:28:02 EST 1996
>Last-Modified:
>Originator: Ken Hornstein
>Organization:
Naval Research Lab
>Release: 1.0-development
>Environment:
System: SunOS nexus 4.1.4 1 sun4m
Architecture: sun4
>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.
>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.
>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) {
>Audit-Trail:
>Unformatted:
