[krbdev.mit.edu #5854] freeing non-heap in gss_indicate_mechs() [CVE-2007-5901]

[Tom Yu via RT]

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.