CESA-2008-005 - rev 1

[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

bzip2 seemingly harmless buffer overflow

There exists a buffer overflow in decompress.c:

      GET_BITS(BZ_X_SELECTOR_2, nSelectors, 15);
      if (nSelectors < 1) RETURN(BZ_DATA_ERROR);
      for (i = 0; i < nSelectors; i++) {
         j = 0;
         while (True) {
            GET_BIT(BZ_X_SELECTOR_3, uc);
            if (uc == 0) break;
            j++;
            if (j >= nGroups) RETURN(BZ_DATA_ERROR);
         }
         s->selectorMtf[i] = j;
      }

This is probably harmless because the overflowed arrays are part of a struct that looks like this:

      UChar    selector   [BZ_MAX_SELECTORS];
      UChar    selectorMtf[BZ_MAX_SELECTORS];
      UChar    len  [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];

      Int32    limit  [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    base   [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    perm   [BZ_N_GROUPS][BZ_MAX_ALPHA_SIZE];
      Int32    minLens[BZ_N_GROUPS];

      /* save area for scalars in the main decompress code */
      Int32    save_i;
      Int32    save_j;

I haven't done an analysis for 2nd (or higher) order effects. For example, the overflow could lead to out-of-bounds portions of the subsequent arrays, such as "len", not being zero-initialized. If some other part of code requires on zero initialization for safety, there would be issues. It's a totally out-there idea, which is a shame because this would have made a lovely exploitation story.

Credits

• Google - this flaw was discovered in Google's time. I'm with Google's Security Team, and we're always recruiting talented security individuals. Mail me.