From craziboy77@hotmail.com Tue Dec 5 08:54:32 2000 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id IAA07016 for ; Tue, 5 Dec 2000 08:54:31 -0500 (EST) Received: from hotmail.com (f164.law11.hotmail.com [64.4.17.164]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA06498 for ; Tue, 5 Dec 2000 08:54:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Dec 2000 05:54:00 -0800 Received: from 202.165.0.37 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 05 Dec 2000 13:54:00 GMT Message-Id: Date: Tue, 05 Dec 2000 13:54:00 -0000 From: "Crazy Boy" To: krb5-bugs@mit.edu Subject: NULL deref from empty returned ETYPE_INFO >Number: 903 >Category: krb5-libs >Synopsis: NULL deref from empty returned ETYPE_INFO >Confidential: no >Severity: serious >Priority: medium >Responsible: tlyu >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Tue Dec 5 08:55:01 EST 2000 >Last-Modified: Fri Sep 14 19:52:30 EDT 2001 >Originator: Crazy Boy >Organization: >Release: krb5-1.2.1 >Environment: System: SunOS buildhost 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-5_10 Architecture: sun4 >Description: A Windows 2000 KDC will in some circumstances return an empty list of supported authentication types (a KRB5_PADATA_ETYPE_INFO message with no data(?)). When this is processed to select the first supported encryption type, there is no check that any types are actually supported; the first one is selected (blindly), causing a null pointer deference when the list returned is empty (in preauth2.c, line 533). The desired outcome in this situation is to return the "no supported encryption types" message to the user rather than crashing :). This bug also exists in krb5-1.0.5 code (I have checked this) and so I assume also in 1.1. >How-To-Repeat: Install a Windows 2000 Server, being careful to not change the Administrator password. Promote it to be a domain controller. I believe this is when the kerberos database is created. At this point, there are no kerberos principals on the Win2K machine, and trying to kinit Administrator@WIN2K.KERBEROS.REALM causes a seg fault as described. Alternatively, if you already have a W2K KDC running, add new user into Active Directory via LDAP queries, but do not set a password for the user. Try to kinit newuser@WIN2K.KERBEROS.REALM, and you will see the same behaviour. >Fix: Apply the following patch which makes the preauthentication code treat an empty received supported encryption type list as if no one had been received at all. This patch fixes the bug encountered when talking to Win2000 in preauth2.c, and also a similar problem in preauth.c. --8<-- diff -r -u krb5-1.2.1.orig/src/lib/krb5/krb/preauth.c krb5-1.2.1.w2k/src/lib/krb5/krb/preauth.c --- krb5-1.2.1.orig/src/lib/krb5/krb/preauth.c Fri Jun 30 12:28:13 2000 +++ krb5-1.2.1.w2k/src/lib/krb5/krb/preauth.c Tue Dec 5 22:37:59 2000 @@ -172,6 +172,10 @@ retval = decode_krb5_etype_info(&scratch, &etype_info); if (retval) return retval; + if (etype_info[0] == NULL) { + krb5_free_etype_info(context, etype_info); + etype_info = 0; + } } } diff -r -u krb5-1.2.1.orig/src/lib/krb5/krb/preauth2.c krb5-1.2.1.w2k/src/lib/krb5/krb/preauth2.c --- krb5-1.2.1.orig/src/lib/krb5/krb/preauth2.c Fri Jun 30 12:28:13 2000 +++ krb5-1.2.1.w2k/src/lib/krb5/krb/preauth2.c Tue Dec 5 22:44:56 2000 @@ -530,6 +530,11 @@ } return ret; } + if (etype_info[0] == NULL) { + krb5_free_etype_info(context, etype_info); + etype_info = NULL; + break; + } salt->data = (char *) etype_info[0]->salt; salt->length = etype_info[0]->length; *etype = etype_info[0]->etype; >Audit-Trail: Responsible-Changed-From-To: gnats-admin->tlyu Responsible-Changed-By: tlyu Responsible-Changed-When: Tue Jan 30 16:47:45 2001 Responsible-Changed-Why: refiled, reformatted State-Changed-From-To: open-feedback State-Changed-By: tlyu State-Changed-When: Tue Jan 30 18:31:31 2001 State-Changed-Why: patch committed From: Tom Yu To: craziboy77@hotmail.com Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-libs/903: NULL deref from empty returned ETYPE_INFO Date: Tue, 30 Jan 2001 18:33:19 -0500 (EST) >>>>> "craziboy77" == Crazy Boy writes: craziboy77> A Windows 2000 KDC will in some circumstances return craziboy77> an empty list of supported authentication types (a craziboy77> KRB5_PADATA_ETYPE_INFO message with no data(?)). When craziboy77> this is processed to select the first supported craziboy77> encryption type, there is no check that any types are craziboy77> actually supported; the first one is selected craziboy77> (blindly), causing a null pointer deference when the craziboy77> list returned is empty (in preauth2.c, line 533). The craziboy77> desired outcome in this situation is to return the "no craziboy77> supported encryption types" message to the user rather craziboy77> than crashing :). Thanks for the bug report; I've committed a patch, and it should be in the upcoming release. ---Tom State-Changed-From-To: feedback-closed State-Changed-By: tlyu State-Changed-When: Fri Sep 14 19:52:18 2001 State-Changed-Why: Fixed in 1.2.2. >Unformatted: