Bug in Kerberos support for openssh.

[Eric Youngdale]

David Leonard wrote:
>>
>>
>> Here ctx->client is passed in but gss_export_name assumes that the 
>> input name is a krb5_principal.
> gss_export_name() should work with any src_name returned by 
> gss_accept_sec_context()...
>
> Whatversion of the MIT libraries do you have? The error appears to 
> come not from a nametype check, but from a pointer validation:
>        if (! kg_validate_name(input_name)) {
>                if (minor_status)
>                        *minor_status = (OM_uint32) G_VALIDATE_FAILED;
>                krb5_free_context(context);
>                return(GSS_S_CALL_BAD_STRUCTURE|GSS_S_BAD_NAME);
>        }
>
> Is it possible that the ctx->client pointer is getting mangled somehow?
It isn't mangled - the pointer is still valid, but not pointing to the 
same type of object that kg_validate_name is expecting.  All I needed to 
do to hack around the problem was to cast the thing to the real type of 
the object, dereference to get the member which does represent a 
krb5_principal, and then feed that into gss_export_name and life was 
good again.

Using Kerberos 1.4.3 from MIT, and libgssapi-0.7.  I am seeing this with 
Suse-10 - I essentially got the source RPMS fro krb5-devel and 
libgssapi, unpacked and built with debugging so I could step all the way 
in and figure out what the heck this was all about.

The problem could well be in libgssapi instead of ssh - it is inside of 
gss_accept_sec_context that

    status = __gss_convert_name_to_union_name(&temp_minor_status, mech,
                          internal_name,
                          (gss_name_t *) &union_name);

is called - this is what sets up the value returned to ctx->client, and 
sets it up as this union_name thing.  So which one is wrong here?  Is 
the mistake that libgssapi is returning a name from 
gss_accept_sec_context() that isn't a krb5_principal, or is the bug in 
ssh in that it makes assumptions about what ctx->client really is?  I 
think I have ruled out Kerberos proper however - everything on that 
level seems to be working.

I should note that the man pages I found online for 
gss_accept_sec_context() suggest that the value returned to ctx->client 
should be deallocated by passing it to gss_release_name():

http://docs.hp.com/en/B2355-90694/gss_accept_sec_context.3.html

I examined the source to gss_release_name() and it again assumes that 
the opaque type is one which should be cast to a union_name, which 
implies that libgssapi is behaving consistently and that the problem is 
that ssh is assuming that this pointer returned from 
gss_accept_sec_context() into ctx->client is something that can be 
passed to gss_export_name().

What are other people using as a sourcebase for libgssapi??