First published: Wed Nov 07 2007(Updated: )
<a href="https://access.redhat.com/security/cve/CVE-2006-7224">CVE-2006-7224</a> initially described several integer overflows in pcre, all described here: <a href="http://scary.beasts.org/security/CESA-2007-006.html">http://scary.beasts.org/security/CESA-2007-006.html</a> This id should be used to describe issue #2 in that advisory: 3) More possible integer overflow trouble. pcre_compile: --- if (min == 0) { length++; if (max > 0) length += (max - 1) * (duplength + 3 + 2*LINK_SIZE); } ... else { length += (min - 1) * duplength; if (max > min) /* Need this test as max=-1 means no limit */ length += (max - min) * (duplength + 3 + 2*LINK_SIZE) - (2 + 2*LINK_SIZE); } --- In both these cases, I see no reason why a malicious regexp pattern couldn't cause an integer overflow by using large min / max / duplength values. This will really mess up the critical "length" value.
Credit: secalert@redhat.com secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Pcre Pcre | <=6.6 | |
redhat/pcre | <0:4.5-4.el4_6.6 | 0:4.5-4.el4_6.6 |
redhat/python | <0:2.3.4-14.4.el4_6.1 | 0:2.3.4-14.4.el4_6.1 |
redhat/pcre | <0:6.6-2.el5_1.7 | 0:6.6-2.el5_1.7 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
(Appears in the following advisories)