Gnumeric sources apparently include their own (affected) copy of the libpcre library. See bug 103337 for details on the vulnerability. There may not be much use of parsing of untrusted PCRE in gnumeric (?), but it should be fixed nevertheless. If possible, it might be a good idea to make gnumeric build against the system libpcre rather than using the internal copy. Ccing maintainers for advice.
leonardop will be taking care of this shortly, Thanks!
I've committed gnumeric-1.4.3-r2.ebuild, which includes a patch for this problem. However, the ebuild is not marked stable yet. Could you please confirm if the patch covers the whole vulnerability? For reference, the patch is based on the differences between pcre-6.1 and pcre-6.2, specifically in the file pcre_compile.c. Also, modifying gnumeric to use an external pcre is untested so it doesn't seem like a good alternative at the moment. I could push this patch upstream once I have your blessing, and ask the developers about the possibility of optionally linking against an external pcre.
Current KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86" Target KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86"
sparc stable.
Stable on x86.
Marked Stable on AMD64.
Stable on ppc and hppa.
Removing x86 CC, sorry for the spam.
stable on ppc64
Stable on alpha
Not sure this needs a GLSA, or maybe a combined one with other 'probably-not-affected' libpcre-challenged packages (like exim, apache...).
Hmm. Our beloved Martin Pitt says : "In gnumeric this bug could be exploited to execute arbitrary code with the privileges of the user if the user was tricked into opening a specially crafted spreadsheet document." So I guess this really is a B2 and we need a GLSA for it.
GLSA 200509-02 ia64 should mark stable to benefit from GLSA.
