Hash: SHA1

This message responds to multiple alleged vulnerabilities in MIT
Kerberos 5 reported by Venustech AD-LAB. The alleged vulnerabilities
have CVE identifiers CVE-2007-5894, CVE-2007-5901, CVE-2007-5902,
CVE-2007-5971, and CVE-2007-5972. For the most part, the bugs are not
exploitable, and the ones which are theoretically exploitable require
extremely unlikely conditions. We plan to fix these bugs in the next
release, and will open tickets for them in our bug database in the
near future.


This is not a vulnerability, and only a stylistic bug. The alleged
vulnerability consists of reading an uninitialized variable, "length",
in the reply() function in src/appl/gssftp/ftpd/ftpd.c.

1878 /* Other auth types go here ... */
1879 if (length >= sizeof(in) / 4 * 3) {
1880 syslog(LOG_ERR, "input to radix_encode too long");
1881 fputs(in, stdout);
1882 } else if ((kerror = radix_encode(out, in, &length, 0))) {
1883 syslog(LOG_ERR, "Couldn't encode reply (%s)",
1884 radix_error(kerror));
1885 fputs(in,stdout);

The "length" variable is only uninitialized if "auth_type" is neither
the "KERBEROS_V4" nor "GSSAPI"; this condition cannot occur in the
unmodified source code. While the remote user can set the string in
"auth_type", this may only occur by way of the auth_data() function,
which will only set "auth_type" if it exactly matches one of the
aforementioned two strings.


This bug is consists of freeing a non-heap pointer, and is not a
practical vulnerability due to the extreme difficulty of exploitation.
In src/lib/gssapi/mechglue/g_initialize.c, the function
gss_indicate_mechs() can make the call free(mechSet), which is
erroneous because "mechSet" is a pointer to type "gss_OID_set" passed
in by the caller of gss_indicate_mechs() and the dereferenced
"*mechSet" is where the pointer to allocated memory is assigned.

201 /* still need to copy each of the oid elements arrays */
202 for (i = 0; i < (*mechSet)->count; i++) {
203 curItem = &((*mechSet)->elements[i]);
204 curItem->elements =
205 (void *) malloc(g_mechSet.elements[i].length);
206 if (curItem->elements == NULL) {
207 (void) k5_mutex_unlock(&g_mechSetLock);
208 /*
209 * must still free the allocated elements for
210 * each allocated gss_OID_desc
211 */
212 for (j = 0; j < i; j++) {
213 free((*mechSet)->elements[j].elements);
214 }
215 free((*mechSet)->elements);
216 free(mechSet);
217 *mechSet = NULL;
218 return (GSS_S_FAILURE);
219 }
220 g_OID_copy(curItem, &g_mechSet.elements[i]);
221 }

If the allocation of (*mechSet)->elements fails, the erroneous call of
free(mechSet) occurs, freeing a pointer which probably points into the
stack frame of the caller. In order to successfully exploit this
vulnerability, an attacker would have to cause a malloc() failure to
occur at precisely the right time: almost immediately after a
different malloc() call has succeeded.


This bug consists of an integer overflow in
svcauth_gss_get_principal() in src/lib/rpc/svc_auth_gss.c, which can
cause an invocation of memcpy() to overflow a zero-length allocated
buffer. This is not a practical vulnerability due to the
nigh-impossibility of producing the conditions required to trigger the

641 svcauth_gss_get_principal(SVCAUTH *auth)
642 {
643 struct svc_rpc_gss_data *gd;
644 char *pname;
646 gd = SVCAUTH_PRIVATE(auth);
648 if (gd->cname.length == 0)
649 return (NULL);
651 if ((pname = malloc(gd->cname.length + 1)) == NULL)
652 return (NULL);
654 memcpy(pname, gd->cname.value, gd->cname.length);
655 pname[gd->cname.length] = '\0';
657 return (pname);
658 }

If "gd->cname.length" is exactly SIZE_MAX, then the call to malloc()
will have an argument of zero due to the modular arithmetic used on
unsigned integer types in C. If malloc(0) returns a non-null pointer
on a specific platform, then the subsequent memcpy() call can attempt
to copy SIZE_MAX bytes and overflow the zero-length buffer.

The value "gd->cname" results from calling krb5_unparse_name() with a
principal obtained during authentication. To successfully exploit
this vulnerability, an attacker would need to successfully
authenticate using a principal name whose unparsed string
representation is exactly SIZE_MAX+1 bytes long. Such a principal
name is very unlikely to exist, and even if such an unusual principal
did exist, the C implementation would have to successfully allocate a
buffer SIZE_MAX+1 bytes long, which almost certainly will not succeed.


This bug is a double-free condition which is not a practical
vulnerability due to the extreme difficulty of exploitation. If
krb5_c_make_checksum() (in src/lib/gssapi/krb5/k5sealv3.c) fails,
"outbuf" may be freed twice.

244 err = krb5_c_make_checksum(context, ctx->cksumtype, key,
245 key_usage, &plain, &sum);
246 zap(plain.data, plain.length);
247 free(plain.data);
248 plain.data = 0;
249 if (err) {
250 zap(outbuf,bufsize);
251 free(outbuf);
252 goto error;
253 }
290 error:
291 free(outbuf);
292 token->value = NULL;
293 token->length = 0;
294 return err;
295 }

krb5_c_make_checksum() only fails if malloc() fails to allocate a very
small amount of memory. To exploit this vulnerability, an attacker
would need to force a malloc() failure at exactly the point where
krb5_c_make_checksum is called.


This bug is a double-free (actually a double-fclose) bug which is not
a vulnerability due to inaccessibility to an attacker. If the
fwrite() call in krb5_def_store_mkey() (in src/lib/kdb/kdb_default.c)
fails, the file pointer "kf" may have fclose() called on it twice.

180 if ((fwrite((krb5_pointer) &enctype,
181 2, 1, kf) != 1) ||
182 (fwrite((krb5_pointer) &key->length,
183 sizeof(key->length), 1, kf) != 1) ||
184 (fwrite((krb5_pointer) key->contents,
185 sizeof(key->contents[0]), (unsigned) key->length,
186 kf) != key->length)) {
187 retval = errno;
188 (void) fclose(kf);
189 }
190 if (fclose(kf) == EOF)
191 retval = errno;

The relevant code stashes a KDC master key. It is only run by
explicit action of a KDC administrator, who already has all the
privileges that exploiting this bug would gain. A properly configured
KDC will have no unprivileged users having shell or other login
access; therefore, an unprivileged user cannot cause the fwrite()
failure necessary for triggering this bug. Also, under normal
conditions, the code is run exactly once in the lifetime of a KDC: at
database creation time.
Version: GnuPG v1.4.6 (SunOS)

iD8DBQFHXyzDSO8fWy4vZo4RArR4AJ9HLOsoUqghl8getTcQdi lk2RZeFgCfeDa3