Bug 323571 (CVE-2007-5116)
| Summary: | CVE-2007-5116 perl regular expression UTF parsing errors | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Josh Bressers <bressers> | ||||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | |||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | unspecified | CC: | kreilly, mkoci, psplicha, robin.norwood | ||||||
| Target Milestone: | --- | Keywords: | Security | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-12-19 09:07: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: | 323781, 323791, 323801, 323811, 323821, 349461, 378121, 378131, 378141, 378151, 466966, 466967, 466968 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
Created attachment 220101 [details]
Patch for Perl 5.8 from Tavis
I don't believe this affects perl 5.6. I wouldn't mind if someone could back me up on this, but my research suggests that the 5.6 regular expression interpreter is either in unicode mode or not, it can't switch, which means there can't be a mismatch between the passes. Part of perlunicode(1) from perl5.6 what corresponds to quote used in original
description:
The existing regular expression compiler does not produce polymorphic
opcodes. This means that the determination on whether to match Unicode
characters is made when the pattern is compiled, based on whether
the pattern contains Unicode characters, and not when the matching
happens at run time. This needs to be changed to adaptively match
Unicode if the string to be matched is Unicode.
This is going to be RHSA-2007:0966 Lifting embargo Created attachment 255541 [details]
Corrected patch
Original patch was mangled while being mailed, this one was used in updated
RHEL perl packages and really fixes the issue.
Fixed in affected versions of Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2007-0966.html Red Hat Application Stack: http://rhn.redhat.com/errata/RHSA-2007-1011.html and Fedora: https://admin.fedoraproject.org/updates/F7/FEDORA-2007-3255 https://admin.fedoraproject.org/updates/F8/FEDORA-2007-3218 This issue has been addressed in following products: Red Hat Certificate System 7.3 Via RHSA-2010:0602 https://rhn.redhat.com/errata/RHSA-2010-0602.html |
Tavis Ormandy and Will Drewry have discovered a flaw in the way perl calculates the space needed to process a regular expression. It is possible to cause the two passes to mismatch. To quote their mail: The compile phase uses multiple passes (similar to older pcre releases), once to determine space requirements and another to actually compile the expression, however it's very simple to cause the two passes to mismatch. From the perl documentation: > The regular expression compiler produces polymorphic opcodes.That is, > the pattern adapts to the data and automatically switches to the Unicode > character scheme when presented with Unicode data--or instead uses a > traditional byte scheme when presented with byte data. This unfortunately means that you can cause the mode to switch at an arbitrary point, and then subsequent passes of any of the expression prior to this point switch will be passed differently, and thus potentially have their space requirements miscalculated. Acknowledgements: Red Hat would like to thank Tavis Ormandy and Will Drewry for properly disclosing this issue.