Re: Bug in Kerberos support for openssh.

[ cross-posted both to openssh-unix-dev and kerberos@mit.edu as this
question has been asked on both lists ]

The first and most important point to note here is that the problem you're
seeing isn't a bug in OpenSSH - it's a problem with the libraries that
your vendor is shipping, and in particular with the libgssapi package.

On Mon, 27 Feb 2006, Eric Youngdale wrote
> I spent some time in the debugger, and found that essentially the
> problem was that ssh is calling
>
> ctx->major = gss_accept_sec_context(&ctx->minor,
> Later on (not much further later), ssh calls
>
> if ((ctx->major = gss_export_name(&ctx->minor, ctx->client,
>
> Here ctx->client is passed in but gss_export_name assumes that the input
> name is a krb5_principal. Not surprisingly, the datatype mismatch
> causes the call to fail. Could have caused it to crash, I suppose -
> that would have been a much clearer indication of what the trouble was.

GSSAPI is an IETF standard. If your GSSAPI library doesn't allow
gss_export_name to be called with the client name returned by
gss_accept_sec_context then it is broken. The type of the client name
is, as others have noted on the Kerberos mailing list, opaque. An
implementation can chose to make this whatever it likes, as long as that
decision is consistent across every call.

The OpenSSH code has been tested with (to my knowledge) GSSAPI
implementations from MIT, Heimdal and Globus, and works correctly with all
of these.

SuSe 10 ships with a library called 'libgssapi', which isn't a Kerberos
GSSAPI library at all (the Kerberos GSSAPI library from the MIT code is
called libgssapi_krb5.so). It's a version of the 'mechglue' code which, I
believe, CITI have packaged up to work with NFSv4. It acts as a 'shim' layer,
allowing multiple different GSSAPI libraries to be used by the one
application.

Unfortunately this code has issues that are causing problems for a number
of people trying to do GSSAPI on SuSE 10. Firstly, it calls exit() when it
encounters problems - not particular great behaviour from a shared
library. I first encountered this with Thunderbird's Kerberos support -
both Thunderbird and Firefox now explicitly check for this library and
don't use it if found.

Secondly, as you've noted, its support for calling 'export_name' is
broken. In fact, the version of the library that I have to hand doesn't
even support export_name - so I suspect that you're falling back to using
the native export_name provided by libgssapi_krb5, although I'm not
familiar enough with the behaviour of Linux's linker to work out how.

The short answer is - don't build OpenSSH against libgssapi - build it
against the GSSAPI library (libgssapi_krb5) which ships with MIT Kerberos.
File a bug with your vendor about the fact that they're shipping a broken
GSSAPI library.

I'll drop Kevin Coffman at UMICH a mail about this too.

Cheers,

Simon.

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