Bug 166330

Summary: CAN-2005-2491 PCRE heap overflow
Product: Red Hat Enterprise Linux 4 Reporter: Mark J. Cox <mjc>
Component: pcreAssignee: Than Ngo <than>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: tao
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2005-761 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-08 17:18:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 430638    
Attachments:
Description Flags
Upstream patch from 6.1 to 6.2 to correct this issue none

Description Mark J. Cox 2005-08-19 11:35:56 UTC
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.

Comment 1 Mark J. Cox 2005-08-19 11:35:57 UTC
Created attachment 117907 [details]
Upstream patch from 6.1 to 6.2 to correct this issue

Comment 2 Mark J. Cox 2005-08-19 11:37:35 UTC
It's hard to assign a severity level to a library such as PCRE as it will depend
exactly on how applications use it.  Applications that parse untrusted regular
expressions are not particularly likely, therefore setting this to Moderate.



Comment 3 Mark J. Cox 2005-08-19 11:39:45 UTC
[vulnerable doesn't actually mean this has a security context, we need to look
how pcre is used in each case]

pcre 
        (rhel4, rhel3, rhel2.1, fc3, fc4)

exim                     (rhel4, fc3)
        VULNERABLE: confirmed contains pcre in rhel4, seems to 
        use internal version

gnumeric                                (fc3)
        VULNERABLE: contains pcre, and uses it

httpd            (rhel4, rhel3, fc3, fc4)
        SAFE: contains pcre, but uses system pcre

nmap                      (rhel4, fc3, fc4)
        SAFE: contains pcre, uses system pcre in rhel4

privoxy                                 (fc3, fc4)
        VULNERABLE: contains pcre, uses internal pcre

postfix                                 (rhel3, fc3, fc4)
        SAFE: contains pcre, but uses system pcre

php                     (rhel4, rhel3, rhel2.1, fc3, fc4)
        SAFE: contains pcre, but uses system pcre in rhel4, rhel3
        UNKNOWN: uses internal pcre in rhel2.1?

Python       (rhel4, rhel3, rhel2.1, fc3)

        UNKNOWN: Needs investigation


Comment 4 Than Ngo 2005-08-19 13:46:17 UTC
it's now fixed in pcre-3.4-2.1 (RHEL-2.1), pcre-3.9-10.2 (RHEL-3.0E),
pcre-4.5-3.2.RHEL4 (RHEL-4), pcre-4.5-3.1.1.fc3 and pcre-5.0-4.1.fc4

Comment 6 Red Hat Bugzilla 2005-09-08 17:18:23 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.

http://rhn.redhat.com/errata/RHSA-2005-761.html