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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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@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?)

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Simon Wilkinson
Troy Benjegerdes wrote:
>
> 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.

You've not really provided enough information to track this down. The
stack trace doesn't have any symbols, and you haven't even said which
version of krb5 or ssh you're running. You've also not provided any
debugging dumps from the ssh client which would help show where the
error is occuring.

If you could let me know those things, I can probably trace this a bit
better. My rough guess is that the client's first call into init_context
is failing, due to the bad configuration. It's then trying to release a
buffer that hasn't been allocated, and so is seg faulting.

I don't think this is a security issue - its client side, rather than
server side, the error isn't as a result of bad incoming data, and ssh
doesn't run with elevated priviledge.

If you can provide more information though, and you're running OpenSSH
with my patches, or code derived from them, it would be good to fix this.

Cheers,

Simon.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery
In reply to this post by Troy Benjegerdes
Troy Benjegerdes <[hidden email]> writes:

> 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.

If you linked against the MIT Kerberos v5 libraries, whitespace before
comments will cause Kerberos initialization to fail.  If that wasn't
checked for thoroughly, it could result in trying to use or free a NULL
pointer.  (There's also another problem with MIT K5 right now where it
doesn't completely initialize an output_token buffer in the GSSAPI layer
in some particular circumstances.)

These are #1988 and #3086 in the MIT Kerberos RT.

--
Russ Allbery ([hidden email])             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Troy Benjegerdes
In reply to this post by Simon Wilkinson
On Wed, Jul 13, 2005 at 09:43:41PM +0100, Simon Wilkinson wrote:

> Troy Benjegerdes wrote:
> >
> > 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.
>
> You've not really provided enough information to track this down. The
> stack trace doesn't have any symbols, and you haven't even said which
> version of krb5 or ssh you're running. You've also not provided any
> debugging dumps from the ssh client which would help show where the
> error is occuring.
>
> If you could let me know those things, I can probably trace this a bit
> better. My rough guess is that the client's first call into init_context
> is failing, due to the bad configuration. It's then trying to release a
> buffer that hasn't been allocated, and so is seg faulting.
>
> I don't think this is a security issue - its client side, rather than
> server side, the error isn't as a result of bad incoming data, and ssh
> doesn't run with elevated priviledge.
>
> If you can provide more information though, and you're running OpenSSH
> with my patches, or code derived from them, it would be good to fix this.

Debian-powerpc, running sarge:

ii  libkrb53       1.3.6-3        MIT Kerberos runtime libraries
ii  ssh-krb5       3.8.1p1-8      Secure rlogin/rsh/rcp replacement

I also know the segv occurred immediately after opening /etc/krb5.conf,
but the strace log is gone from my scrollback.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos