Re: Bug in Kerberos support for openssh.

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_statu s, 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/gs...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??


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev