gss_krb5_ccache_name can return pointer to freed memory

[Ezra Peisach]

While playing with valgrind (which is a great utility for Linux to
detect accessing freed memory, memory leaks, etc) and discovered that
kadm5 clients can potentially access freed memory.

The function gss_krb5_ccache_name() (src/lib/gssapi/krb5/set_ccache.c)
is an extension that allows setting the ccache name to use through a
gssapi interface. The function accepts an optional argument, which
if non-NULL, will return a pointer to the return of
krb5_cc_default_name(). 

After retrieving the default ccache name (if required) -
krb5_cc_set_default_name() is called with the new ccache name. 
If the new name does not match the previously cached one in the
krb5_context, the old value is freed. It is this old value that was
returned by the earlier invocation of krb5_cc_default_name().

Therefore gss_krb5_ccache_name will return a pointer that a char * that
has already been freed and could potentially be overwritten.

There are two places in the tree that depend on gss_krb5_ccache_name() -
a) In mac/GSS.more*: GSSAPILibrarySupportsCCacheName (which only
determines if the function is in the library)
b) In lib/kadm5/clnt/client_init.c _kadm5_init_any

It is in (b) that the problem occurs. 

I see several solutions - each with pros and cons:

i) gss_krb5_ccache_name() should allocate memory (i.e. strdup) the old
ccache name and return it. This requires that the caller free the
memory. The downside of this is that this would be a change in API.
Also  - we may theh need a new function for users to call to free the
memory.

ii) gss_krb5_ccache_name() could have a static copy of the cache name.
The value of cc_default_name can be cached and returned. .This requires
no API change but may have implications with eventual thread support...

As we do not know if anything is depending on this function - I do not
know how to proceed... Any opinions?

     Ezra