Summary: | <app-office/openoffice{,-bin}-3.3: multiple vulnerabilities (CVE-2010-{3450,3451,3452,3453,3454,3689,4253,4643}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Yury German <blueknight> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | write2David |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://seclists.org/fulldisclosure/2011/Jan/473 | ||
Whiteboard: | A2 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Yury German
2011-01-26 21:17:42 UTC
We have a bit of a special situation here, basically: I don't plan to do any more updates for app-office/openoffice, people should move to app-office/libreoffice instead. Let me explain why, so everyone understands the reasoning: *) libreoffice is actually the successor of go-oo / ooo-build which we based our openoffice-releases on since a few years, which also means *) we didn't have a vanilla openoffice ebuild since quite some time *) trying to do a vanilla openoffice ebuild is a very unfortunate experience, believe me, we've been there. *) all other Linux distros are moving to Libreoffice too. So basically I'd like to deprecate app-office/openoffice soon. And so I ask: Do you have any advice for me how to handle that best? I would recommend that you stabilize the current non vulnerable build (3.3.0 RC 10) so that the vulnerable builds can be masked. Then request for stabilization of Libreoffice so that now there is a migration path available for stable builds. This is just an idea. (In reply to comment #1) > So basically I'd like to deprecate app-office/openoffice soon. And so I ask: Do > you have any advice for me how to handle that best? > So, if you feel that the libreoffice ebuilds are ready for prime time, stabilize them and we'll advise people to migrate to libreoffice in the GLSA. On the other hand, such things shouldn't really happen during a security update and bumping OOo one last time shouldn't be too much harm. I guess I'm fine with both alternatives, though slightly preferring the latter. (In reply to comment #3) > On the other hand, such things shouldn't really happen during a security update > and bumping OOo one last time shouldn't be too much harm. Like I tried to say before: This is not possible without a pretty high amount of extra-work and complications, as a new openoffice-bump would be basically a totally new ebuild. A simple bump is not possible, build-system- and code-wise Libreoffice is the direct successor to what we had in portage before as app-office/openoffice before, NOT the current OpenOffice.org There have been stable releases of Libreoffice and Libreoffice-bin in the tree for quite some time. So could we please now advice people to move away from openoffice for this bug? (and mask / remove it) CVE-2010-4643 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4643): Heap-based buffer overflow in Impress in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted Truevision TGA (TARGA) file in an ODF or Microsoft Office document. CVE-2010-4253 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4253): Heap-based buffer overflow in Impress in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted PNG file in an ODF or Microsoft Office document, as demonstrated by a PowerPoint (aka PPT) document. CVE-2010-3454 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3454): Multiple off-by-one errors in the WW8DopTypography::ReadFromMem function in oowriter in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via crafted typography information in a Microsoft Word .DOC file that triggers an out-of-bounds write. CVE-2010-3453 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3453): The WW8ListManager::WW8ListManager function in oowriter in OpenOffice.org (OOo) 2.x and 3.x before 3.3 does not properly handle an unspecified number of list levels in user-defined list styles in WW8 data in a Microsoft Word document, which allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted .DOC file that triggers an out-of-bounds write. openoffice ebuilds marked for removal. Only leaves around the libreoffice versions that are unaffected. (In reply to comment #7) > openoffice ebuilds marked for removal. Only leaves around the libreoffice > versions that are unaffected. Ok, thanks. We still need to publish a GLSA; added to existing request. CVE-2010-3689 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3689): soffice in OpenOffice.org (OOo) 3.x before 3.3 places a zero-length directory name in the LD_LIBRARY_PATH, which allows local users to gain privileges via a Trojan horse shared library in the current working directory. CVE-2010-3452 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3452): Use-after-free vulnerability in oowriter in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via crafted tags in an RTF document. CVE-2010-3451 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3451): Use-after-free vulnerability in oowriter in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via malformed tables in an RTF document. CVE-2010-3450 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3450): Multiple directory traversal vulnerabilities in OpenOffice.org (OOo) 2.x and 3.x before 3.3 allow remote attackers to overwrite arbitrary files via a .. (dot dot) in an entry in (1) an XSLT JAR filter description file, (2) an Extension (aka OXT) file, or unspecified other (3) JAR or (4) ZIP files. Nothing to be done by office team anymore, removing us from cc. This issue was resolved and addressed in GLSA 201408-19 at http://security.gentoo.org/glsa/glsa-201408-19.xml by GLSA coordinator Kristian Fiskerstrand (K_F). |