Date: Tue, 11 Dec 2007 19:35:26 -0500
From: Tom Yu <tlyu@....EDU>
To: full-disclosure@...ts.grok.org.uk
Subject: Venustech reports of MIT krb5 vulns
	[CVE-2007-5894 CVE-2007-5901 CVE-2007-5902 CVE-2007-5971
	CVE-2007-5972]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (SunOS)

iD8DBQFHXyzQSO8fWy4vZo4RAvN8AKC7FAZwTlVZYDzraJoXHFc8CI3kdACeLH4J
xV9iw49odvlTK4GwMklowaM=
=ap3J
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists