Bug 323571 - (CVE-2007-5116) CVE-2007-5116 perl regular expression UTF parsing errors
CVE-2007-5116 perl regular expression UTF parsing errors
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,source=vendorsec,rep...
: Security
Depends On: 466966 323781 323791 323801 323811 323821 349461 378121 378131 378141 378151 466967 466968
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-08 15:03 EDT by Josh Bressers
Modified: 2010-08-04 17:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-19 04:07:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for Perl 5.8 from Tavis (1.82 KB, patch)
2007-10-08 15:49 EDT, Josh Bressers
no flags Details | Diff
Corrected patch (1.82 KB, patch)
2007-11-12 13:42 EST, Tomas Hoger
no flags Details | Diff

  None (edit)
Description Josh Bressers 2007-10-08 15:03:52 EDT
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.
Comment 2 Josh Bressers 2007-10-08 15:49:58 EDT
Created attachment 220101 [details]
Patch for Perl 5.8 from Tavis
Comment 3 Josh Bressers 2007-10-08 15:54:54 EDT
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.
Comment 6 Tomas Hoger 2007-10-09 07:09:40 EDT
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.
Comment 7 Josh Bressers 2007-10-09 14:19:04 EDT
This is going to be RHSA-2007:0966
Comment 14 Josh Bressers 2007-11-05 10:57:31 EST
Lifting embargo
Comment 15 Tomas Hoger 2007-11-12 13:42:14 EST
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.
Comment 19 errata-xmlrpc 2010-08-04 17:32:43 EDT
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

Note You need to log in before you can comment on or make changes to this bug.