Bug 455858 - bzip2: possible selectorMtf buffer overflow (CESA-2008-005)
bzip2: possible selectorMtf buffer overflow (CESA-2008-005)
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
  Show dependency treegraph
Reported: 2008-07-18 08:35 EDT by Tomas Hoger
Modified: 2008-08-22 04:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-22 04:21:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-07-18 08:35:12 EDT
Chris Evans of the Google Security Team reports on his page a seemingly harmless
buffer overflow affecting bzip2:


Rest is quoting Chris:

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;
            if (j >= nGroups) RETURN(BZ_DATA_ERROR);
         s->selectorMtf[i] = j;

The problem here is that nSelectors could be specified in a malicious archive as
up to 32767, but the selectorMtf array (and the selector array) only take 18002

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;

Those big arrays subsequent to selectorMtf are both big enough to absorb the 14k
or so of buffer overflow in its entirety, and are not referenced between the
time of the overflow and the time of initializing them. In addition, the
placement of "selector" before "selectorMtf" is fortunate because it means
unused selectorMtf values won't get corrupted as the selector values are stored.
Comment 1 Tomas Hoger 2008-08-22 04:21:24 EDT
As noted by Chris, overflow is limited to neighbour buffers and can not reach program control structures.  Closing.

Note You need to log in before you can comment on or make changes to this bug.