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

This is a discussion on krb5.conf ' # ' in realms section can cause ssh to segv - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

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

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

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


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

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


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

    Troy Benjegerdes 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 (rra@stanford.edu)

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

    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 Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread