To: krb5-bugs@MIT.EDU
Subject: freeing non-heap in gss_indicate_mechs() [CVE-2007-5901]
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 12 Dec 2007 13:39:31 -0500
Message-ID: <ldvabofsqos.fsf@cathode-dark-space.mit.edu>
Lines: 41
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list
Sender: krb5-bugs-incoming-bounces@PCH.MIT.EDU
Errors-To: krb5-bugs-incoming-bounces@PCH.MIT.EDU
Content-Length: 2109

This is one of the Venustech AD-LAB alleged vulnerabilities.

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.