[krbdev.mit.edu #1214] create_history_entry() attempts to use NULL key

Wed Oct 9 02:31:31 EDT 2002

>From darrenr at chiron.nabaus.com.au  Wed Oct  9 02:31:28 2002
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by krbdev.mit.edu (8.9.3) with ESMTP
	id CAA21659; Wed, 9 Oct 2002 02:31:27 -0400 (EDT)
From: darrenr at chiron.nabaus.com.au
Received: from orange.national.com.au (orange.national.com.au [203.57.240.81])
	by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA24443
	for <krb5-bugs at mit.edu>; Wed, 9 Oct 2002 02:31:25 -0400 (EDT)
Received: by orange.national.com.au (Postfix, from userid 5)
	id 8F3201449F3; Wed,  9 Oct 2002 16:30:48 +1000 (EST)
Received: from orange(203.57.240.81) by orange.national.com.au via csmap (V4.1)
	id srcAAAARaiDv; Wed, 9 Oct 02 16:30:45 +1000
Received: from chiron.rais.nabaus.com.au (unknown [164.53.57.131])
	by orange.national.com.au (Postfix) with ESMTP
	id 02C10144AE7; Wed,  9 Oct 2002 16:30:29 +1000 (EST)
Received: (from darrenr at localhost)
	by chiron.rais.nabaus.com.au (8.8.8+Sun/8.8.8) id QAA22812;
	Wed, 9 Oct 2002 16:30:25 +1000 (EST)
Date: Wed, 9 Oct 2002 16:30:25 +1000 (EST)
Message-Id: <200210090630.QAA22812 at chiron.rais.nabaus.com.au>
To: krb5-bugs at mit.edu
Priority: first-class
Subject: create_history_entry() attempts to use NULL key?
Reply-To: darrenr at chiron.nabaus.com.au
Cc: darrenr at optimation.com.au
X-send-pr-version: 3.99

>Submitter-Id:	net
>Originator:	Darren Reed
>Organization:	Optimation Software Engineering
>Confidential:	no
>Synopsis:	create_history_entry() attempts to use NULL key
>Severity:	critical
>Priority:	high
>Category:	krb5-libs
>Class:		sw-bug
>Release:	krb5-1.2.5
>Environment:
System: SunOS sun 5.5.1 Generic_103640-34 sun4u sparc SUNW,Ultra-2
Architecture: sun4

>Description:
A daemon application of ours that changes passwords dies with this stack trace:

#0  0xef560618 in _memcpy ()
#1  0x98888 in krb5_old_encrypt (enc=0xaf79c, hash=0xaf7c4, key=0xca510, 
    usage=0, ivec=0x0, input=0xefffe210, output=0xefffe204) at old_encrypt.c:79
#2  0x920cc in krb5_c_encrypt (context=0x100d08, key=0xca510, usage=0, 
    ivec=0x0, input=0xefffe210, output=0xefffe1f8) at encrypt.c:53
#3  0x3b864 in krb5_dbekd_encrypt_key_data (context=0x100d08, mkey=0xca510, 
    dbkey=0xefffe2c8, keysalt=0xefffe2b8, keyver=0, key_data=0x1026dc)
    at encrypt_key.c:112
#4  0x27a68 in create_history_entry (context=0x100d08, n_key_data=2, 
    key_data=0x102698, hist=0xefffe360) at svr_principal.c:1012
#5  0x2849c in kadm5_chpass_principal_3 (server_handle=0x100c88, 
    principal=0xcdf48, keepold=0, n_ks_tuple=0, ks_tuple=0x0, 
    password=0xefffea38 "0639192") at svr_principal.c:1214
#6  0x28024 in kadm5_chpass_principal (server_handle=0x100c88, 
    principal=0xcdf48, password=0xefffea38 "0639192") at svr_principal.c:1144
#7  0x1e1f0 in update_kerberos_password (pcUser=0xefffef10 "NPTST01", 
    pcPass=0xefffea38 "0639192") at changepass-mit.c:51
...

Walking up, we see that input->data is NULL in krb5_old_encrypt().
Further up, in create_history_entry(), we find we are in the second
loop (i == 1).  The key_data structure gives a hint to what has gone
awry here:
(gdb) p key_data[0]
$2 = {key_data_ver = 2, key_data_kvno = 0, key_data_type = {1, 1}, 
  key_data_length = {26, 0}, key_data_contents = {0x104b48 "\b", 0x0}}
(gdb) p key_data[1]
$3 = {key_data_ver = 2, key_data_kvno = 0, key_data_type = {0, 1}, 
  key_data_length = {0, 0}, key_data_contents = {0x0, 0x0}}

An attempt to fix this was to make the for() loop in create_history_entry()
only apply to key_data[] where key_data_length > 0.  However, this resulted
in a core dump like this:

(gdb) where
#0  0xef560618 in ?? ()
#1  0x920cc in ?? ()
#2  0x3b868 in object.7 ()
#3  0x27a68 in _lib_version ()
#4  0x2849c in ?? ()
#5  0x28024 in ?? ()
#6  0x1e1f0 in __kdb2_big_return (hashp=0xefffef10, item_info=0xefffea38, 
    val=0xefffea38, on_bigkey_page=820060) at ../hash/hash_bigkey.c:331
#7  0x1cf1c in __kdb2_hash_open (file=0xefffef10 "NPTST01", flags=-268440792, 
    mode=32, info=0xef61bd50, dflags=840968) at ../hash/hash.c:207
#8  0x1c24c in __kdb2_rec_put (dbp=0x4, key=0xeffff374, data=0xeffff388, 
    flags=816360) at ../recno/rec_put.c:91

This application was linked with libraries as follows:
-L/krb5/lib -lkadm5srv -lkdb5 -ldb -lcom_err -lkrb5 -lk5crypto -lgssapi_krb5 -lgssrpc -ldyn -lresolv -R/krb5/lib

The Kerberos configuration has been setup to allow DES and 3DES,
with the KDC set to use both.  All of the user information has been
imported from a 'beta5' database (load -old) where only single DES
key information was available.
>How-To-Repeat:

>Fix: