Bug 383371 (CVE-2006-7228) - CVE-2006-7228 pcre integer overflow
Summary: CVE-2006-7228 pcre integer overflow
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2006-7228
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 380511 380521 380531 380541 381991 382081 392031 392041 392051 392061 411731 413871 414271 430870 445917
Blocks: CVE-2006-7224
TreeView+ depends on / blocked
 
Reported: 2007-11-14 20:53 UTC by Josh Bressers
Modified: 2019-09-29 12:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-11 17:33:45 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:1059 normal SHIPPED_LIVE Important: pcre security update 2007-11-29 14:51:01 UTC
Red Hat Product Errata RHSA-2007:1063 normal SHIPPED_LIVE Important: pcre security update 2007-11-29 14:56:28 UTC
Red Hat Product Errata RHSA-2007:1065 normal SHIPPED_LIVE Moderate: pcre security update 2007-11-29 14:58:42 UTC
Red Hat Product Errata RHSA-2007:1068 normal SHIPPED_LIVE Important: pcre security update 2007-11-29 15:09:39 UTC
Red Hat Product Errata RHSA-2007:1076 normal SHIPPED_LIVE Moderate: python security update 2007-12-10 18:41:24 UTC
Red Hat Product Errata RHSA-2007:1077 normal SHIPPED_LIVE Moderate: python security update 2007-12-10 17:57:16 UTC
Red Hat Product Errata RHSA-2008:0546 normal SHIPPED_LIVE Moderate: php security update 2008-07-16 09:59:22 UTC

Description Josh Bressers 2007-11-14 20:53:56 UTC
CVE-2006-7224 initially described several integer overflows in pcre, all
described here:
http://scary.beasts.org/security/CESA-2007-006.html

This id should be used to describe issue #2         
in that advisory:

3) More possible integer overflow trouble.

pcre_compile:
---
    if (min == 0)
      {
      length++;
      if (max > 0) length += (max - 1) * (duplength + 3 + 2*LINK_SIZE);
      }
...
    else
      {
      length += (min - 1) * duplength;
      if (max > min)   /* Need this test as max=-1 means no limit */
        length += (max - min) * (duplength + 3 + 2*LINK_SIZE)
          - (2 + 2*LINK_SIZE);
      }
---

In both these cases, I see no reason why a malicious regexp pattern couldn't
cause an integer overflow by using large min / max / duplength values. This will
really mess up the critical "length" value.

Comment 2 Tomas Hoger 2007-11-15 10:58:34 UTC
Reference in PCRE changelog for version 6.7:

11. Subpatterns that are repeated with specific counts have to be replicated in
    the compiled pattern. The size of memory for this was computed from the
    length of the subpattern and the repeat count. The latter is limited to
    65535, but there was no limit on the former, meaning that integer overflow
    could in principle occur. The compiled length of a repeated subpattern is
    now limited to 30,000 bytes in order to prevent this.

Comment 11 James Antill 2007-11-20 15:37:52 UTC
 Looking at the RHEL-4 included pcre, the only thing I can see referencing
duplength is:

      if (minval == 0) length++;
        else if (minval > 1) length += (minval - 1) * duplength;
      if (maxval > minval) length += (maxval - minval) * (duplength + 1);

...which does look like a bug, but the code is different (the code is basically
the same for RHEL-2.1 and RHEL-3).
 It looks like that's the "only"[1] thing I need to fix, is that so?

 [1] I've also added the code to get out the loop and fail if any of the adds in
the loop cross the 65535 barrier or go negative.


Comment 12 James Antill 2007-11-20 15:38:34 UTC
My comment is in reference to python's pypcre (for anyone being confused about
now :).


Comment 13 Tomas Hoger 2007-11-21 09:28:48 UTC
Re comment 11:

James, I'm not quite sure I understand your question, hope I do... ;)

Yes, the code snippet is the place where the problem occurs.  I've checked your
patch.  Unlike upstream pcre, it does not add arbitrary hard-coded limit
(duplength <= 30000), but looks good to me.



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