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.
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.
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.
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.
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.
ping on this issue
Created attachment 123511 [details] Proposed patch Pending testing of patch / unit tests.
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-2006-0197.html