Ticket History #465: Bad memset parameters in krb_rd_cred_basic

From davidson@sdremote.hpc-mo.com Wed Aug 27 17:52:35 1997
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA00520 for <bugs@RT-11.MIT.EDU>; Wed, 27 Aug 1997 17:52:34 -0400
Received: from ZEUS.ESY.COM by MIT.EDU with SMTP
id AA06105; Wed, 27 Aug 97 17:52:30 EDT
Received: by firewall.gar.esys.com; id QAA03908; Wed, 27 Aug 1997 16:52:04 -0500
Received: from gar.esys.com(162.36.1.11) by firewall.gar.esys.com via smap (3.2)
id xma003892; Wed, 27 Aug 97 16:51:57 -0500
Received: from sdremote.hpc-mo.com by gar.esys.com (5.x/SMI-SVR4)
id AA20174; Wed, 27 Aug 1997 16:50:59 -0500
Received: by sdremote.hpc-mo.com (950413.SGI.8.6.12/940406.SGI)
id QAA07692; Wed, 27 Aug 1997 16:44:43 -0500
Message-Id: <199708272144.QAA07692@sdremote.hpc-mo.com>
Date: Wed, 27 Aug 1997 16:44:43 -0500
From: davidson@ms.gar.esys.com
Reply-To: davidson@ms.gar.esys.com
To: krb5-bugs@MIT.EDU
Cc: davidson@sdremote.hpc-mo.com
Subject: Bad memset parameters in krb_rd_cred_basic
X-Send-Pr-Version: 3.99

+-----------------------------------------------------------+
| Shannon V. Davidson Voice: (314)475-7596 |
| Raytheon E-Systems E-mail: davidson@ms.gar.esys.com |
+-----------------------------------------------------------+

System: IRIX sdremote 6.2 03131015 IP22



I found a bug in krb_rd_cred_basic(). Line 98 of src/lib/krb5/krb/rd_cred.c is

memset(&encpart, sizeof(encpart), 0);

and should be

memset(&encpart, 0, sizeof(encpart));

A quick search of the code revealed similar problems in src/lib/krb4/decomp_tkt.c, lines 83 and 98 are

memset(keybuf, sizeof(keybuf), 0); /* Clear the buffer */

and should be

memset(keybuf, 0, sizeof(keybuf)); /* Clear the buffer */


I ran into this when forwarding TGTs in some application code that I am
writing. It can cause the decrypt code to abort when trying to free
some structures in the encpart structure.


See above for the fix.



From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: davidson@ms.gar.esys.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/465: Bad memset parameters in krb_rd_cred_basic
Date: Wed, 27 Aug 1997 18:19:23 -0400


While this is definately a bug, I'm kinda surprised it caused any problems,
because this shouldn't modify any memory at all (since the length is zero).

--Ken

From: "Shannon V. Davidson" <davidson@sdremote.hpc-mo.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: davidson@sdremote.hpc-mo.com, krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/465: Bad memset parameters in krb_rd_cred_basic
Date: Thu, 28 Aug 1997 07:17:47 -0500

On Aug 27, 6:19pm, Ken Hornstein wrote:
is

This statement didn't blow up, but later in krb5_free_cred_enc_part there is
some cleanup code which frees some of the structures in encpart and that code
did blow up (while I was testing some new code) when it tried to reference some
invalid pointers in the uninitialized encpart structure.

It may be that existing application code hasn't ran into this problem due to a)
luck - the previous data on the stack occupied by encpart was all zeros or b)
it may only be a problem when the decrypt_credencdata() routine fails and
encpart does not get filled in with valid data.

Shannon

--
+-----------------------------------------------------------+
| Shannon V. Davidson Voice: (314)475-7596 |
| Raytheon E-Systems E-mail: davidson@ms.gar.esys.com |
+-----------------------------------------------------------+

Responsible-Changed-From-To: krb5-unassigned->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Mon Sep 1 21:24:43 1997
Responsible-Changed-Why:

Mine now.

State-Changed-From-To: open-closed
State-Changed-By: tlyu
State-Changed-When: Mon Sep 1 21:38:44 1997
State-Changed-Why:

Fixed.

src/lib/krb5/krb/rd_cred.c 5.32
src/lib/krb4/decomp_tkt.c 1.2


From: Tom Yu <tlyu@MIT.EDU>
To: davidson@ms.gar.esys.com
Cc: krb5-bugs@MIT.EDU, davidson@sdremote.hpc-mo.com
Subject: Re: krb5-libs/465: Bad memset parameters in krb_rd_cred_basic
Date: Mon, 1 Sep 1997 21:34:19 -0400

Thank you for your bug report; I believe your fixes are correct and
that there are no more bugs of a similar nature evident by a grep
through the code. I have applied them to our master sources.

---Tom