Bug 166335 - CVE-2005-2491 PCRE heap overflow
Summary: CVE-2005-2491 PCRE heap overflow
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: python (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
Whiteboard: impact=moderate,public=20050801,sourc...
Keywords: Security
Depends On:
Blocks: CVE-2005-2491
TreeView+ depends on / blocked
Reported: 2005-08-19 11:58 UTC by Mark J. Cox
Modified: 2008-01-29 09:38 UTC (History)
3 users (show)

Fixed In Version: RHSA-2006-0197
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-09 20:39:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (1.43 KB, text/x-patch)
2006-01-20 23:41 UTC, Mihai Ibanescu
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0197 normal SHIPPED_LIVE Moderate: python security update 2006-03-09 05:00:00 UTC

Description Mark J. Cox 2005-08-19 11:58:04 UTC
We need to determine if this issue affects Python; Python does contain it's own
version of pcre, but we didn't confirm if it used it's own version or the system
pcre library across all RHEL releases.

+++ This bug was initially created as a clone of Bug #166330 +++

PCRE 6.2 was released recently which included a fix for a heap buffer overflow.
 PCRE is used by things such as Apache but only for configuration (therefore
making an exploit low severity).  A number of packages also include PCRE code
internally, I'll be adding separate bugs for those that contain PCRE and do not
use system PCRE later.

Changelog states:

1. There was no test for integer overflow of quantifier values. A construction
such as {1111111111111111} would give undefined results. What is worse, if
a minimum quantifier for a parenthesized subpattern overflowed and became
negative, the calculation of the memory size went wrong. This  could have led to
memory overwriting.

A minimal diff of the flaw is attached, the full 6.2 to 6.1 diff contains other
fixes that might be worth incorporating and a test for this flaw.

Although PHP in RHEL3 and RHEL4 definately uses the system pcre library, the one
in RHEL2.1 seemed to use the internal version.  This needs confirming and
determining if there is a security context from this flaw.

Comment 1 Jeremy Katz 2005-08-19 14:55:19 UTC
pcre in python looks to be a massaging of the system pcre and like it's getting
used. And from the patch, it looks like the vulnerability is there.  Unknown as
to the security sensitivity given that you're only getting there from
python-land where things may get otherwise changed.

Comment 2 Josh Bressers 2005-09-14 21:02:05 UTC
I did some digging on this issue today.  It seems the FC4 python does not
contain pcre, but all the rest do.  As best as I can tell, if you execute a
regular expression using the 're' module, it catches the big integers.  I'm not
sure if that's because it's not using pcre, or if it's just smart.  The overflow
is present if you import and use the 'pcre' module directly.

Comment 4 Mihai Ibanescu 2005-09-23 12:59:37 UTC
This is the test I used:

python -c "import pcre; pcre.pcre_compile('a{1111111111111111}',  0, {})"

The result I got on rhel 2.1, rhel3, rhel4 is:

Traceback (innermost last):
  File "<string>", line 1, in ?
pcre.error: ('internal error: code overflow', 19)

Unless my test case is not comprehensive enough, this doesn't necessarily
mandate a fix. Since I don't understand yet how that error gets generated, I
can't tell for sure.

Comment 5 Josh Bressers 2005-09-23 18:16:02 UTC
I spent some time on this, here is why I'm worried (this is all from pypcre.c)

There are two ints in read_repeat_counts(), min and max.  When you feed it a
very large repeat count, you can get them both to overflow multiple times during
the run.  The current logic only verifies they are < 65535 (for example,
4294967295 will render a -1).  From looking at the code, if the int is positive
(after the overflow), it will just cause a broken regexp (it won't do what you
think it will).  I'm having a hard time understanding the impact of a negative
repeat value, but it does scare me a bit as to the undefined nature of it.

Comment 6 Josh Bressers 2005-11-09 20:02:48 UTC
ping on this issue

Comment 7 Mihai Ibanescu 2006-01-20 23:41:42 UTC
Created attachment 123511 [details]
Proposed patch

Pending testing of patch / unit tests.

Comment 11 Red Hat Bugzilla 2006-03-09 20:39:54 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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