Hello,
Our software uses libpcre 5.0 version. Given that the pcre_compile() was
refactored in version 7.0, could you advise if PCRE Regular Expression Heap
Based Buffer Overflow Vulnerability affects versions prior to 7.0 alos?
Thanks,
Venu A
Version 7.0 19-Dec-06 --------------------- ...
17. I have done a major re-factoring of the way pcre_compile() computes the
amount of memory needed for a compiled pattern. Previously, there was code
that made a preliminary scan of the pattern in order to do this. That was
OK when PCRE was new, but as the facilities have expanded, it has become
harder and harder to keep it in step with the real compile phase, and there
have been a number of bugs (see for example, 4 above). I have now found a
cunning way of running the real compile function in a "fake" mode that
enables it to compute how much memory it would need, while actually only
ever using a few hundred bytes of working memory and without too many
tests of the mode. This should make future maintenance and development
easier. A side effect of this work is that the limit of 200 on the nesting
depth of parentheses has been removed (though this was never a serious
limitation, I suspect). However, there is a downside: pcre_compile() now
runs more slowly than before (30% or more, depending on the pattern). I
hope this isn't a big issue. There is no effect on runtime performance.
PCRE Regular Expression Heap Based Buffer Overflow Vulnerability
Bugtraq ID: 30087 Class: Design Error CVE: CVE-2008-2371
Remote: Yes Local: No Published: Jul 01 2008 12:00AM Updated: Jul 07
2008 03:39PM Credit: Tavis Ormandy Vulnerable: S.u.S.E. openSUSE 10.3
RedHat Fedora 9 0
RedHat Fedora 8 0
PCRE PCRE 7.7
GNOME glib 2.16.3
Debian Linux 4.0 sparc
Debian Linux 4.0 s/390
Debian Linux 4.0 powerpc
Debian Linux 4.0 mipsel
Debian Linux 4.0 mips
Debian Linux 4.0 m68k
Debian Linux 4.0 ia-64
Debian Linux 4.0 ia-32
Debian Linux 4.0 hppa
Debian Linux 4.0 arm
Debian Linux 4.0 amd64
Debian Linux 4.0 alpha
Debian Linux 4.0
Not Vulnerable: GNOME glib 2.16.4
