krb5.conf ' # ' in realms section can cause ssh to segv

[Troy Benjegerdes]

While testing a new kerberos server, I commented out one of my existing
servers with something like the following:

[realms]
EXAMPLE.COM = {
	#kdc = kerberos-1.example.com
	kdc = new-test-server.example.com
	admin_server = kerberos.example.com
}

Unfortunately, I seem to be unable to reproduce the problem exactly
anymore.. When it was failing, I was getting the included backtrace.
What tipped me off to /etc/krb5.conf was that was the last thing I saw
in strace output.

Is this a potential security issue? Granted, if you can edit krb5.conf,
you can do a lot of other stuff.. but a segv is pretty bad behavior.

troy at talia:~$ gdb ssh
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "powerpc-linux"...(no debugging symbols
found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run minbar
Starting program: /usr/bin/ssh minbar
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 23841)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 23841)]
0x0fbe4ce0 in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb) bt
#0  0x0fbe4ce0 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x0faf919c in free () from /lib/libc.so.6
#2  0x0fd87c58 in generic_gss_release_buffer ()
   from /usr/lib/libgssapi_krb5.so.2
#3  0x0fd9631c in gss_release_buffer () from
/usr/lib/libgssapi_krb5.so.2
#4  0x1002a458 in error ()
#5  0x10029960 in error ()
#6  0x1000e230 in ?? ()
#7  0x1000e230 in ?? ()
Previous frame identical to this frame (corrupt stack?)