Skip Menu |
 

Download (untitled) / with headers
text/plain 16.2KiB
From epeisach@MIT.EDU Fri Aug 29 21:31:50 1997
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 VAA13672 for <bugs@RT-11.MIT.EDU>; Fri, 29 Aug 1997 21:31:50 -0400
Received: from KANGAROO.MIT.EDU by MIT.EDU with SMTP
id AA27508; Fri, 29 Aug 97 21:31:48 EDT
Received: by kangaroo.mit.edu (5.65v3.2/1.1.10.5/23Jun97-0310PM)
id AA27544; Fri, 29 Aug 1997 21:31:47 -0400
Message-Id: <9708300131.AA27544@kangaroo.mit.edu>
Date: Fri, 29 Aug 1997 21:31:47 -0400
From: epeisach@MIT.EDU
Reply-To: epeisach@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: AFS string_to_key bounds problems...
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 467
>Category: krb5-libs
>Synopsis: AFS salt type array overflow problems
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Aug 29 21:32:01 EDT 1997
>Last-Modified: Tue Sep 02 16:24:00 EDT 1997
>Originator: Ezra Peisach
>Organization:
MIT
Show quoted text
>Release: 1.0++
>Environment:
System: OSF1 kangaroo.mit.edu V4.0 464 alpha
Machine: alpha
Show quoted text
>Description:
Discovered using purify with kadmind and adding principals to
the database. Supported_enctypes in kdc.conf include des:afs3.

Ok - here is the code pathway... It is a bit convoluted....

add_key_pwd (kdb_cpw.c): If the salt type is an AFS key, the
realm of the principal is krb5_copy_data into temporary storage
and the length set to -1;

mit_des_string_to_key takes a salt (krb5_data *). If the
length is -1, it then calls mit_afs_string_to_key.

mit_afs_string_to_key assigns the realm to the salt->data portion.
It then wants to use strlen on the field to determine
the length of the realm.

But oops - a krb5_data element does not have to NULL terminated!!

Therefore the strlen walks past the copied data by one. I guess with
my testing there has been a '0' at the end, but there does not have to
be one.

So the question is what to do?

I believe the right thing to do is not use krb5_copy_data, but be
smart and knowing that the lower bowels of afs_mit_string_to_key will
use strlen, copy to the realmsize + 1, 0 terminate and I believe we
win!!

I am willing to entertain other suggestions?

Show quoted text
>How-To-Repeat:
Run purify and add keys to the database.
Show quoted text
>Fix:
About line 395 in kdb_cpw.c:
krb5_data * saltdata;
if (retval = krb5_copy_data(context, krb5_princ_realm(context,
db_entry->princ), &saltdata))
return(retval);

key_salt.data = *saltdata;
key_salt.data.length = -1; /*length actually used below...*/
krb5_xfree(saltdata);

Change the copy_data to malloc(size+1), memcpy, copy, add the
0.... And comment why we do this crap...

If none have a better idea, I will go with this...

Ezra
Show quoted text
>Audit-Trail:

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, epeisach@MIT.EDU
Cc: krb5-unassigned@RT-11.MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Fri, 29 Aug 1997 22:29:55 -0400

Date: Fri, 29 Aug 1997 21:31:47 -0400
From: epeisach@MIT.EDU

mit_afs_string_to_key assigns the realm to the salt->data portion.
It then wants to use strlen on the field to determine
the length of the realm.

I haven't yet had a chance to look at the relevant code yet, but --- is
there a good reason why mit_afs_string_to_key doesn't use salt->length
to determine the lentgh of the realm?

- Ted

From: Ezra Peisach <epeisach@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, epeisach@MIT.EDU, krb5-unassigned@rt-11.MIT.EDU,
gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Fri, 29 Aug 1997 23:04:54 EDT

Show quoted text
>I haven't yet had a chance to look at the relevant code yet, but --- is
>there a good reason why mit_afs_string_to_key doesn't use salt->length
>to determine the lentgh of the realm?

Yeah - it's called abstraction... The salt->length is set to -1 and
krb5_string_to_key "knows" that this means we want an AFS string to
key included in this mess. I suppose an alternate solution would be to set the
length to negative of the required length - but I would have to think of the
"0" case - could we get there, etc....


Ezra


From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU, epeisach@MIT.EDU,
krb5-unassigned@rt-11.MIT.EDU, gnats-admin@rt-11.MIT.EDU,
krb5-prs@rt-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Sat, 30 Aug 1997 00:21:00 -0400

It's called, "we overloaded the length field and we're now paying the
price for it". Blech.

