Bug 166335
| Summary: | CVE-2005-2491 PCRE heap overflow | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Mark J. Cox <mjc> | ||||
| Component: | python | Assignee: | Mihai Ibanescu <mihai.ibanescu> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0 | CC: | bressers, deisenst, katzj | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | impact=moderate,public=20050801,source=secalert,reported=20050819 | ||||||
| Fixed In Version: | RHSA-2006-0197 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-03-09 20:39:54 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
Mark J. Cox
2005-08-19 11:58:04 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. 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 |