First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 104010
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Thierry Carrez (RETIRED) <koon@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 104010 depends on: Show dependency tree
Bug 104010 blocks:

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug

Description:   Opened: 2005-08-28 01:07 0000 
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.

------- Comment #1 From John N. Laliberte (RETIRED) 2005-08-31 08:20:02 0000 ------- 
leonardop will be taking care of this shortly,

Thanks!

------- Comment #2 From Leonardo Boshell (RETIRED) 2005-09-01 04:08:13 0000 ------- 
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.

------- Comment #3 From Thierry Carrez (RETIRED) 2005-09-01 04:52:30 0000 ------- 
Current KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86"
Target KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86"

------- Comment #4 From Gustavo Zacarias (RETIRED) 2005-09-01 07:49:16 0000 ------- 
sparc stable.

------- Comment #5 From Ian Leitch (RETIRED) 2005-09-01 09:20:19 0000 ------- 
Stable on x86.

------- Comment #6 From Luis Medinas (RETIRED) 2005-09-01 10:29:39 0000 ------- 
Marked Stable on AMD64.

------- Comment #7 From Michael Hanselmann (hansmi) (RETIRED) 2005-09-01 10:51:52 0000 ------- 
Stable on ppc and hppa.

------- Comment #8 From Ian Leitch (RETIRED) 2005-09-01 11:27:30 0000 ------- 
Removing x86 CC, sorry for the spam.

------- Comment #9 From Markus Rothe 2005-09-01 21:04:09 0000 ------- 
stable on ppc64

------- Comment #10 From Jose Luis Rivero (yoswink) 2005-09-02 00:20:48 0000 ------- 
Stable on alpha

------- Comment #11 From Thierry Carrez (RETIRED) 2005-09-02 00:31:57 0000 ------- 
Not sure this needs a GLSA, or maybe a combined one with other
'probably-not-affected' libpcre-challenged packages (like exim, apache...).

------- Comment #12 From Thierry Carrez (RETIRED) 2005-09-02 00:33:31 0000 ------- 
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.

------- Comment #13 From Thierry Carrez (RETIRED) 2005-09-03 02:31:31 0000 ------- 
GLSA 200509-02
ia64 should mark stable to benefit from GLSA.
First Last Prev Next    No search results available      Search page      Enter new bug