See $URL and bug 235770.
Confirmed, we are installing /usr/lib/openoffice/program/senddoc and it contains code which allows for overwriting arbitrary files via symlink attacks. Tested 2.4.1, 3* is still hardmasked on Gentoo and is not vulnerable according to $URL. This (lines 3 and 4 in the mentioned script) just looks like debug code which could probably removed without problems.
Most of the other distributions (SUSE, Fedora) are handling this low key and want to just fix it with 3.0, as they don't see a big risk in it. Not saying we should do the same, just giving some perspective. Did someone already check openoffice-bin?
(In reply to comment #2) > Most of the other distributions (SUSE, Fedora) are handling this low key and > want to just fix it with 3.0, as they don't see a big risk in it. Not saying we > should do the same, just giving some perspective. The impact is that a local attacker can trick a victim into truncating any local file if he gets the victim to call that script. I don't know the timeframe for a new release (and its stabling), but I do feel the pain of users rebuilding OO. > Did someone already check openoffice-bin? Yes, /usr/lib32/openoffice/program/senddoc does the same.
Well OOo 3.0 (-bin and source) is in the tree, unmasked and should be fine
Arches, please test and mark stable: - app-office/openoffice-3.0.0 (amd64 ppc x86) - app-office/openoffice-bin-3.0.0 (amd64 x86)
marked the -bin version stable on amd64/x86. maybe I find some time tomorrow for the non-bin...
amd64/x86 stable
ppc stable, sorry for the delay *hide*
GLSA request filed.
GLSA 200812-13
As reported on bug 238539, some ~arch users cannot install this issue.
(In reply to comment #11) > As reported on bug 238539, some ~arch users cannot install this issue. > How is this bug preventing people to install OOo 3.0 when there is a known workaround for this issue (which is actually referenced in the ebuild)?
You mean rebuilding with USE=kdeprefix? Re-thinking the situation, it is no worse than any other USE-dependency and no blocker to the installation. Sorry for the noise.
(In reply to comment #13) > You mean rebuilding with USE=kdeprefix? Yes > > Re-thinking the situation, it is no worse than any other USE-dependency and no > blocker to the installation. Sorry for the noise. > No problem, I'm going to add the patch soonish anyway, I just didn't think it was security related...