>Number:         15585
>Category:       bin
>Synopsis:       sshd crashes in Kerberos5 library under given conditions
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 11 15:48:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD-1.5.3_ALPHA from Feb 10 2002
>Organization:
	NORDUnet AS
>Environment:
System: NetBSD server.nordu.net 1.5.3_ALPHA NetBSD 1.5.3_ALPHA (SERVER) #3: Sun Feb 10 15:09:34 MET 2002     he@server.nordu.net:/usr/src/sys/arch/i386/compile/SERVER i386

>Description:
	sshd crashes under given conditions:

	1) server was previously running 1.4.3A, and was configured
	   for using KerberisIV -- /etc/krb.conf exists and worked
	   with previous software.  OS was recently upgraded.
	2) user trying to connect using ssh protocol version 2
	3) user is not in the Kerberos database, but exists as a local
	   user
	4) user has to use password authentication to log in

	Under those conditions, sshd will close the connection after
	accepting the password.  A debug run on the client ends in

debug: next auth method to try is password
he@server.nordu.net's password: 
Connection closed by 193.10.252.19
debug: Calling cleanup 0x8057764(0x0)

	while a debug run of the server ends in

debug1: userauth-request for user he service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for he from 158.38.60.77 port 63222 ssh2
debug1: userauth-request for user he service ssh-connection method password
debug1: attempt 1 failures 1
debug1: temporarily_use_uid: 1612/300 (e=0)
debug1: restore_uid
Segmentation fault

	Compiled sshd with debug info, and got the following
	backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x480a889c in krb5_get_err_text (context=0x0, code=6)
    at /usr/src/lib/libkrb5/../../crypto/dist/heimdal/lib/krb5/context.c:283
283         const char *p = com_right(context->et_list, code);
(gdb) where
#0  0x480a889c in krb5_get_err_text (context=0x0, code=6)
    at /usr/src/lib/libkrb5/../../crypto/dist/heimdal/lib/krb5/context.c:283
#1  0x8058a7d in auth_krb5_password (authctxt=0x808b480, 
    password=0x808b740 "*******")
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/auth-krb5.c:223
#2  0x804ef58 in auth_password (authctxt=0x808b480, 
    password=0x808b740 "*******")
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/auth-passwd.c:70
#3  0x80541f9 in userauth_passwd (authctxt=0x808b480)
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/auth2.c:335
#4  0x8053f52 in input_userauth_request (type=50, plen=73, ctxt=0x808b480)
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/auth2.c:229
#5  0x805d2c7 in dispatch_run (mode=0, done=0x808b480, ctxt=0x808b480)
    at /usr/src/usr.bin/ssh/libssh/../../../crypto/dist/ssh/dispatch.c:72
#6  0x8053c63 in do_authentication2 ()
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/auth2.c:127
#7  0x804e225 in main (ac=4, av=0xbfbfd6b4)
    at /usr/src/usr.bin/ssh/sshd/../../../crypto/dist/ssh/sshd.c:1193
#8  0x804c689 in ___start ()
(gdb) 

	Gee, I guess context is null, and it tried to deref it.

	It turns out that krb5_init() is failing with error code 6 (as
	shown above; /etc/krb5.conf does not exist).

	However, how this all works on my other non-Kerberos-using
	hosts remains a deep mystery to me; even after renaming
	/etc/krb.conf out of the way and removing any DNS remnants
	pointing in the direction of Kerberos-IV, I still get the
	crash on this one system, but not on any of my other
	never-run-Kerberos5 systems.

	For now I've worked around this by setting
	KerberosAuthentication to "no" in /etc/sshd.conf, but
	obviously that's not the desired long-term solution.

	The robustness of this code against what appears to be a pilot
	error could stand some improvement.


>How-To-Repeat:
	See above.

>Fix:
	It would seem that openssh's auth_krb5_password() can't do
	"goto out" and there use krb5_get_err_text() if krb5_init()
	fails, as the Kerberos5 context will then be uninitialized.

	However, the Kerberos5 library could possibly also have some
	improved robustness against these sort of errors (?).
>Release-Note:
>Audit-Trail:
>Unformatted: