Red Hat Bugzilla – Bug 168318
CAN-2005-2491 - python PCRE heap overflow
Last modified: 2008-01-29 04:38:57 EST
+++ This bug was initially created as a clone of Bug #166335 +++ 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. -- Additional comment from katzj@redhat.com on 2005-08-19 10:55 EST -- 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. -- Additional comment from bressers@redhat.com on 2005-09-14 17:02 EST -- 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.
Reassigning to Fedora Legacy. Still not sure if this affects us or not.... Josh, do you know what you all eventually did with this bug for other distros?
This issue didn't affect FC4, but does affect RHEL. We have an update in progress. Note the ability to exploit this issue is seriously mitigated by how PCRE is used in a python script which processes unsanitized user input.
Josh, did you ever get information on whether or not this effects FC3's python? It seems very close to RHEL4's python...
This issue is so old now I honestly can't remember. Your best bet will be to test the FC4 python as detailed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166335#c4
(Assuming this affects FC3 and FC4 Pythons until proven otherwise. Changing status whiteboard to reflect that assumption & our need to work on this bug.) (Also, research needs to be done to see if there are any other Python secu- rity issues that Legacy needs to fix that have appeared since Legacy inherited FC3 and FC4 maintenance (in January and August, respectively). We can bundle them into this Bugzilla if so.) --dde
This does affect python on FC3, but not on FC4 - FC4 python doesn't include the pcre library. Since I'm rolling packages for another Python vulnerability, I'm including a patch in the FC3 package for this issue in the updated FC3 package. See bug #214395
Since this is being fixed in Bug #214395, I am going ahead and closing this bug as a duplicate of that bug. Thanks, Jeff. *** This bug has been marked as a duplicate of 214395 ***