Yeah, I think you're write; malloc'ing length+1 and null-terminating the
realm data is the best way to go.

- Ted

From: Doug Engert <deengert@anl.gov>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Ezra Peisach <epeisach@MIT.EDU>, krb5-bugs@MIT.EDU,
krb5-unassigned@RT-11.MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Sat, 30 Aug 1997 20:22:58 -0500

Theodore Y. Ts'o wrote:
Show quoted text
>
> It's called, "we overloaded the length field and we're now paying the
> price for it". Blech.
>
> Yeah, I think you're write; malloc'ing length+1 and null-terminating the
> realm data is the best way to go.
>
> - Ted

Here is another approach we have been using by proceeding the salt with
AFS:
This works with the DCE security server, since you can store the
salt to use which can include the AFS: followed by the AFS cell name.
Note
that hte AFS cell name does not have to match the K5 realm.

The same aproach might not work with the K5 database.

But in any case note the creation of the null terminated string before
calling the mit_afs_string_to_key to avoid the problem.


Hope this helps.


*** ,string2key.c Tue Apr 9 17:47:24
1996
--- string2key.c Tue Apr 29 17:26:35
1997
***************
*** 78,83
****
--- 78,104
----
key =
keyblock->contents;

if (salt)
{
+ /* ANL Change
*/
+ /* we can store AFS keys in DCE, and set the salt such
that
+ * it is preceeded by
AFS:
+ * If so, pass the rest of the salt to the
afs_string_to_key
+ * But it is cheating, and expecting the salt.data to be
a
+ * null terminated string. This may not be the case from
DCE.
+
*/
+ if ((salt->length >= 4) && !memcmp(salt->data,"AFS:",4))
{
+ krb5_data
afssalt;
+ krb5_error_code
ret;
+ afssalt.length = salt->length -
4;
+ afssalt.data =
(char*)malloc(afssalt.length+1);
+ if
(!afssalt.data)
+
return(ENOMEM);
+ memcpy(afssalt.data,salt->data +
4,afssalt.length);
+ afssalt.data[afssalt.length] = '\0'; /* make it a string
*/
+ ret = mit_afs_string_to_key (eblock, keyblock, data,
&afssalt);
+
free(afssalt.data);
+
return(ret);
+ }
else
+ /* end of ANL change
*/
if (salt->length == -1)
{
/* cheat and do AFS string2key instead
*/
return mit_afs_string_to_key (eblock, keyblock, data,
salt);


--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: deengert@anl.gov
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Ezra Peisach <epeisach@MIT.EDU>,
krb5-bugs@MIT.EDU, krb5-unassigned@RT-11.MIT.EDU,
gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Mon, 01 Sep 1997 01:00:48 -0400

Show quoted text
>Here is another approach we have been using by proceeding the salt with
>AFS:

The thing that bugs me about this patch (other than the line
wrapping, which makes it impossible to feed into patch :-) ) is
that the database already _knows_ that the salt for this key uses
the AFS stringtokey algorithm ... and it's even communicated to
the client without any overloading! (Well, okay, it's told via a
preauth hint ... but that's not even that bad). I just kinda wish
there was a "salt algorithm" argument to krb5_stringtokey() , or
even a new DES-AFS encryption type which had all of the regular
DES function pointers but the right stringtokey algorithm.

I just hate overloading the salt via in-band data, I guess.

--Ken

From: Doug Engert <DEEngert@anl.gov>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: deengert@anl.gov, "Theodore Y. Ts'o" <tytso@MIT.EDU>,
Ezra Peisach <epeisach@MIT.EDU>, krb5-bugs@MIT.EDU,
krb5-unassigned@RT-11.MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Tue, 2 Sep 1997 10:32:56 -0500

Ken Hornstein writes:
Show quoted text
> >Here is another approach we have been using by proceeding the salt with
> >AFS:
>
> The thing that bugs me about this patch (other than the line
> wrapping, which makes it impossible to feed into patch :-) )

That was Netscape Mail sent from home which did me in. Sorry. I have
attached it again.

Show quoted text
> is
> that the database already _knows_ that the salt for this key uses
> the AFS stringtokey algorithm ... and it's even communicated to
> the client without any overloading! (Well, okay, it's told via a
> preauth hint ... but that's not even that bad).
> I just kinda wish
> there was a "salt algorithm" argument to krb5_stringtokey() , or
> even a new DES-AFS encryption type which had all of the regular
> DES function pointers but the right stringtokey algorithm.
>
> I just hate overloading the salt via in-band data, I guess.

Note that the mode I sent was designed to work with the DCE security
server which does not know about AFS string2key, and does not have a
AFS preauth hint. But it does know how to store and sent the salt, and the
modified string2key code on the client in the MIT kinit can figure
out that it should use the AFS string2key.

The main point of sending the mode was that it avoids the null
terminated string problem by making sure there is a null on the end of
the string before calling the AFS string2key routine. This same
trick could be used in other places.

Show quoted text
>
> --Ken

*** ,string2key.c Tue Apr 9 17:47:24 1996
--- string2key.c Tue Apr 29 17:26:35 1997
***************
*** 78,83 ****
--- 78,104 ----
key = keyblock->contents;

if (salt) {
+ /* ANL Change */
+ /* we can store AFS keys in DCE, and set the salt such that
+ * it is preceeded by AFS:
+ * If so, pass the rest of the salt to the afs_string_to_key
+ * But it is cheating, and expecting the salt.data to be a
+ * null terminated string. This may not be the case from DCE.
+ */
+ if ((salt->length >= 4) && !memcmp(salt->data,"AFS:",4)) {
+ krb5_data afssalt;
+ krb5_error_code ret;
+ afssalt.length = salt->length - 4;
+ afssalt.data = (char*)malloc(afssalt.length+1);
+ if (!afssalt.data)
+ return(ENOMEM);
+ memcpy(afssalt.data,salt->data + 4,afssalt.length);
+ afssalt.data[afssalt.length] = '\0'; /* make it a string */
+ ret = mit_afs_string_to_key (eblock, keyblock, data, &afssalt);
+ free(afssalt.data);
+ return(ret);
+ } else
+ /* end of ANL change */
if (salt->length == -1) {
/* cheat and do AFS string2key instead */
return mit_afs_string_to_key (eblock, keyblock, data, salt);

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Doug Engert <DEEngert@anl.gov>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Tue, 02 Sep 1997 15:49:09 -0400

(I trimmmed the cc: line a bit)

Show quoted text
>Note that the mode I sent was designed to work with the DCE security
>server which does not know about AFS string2key, and does not have a
>AFS preauth hint. But it does know how to store and sent the salt, and the
>modified string2key code on the client in the MIT kinit can figure
>out that it should use the AFS string2key.

I'm actually rather surprised at this. DCE/DFS is supposed to be
the upgrade for AFS ... are you saying that there's no way to migrate
the AFS KA database over to DCE?

(If that's true ... ouch!)

--Ken

From: Doug Engert <DEEngert@anl.gov>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: Doug Engert <DEEngert@anl.gov>, krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/467: AFS string_to_key bounds problems...
Date: Tue, 2 Sep 1997 15:18:44 -0500

Ken Hornstein writes:
Show quoted text
> (I trimmmed the cc: line a bit)
>
> >Note that the mode I sent was designed to work with the DCE security
> >server which does not know about AFS string2key, and does not have a
> >AFS preauth hint. But it does know how to store and sent the salt, and the
> >modified string2key code on the client in the MIT kinit can figure
> >out that it should use the AFS string2key.
>
> I'm actually rather surprised at this. DCE/DFS is supposed to be
> the upgrade for AFS ...

Depends on who you talk to. Technical yes it looks like an upgrade,
and DFS is based on AFS code. But AFS is a product of Transarc, while
DFS is licenced by the OpenGroup to many vendors to install. Transarc
has ported DCE and DFS for Solaris,some SYSV system, and NT.
And they will sell any DCE product. But they still sell AFS as a
product, and don't appear to be pushing anyone off of AFS to DFS.

They do have a migration aid, (which I have not looked at in a long
time) which somehow used the DES key from the Kaserver as the
password. A user would have to change it the first time it was used.

Show quoted text
> are you saying that there's no way to migrate
> the AFS KA database over to DCE?

So yes they have a way, but it is real ugly.

My way, is to use the modified MIT string2key, with a MIT kinit
which when the first attempt fails, get the prauth return with a
salt to try, sees that it is AFS:afscellname, which then does the
AFS string to key. This combined with a program to add the key and
salt from the Kaserver to the DCE registry works. I user can change
the DCE password using the v5passwd program with the v5passwdd with a
mod to issue a dcecp command to change the password in the DCE
registry. So the use can change it at thier leasure. Note that the
dce_login does not have the mods to the string2key, so it will fail.
It does require the MIT kinit.

We have only done this in test so far.

Show quoted text
>
> (If that's true ... ouch!)
>
> --Ken

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Show quoted text
>Unformatted:
Subject: AFS salt type array overflow problems
I believe this problem is no longer present after r25837, if it wasn't
already fixed before then.