The following packages (and others) could contain the vulnerable libpcre library: exim Python gnumeric apache nmap (Fyodor reports that nmap is safe though) postfix php .... I'm not sure which uses the included one and which uses the external one.
They are vulnerable only if they use untrusted inputs as PCRE. nmap and postfix ebuilds have a libpcre depend.
A bug was opened for PHP (Mandriva released an advisory). That leaves us with the following to analyze : exim Python gnumeric apache + do a more thorough check to find others ?
Bug 103894 opened to track exim
gnumeric and Python bugs opened after Mandriva disclosure.
Keeping this bug to track Apache. The idea would be to link to the system libpcre rather than using the included-in-Apache-sources one.
Fixed in Apache httpd 2.0.55-dev : low: PCRE overflow CAN-2005-2491 An integer overflow flaw was found in PCRE, a Perl-compatible regular expression library included within httpd. A local user who has the ability to create .htaccess files could create a maliciously crafted regular expression in such as way that they could gain the privileges of a httpd child. Patch at : http://svn.apache.org/viewcvs?rev=233493&view=rev
I don't believe that patch will apply cleanly, since it is against PCRE 5.0, not 3.9 that httpd-2.0 comes with.
Ah. I apparently got lost in the branches. This one should apply better to 2.0: http://people.apache.org/~jorton/CAN-2005-2491.patch
If someone else from the apache herd doesn't step up to fix this, I'll take care of it this weekend.
New ebuilds in CVS. Apache 2 old-style should upgrade to: =net-www/apache-2.0.54-r15 Apache 2 new-style should upgrade to: =net-www/apache-2.0.54-r30
Handling stable marking on bug #104807
GLSA 200509-12
