Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Venustech reports of MIT krb5 vulns [CVE-2007-5894 CVE-2007-5901 CVE-2007-5902 CVE-2007-5971 CVE-2007-5972]
From: Tom Yu <tlyu () MIT EDU>
Date: Tue, 11 Dec 2007 19:35:26 -0500

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)


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

  By Date           By Thread  

Current thread:
  • Venustech reports of MIT krb5 vulns [CVE-2007-5894 CVE-2007-5901 CVE-2007-5902 CVE-2007-5971 CVE-2007-5972] Tom Yu (Dec 12)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]