Skip Menu |
 

Download (untitled) / with headers
text/plain 2.8KiB
From friebel@mail.cern.ch Fri Aug 9 11:31:46 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id LAA03358
for <bugs@RT-11.mit.edu>; Fri, 9 Aug 2002 11:31:46 -0400 (EDT)
Received: from smtp3.cern.ch (smtp3.cern.ch [137.138.131.164])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA17863
for <krb5-bugs@mit.edu>; Fri, 9 Aug 2002 11:31:45 -0400 (EDT)
Received: from pcitdis18.cern.ch (pcitdis18.cern.ch [137.138.29.212])
by smtp3.cern.ch (8.12.1/8.12.1) with ESMTP id g79FViTC027204
for <krb5-bugs@mit.edu>; Fri, 9 Aug 2002 17:31:44 +0200 (MET DST)
Received: by pcitdis18.cern.ch (Postfix, from userid 325)
id E18541817; Fri, 9 Aug 2002 17:31:43 +0200 (CEST)
Message-Id: <20020809153143.E18541817@pcitdis18.cern.ch>
Date: Fri, 9 Aug 2002 17:31:43 +0200 (CEST)
From: Wolfgang.Friebel@cern.ch
Reply-To: Wolfgang.Friebel@cern.ch
To: krb5-bugs@mit.edu
Subject: string2key gets wrong salt with Heimdal KDC and converted AFS accounts
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 1146
>Category: krb5-clients
>Synopsis: string2key gets wrong salt with Heimdal KDC and converted AFS accounts
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Aug 9 11:32:01 EDT 2002
>Last-Modified:
>Originator: Wolfgang FRIEBEL
>Organization:
CERN
Show quoted text
>Release: krb5-1.2.5
>Environment:
System: Linux pcitdis18 2.4.9-31.1.cern #1 Thu Apr 4 22:42:20 CEST 2002 i686 unknown
Architecture: i686
Client (kinit) running against Heimdal KDC (0.4e) on Solaris

Show quoted text
>Description:
A Kerberos4 database was converted with Heimdal tools to K5 and is running with a Heimdal KDC
Authentication with Heimdal Clients is ok, authentication with MIT clients does not work for
the AFS salted entries. New entries and entries that got new enctypes trough a password change
do work. Debugging showed that in string2key the salt->data string had a '@' character appended.
By removing the trailing character the MIT client works as well.
Show quoted text
>How-To-Repeat:
see description
Show quoted text
>Fix:
The following context diff solved the problem, but this is only a workaround. I do actually not
know whether the bug is in the MIT client code or in the Heimdal server code.

*** krb5-1.2.5/src/lib/crypto/des/string2key.c Fri Sep 24 23:17:09 1999
--- krb5-1.2.5/src/lib/crypto/des/string2key.c.new Fri Aug 9 16:48:39 2002
***************
*** 99,104 ****
--- 99,107 ----
if (salt) {
if (salt->length == -1) {
/* cheat and do AFS string2key instead */
+ char *c;
+ c=strchr(salt->data, '@');
+ if ( c >= 0 ) *c = '\0';
return mit_afs_string_to_key (keyblock, data, salt);
} else
length = data->length + salt->length;

Show quoted text
>Audit-Trail:
>Unformatted:
To: Wolfgang.Friebel@cern.ch
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1146] string2key gets wrong salt with Heimdal KDC and converted AFS accounts
From: Tom Yu <tlyu@mit.edu>
Date: Tue, 10 Sep 2002 15:17:52 -0400
RT-Send-Cc:
Show quoted text
>>>>> "WF" == Wolfgang Friebel <Wolfgang.Friebel@cern.ch> writes:

Show quoted text
>> Number: 1146
>> Category: krb5-clients
>> Synopsis: string2key gets wrong salt with Heimdal KDC and converted AFS accounts
>> Description:

Show quoted text
WF> A Kerberos4 database was converted with Heimdal tools to K5 and is
WF> running with a Heimdal KDC Authentication with Heimdal Clients is
WF> ok, authentication with MIT clients does not work for the AFS
WF> salted entries. New entries and entries that got new enctypes
WF> trough a password change do work. Debugging showed that in
WF> string2key the salt->data string had a '@' character appended. By
WF> removing the trailing character the MIT client works as well.

Thanks for the report and the patch; it will appear in an upcoming
release.

---Tom
Date: Fri, 13 Sep 2002 11:19:46 +0200 (CEST)
From: Wolfgang FRIEBEL <Wolfgang.Friebel@cern.ch>
To: Tom Yu <tlyu@mit.edu>
Subject: Re: [krbdev.mit.edu #1146] string2key gets wrong salt with Heimdal KDC and converted AFS accounts
RT-Send-Cc:
On Tue, 10 Sep 2002, Tom Yu wrote:

Show quoted text
> >>>>> "WF" == Wolfgang Friebel <Wolfgang.Friebel@cern.ch> writes:
>
> >> Number: 1146
> >> Category: krb5-clients
> >> Synopsis: string2key gets wrong salt with Heimdal KDC and converted AFS accounts
> >> Description:
>
> Thanks for the report and the patch; it will appear in an upcoming
> release.

Tom,

there was a typo in the 3 lines to be included. The test on c must of
course not be >= 0 but > 0 only. It would even be better to get the salt
correct in the first place, i.e. at the place where salt->data is set.
Below is the corrected patch:

*** krb5-1.2.5/src/lib/crypto/des/string2key.c Fri Sep 24 23:17:09 1999
--- krb5-1.2.5/src/lib/crypto/des/string2key.c.new Fri Aug 9 16:48:39 2002
***************
*** 99,104 ****
--- 99,107 ----
if (salt) {
if (salt->length == -1) {
/* cheat and do AFS string2key instead */
+ char *c;
+ c=strchr(salt->data, '@');
+ if ( c > 0 ) *c = '\0';
return mit_afs_string_to_key (keyblock, data, salt);
} else
length = data->length + salt->length;
To: Wolfgang.Friebel@cern.ch
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1146] string2key gets wrong salt with Heimdal KDC and converted AFS accounts
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 13 Sep 2002 16:00:06 -0400
RT-Send-Cc:
Show quoted text
>>>>> "WF" == Wolfgang FRIEBEL <Wolfgang.Friebel@cern.ch> writes:

Show quoted text
WF> there was a typo in the 3 lines to be included. The test on c must of
WF> course not be >= 0 but > 0 only. It would even be better to get the salt
WF> correct in the first place, i.e. at the place where salt->data is set.

I corrected the patch when I checked it in for the 1.2.6 release; it
checks that the pointer returned from strchr() is not NULL.

---Tom
Now I'm wondering if Heimdal really sent the extra '@', or if '@' was just
the garbage after the memory buffer on the reporter's platform.

Unfortunately, I don't think there's any good way to know at this point.