severity 454974 normal
tags 454974 -security
retitle 454974 krb5: Venustech AD-LAB CVEs (not serious)
thanks
Here's the information about the CVEs reported against MIT Kerberos. The
summary is that this isn't significant enough to warrant an advisory or a
stable update, although we'll fix the bugs in a later release.
To: [EMAIL PROTECTED]
Subject: Venustech reports of MIT krb5 vulns [CVE-2007-5894 CVE-2007-5901
CVE-2007-5902 CVE-2007-5971 CVE-2007-5972]
From: Tom Yu <[EMAIL PROTECTED]>
Date: Tue, 11 Dec 2007 19:35:12 -0500
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.
CVE-2007-5894
http://bugs.gentoo.org/show_bug.cgi?id=199205
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.
CVE-2007-5901
http://bugs.gentoo.org/show_bug.cgi?id=199214
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.
CVE-2007-5902
http://bugs.gentoo.org/show_bug.cgi?id=199214
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
bug.
641 svcauth_gss_get_principal(SVCAUTH *auth)
642 {
643 struct svc_rpc_gss_data *gd;
644 char *pname;
645
646 gd = SVCAUTH_PRIVATE(auth);
647
648 if (gd->cname.length == 0)
649 return (NULL);
650
651 if ((pname = malloc(gd->cname.length + 1)) == NULL)
652 return (NULL);
653
654 memcpy(pname, gd->cname.value, gd->cname.length);
655 pname[gd->cname.length] = '\0';
656
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.
CVE-2007-5971
http://bugs.gentoo.org/show_bug.cgi?id=199212
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.
CVE-2007-5972
http://bugs.gentoo.org/show_bug.cgi?id=199211
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.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
