An odd vulnerability report for LibreOffice
LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
An October 5 press release from The
Document Foundation provides a bit of information about a vulnerability
that was fixed in recent versions of LibreOffice (LO). The vulnerability sounds
fairly serious: "This flaw could have been
used for nefarious purposes, such as installing viruses, through a
specially-crafted [.doc] file.
" It was evidently fixed, silently, in
versions 3.4.3 and 3.3.4 of LO, which were released in August. The details
(such as they are) were withheld "until users
have been given time to migrate to the new version
", but it isn't at
all clear that Linux distributions have put out fixes yet. Worse still,
OpenOffice.org (OOo) is vulnerable as well, but there has been no release
from that project since January.
As of this writing, only Debian has released a security update to address the problem, and that fix is only for OOo as Debian hasn't had a release that contains LO. Other distributions may have updated LO (and/or OOo), but just as bug fix releases. They may have been misled by the release notes for LO 3.4.3, which makes no mention of security fixes (nor does the release notes for 3.3.4). Even the detailed list of fixes appears to be mute about the problem.
Now that the vulnerability has been made public as CVE-2011-2713 (just a placeholder at the moment), one would guess that other distributions will be releasing updates soon as well. Even if a bug fix update did pick up the fix, it would make sense for distributions to put out a security alert so that their users will be more likely to upgrade. But it's a little puzzling how we got to this point.
The problem was found by Red Hat security researcher Huzaifa Sidhpurwala
and was fixed by Caolan McNamara of
Red Hat and Marc-André Laverdière of Tata Consultancy
Services, according to the press release. That would seem to clearly show
that some folks at Red Hat (at least)
were aware of the problem. In fact, McNamara put out bug fix updates for both OOo
(for F14) and LO (for F15) in September that only mention "Update for
commonly reported crashes
" and "Fixes for
commonly reported problems
". Was the fix for CVE-2011-2713
included, but just not mentioned?
Press releases are not the usual way that vulnerabilities are announced, at
least in the free software world. The wording of that release certainly
indicates that the project was aware of the security implications of the
fix, but withheld the information in accordance with "industry best
practice
". Perhaps the project was waiting until distributions were
able to update their LO packages (albeit silently), but that begs another
question: what about OOo?
One hopes that the press release is not the first time that the OOo community is hearing about the vulnerability, but that seems to be the case. When the press release was reported to the Apache OpenOffice (AOO) development mailing list, Dennis Hamilton indicated that it might be the first notice that AOO had received. But Simon Phipps quoted an unnamed LO developer who claimed to have alerted AOO:
> The initial report was sent to securityteam@openoffice.org on
> 25-07-2011, the assigned CVE id was cc'ed there somewhat later on. I
> posted the 5 patches which in combination would fix it to the list as
> well. I was informed an ApacheOOo representative had joined the list.
Evidently, an AOO representative was not added to the mailing list, though, as Hamilton pointed out:
It certainly would have been a nice
gesture—in keeping with "responsible disclosure"—for the LO folks to ensure that AOO was up to speed before
putting out a press release.
As Hamilton put it: "I trust this is the last time that either of our projects learn about
something like this in a press release.
"
But Hamilton also notes that the release mentions additional fixes:
It's hard to disagree with that. There is no good reason that LO and AOO can't work together on security issues, regardless of any other friction there may be between the two. It's unfortunate that the "securityteam" mailing list didn't include any AOO folks (one guesses that it does now or will soon), but there is no reason that AOO should have learned about this problem via press release.
The LO developer's message would seem to indicate that OOo is vulnerable, but it's a little too early to say for sure. It is possible that the problem only exists in Go-OO-derived builds (which is what Linux distributions typically shipped prior to LO coming on the scene). If OOo is vulnerable, it's also unclear what AOO will be able to do about it. At the moment, AOO is in a state of flux as it transitions to an Apache incubator project. There have been no releases of the AOO project and it may still be a ways off before that can happen.
For Linux users, the problem will likely sort itself out in short order. Distributions will patch LO and OOo if they haven't already and make them available to their users. For Windows and Mac OS X users of OOo, though, the picture is murkier—at least if the vulnerability exists in those versions. There aren't distribution-like entities for applications on those platforms and the AOO project is not (yet) in a position to do security releases. It might be prudent for those users to consider switching to LO, at least temporarily, until AOO sorts itself out. Being cautious about opening random .doc files is another alternative, but that's always been good advice, though it is rarely followed.
In the final analysis, the press release raises more questions than it actually answers. What was, presumably, an attempt to shed some light on a security flaw in LO instead muddied the waters considerably. One hopes that a more transparent security process will come about for LO so that all of its downstreams—as well as its AOO "sidestream"—are notified of security problems in a timely way. In fact, both LO and AOO should be thinking about proper ways to handle and announce security fixes, perhaps along the lines of what Mozilla does. It may be "industry standard" to silently fix security holes, but free software communities can, and should, do better than that.
Index entries for this article | |
---|---|
Security | Bug reporting |
Security | OpenOffice.org/LibreOffice |
(Log in to post comments)
Debian & general comment
Posted Oct 5, 2011 21:47 UTC (Wed) by Curan (subscriber, #66186) [Link]
As of this writing, only Debian has released a security update to address the problem, and that fix is only for OOo as Debian hasn't had a release that contains LO.
Well, even though it isn't released yet as a stable release, the LO versions in testing and unstable aren't affected either as they are 3.4.3-1 and 3.4.3-3.
Apart from that I really don't like the communications style. Bugs, including security issues, should be made public immediately. It would help users and administrators to take appropriate actions, including being e.g. extra careful about opening files, that might trigger the bug. I hope all LO devs and/or TDF members won't do this again. Better name a bug and allow all to take precautions than leave everybody in the dark with the risk, that some malware developer stumbles across something like this and can take advantage of it.
Debian & general comment
Posted Oct 6, 2011 2:56 UTC (Thu) by steffen780 (guest, #68142) [Link]
More importantly, the LO project seriously needs to re-evaluate its policies on this. There's plenty of arguments for immediate as well as for delayed disclosure (I don't think that topic needs any further lengthy discussions), but afaik there's universal agreement that you always say when an update includes security fixes (or at least, like the kernel, say "this might include security fixes, everyone should update immediately"). Still, at least they fixed it.
Oh and if the AOO-project still can't watch its security mailbox it should probably advice people to go to LO instead until they had time to get setup with their duplicate project...
*: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/a...
An odd vulnerability report for LibreOffice
Posted Oct 5, 2011 22:16 UTC (Wed) by mjw (subscriber, #16740) [Link]
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2713
It is somewhat odd that the apache people were unaware of the security report, since coordinating security issues using a list for all clones/forks/spoons at securityteam@openoffice.org was discussed on their own list:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-de...
And I thought apache now owned the domain, but maybe they don't yet own the smtp services?
An odd vulnerability report for LibreOffice
Posted Oct 5, 2011 22:32 UTC (Wed) by jake (editor, #205) [Link]
Interesting. I wonder why it's "CLOSED NOTABUG". That, at least, explains why I couldn't find it when I searched for OPEN bugs in the Red Hat bugzilla this morning.
The comment:
We do not consider a crash of a client application such as openoffice.org to be a security issue.
seems a little strange too ... I guess Red Hat doesn't believe that it's an exploitable crash? I wonder what it bases that on ...
jake
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 7:50 UTC (Thu) by huzaifas (guest, #45244) [Link]
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 9:06 UTC (Thu) by mjw (subscriber, #16740) [Link]
There is now also a new comment explaining why it was first thought to be a security issue and then not. Also included is a timeline that clearly mentions openoffice.org being notified weeks ago. Why the apache people weren't aware still is a bit of a mystery though (Assuming they are in control of openoffice.org now, maybe Oracle still haven't handed it all over? Or maybe the apache office project just don't have enough hackers to take care of security issues anymore?).It initially appeared that this flaw may be exploitable similar to CVE-2010-3452, where an OOB Read caused Arbitrary Code Execution. However in the case of this particular flaw, the junk data read is just parsed into an internal representation of properties and the maximum harm this should cause in application crash (Denial Of Service).Timeline:
- Reported to securityteam@openoffice.org on 25-July-2011
- Recieved a reply (with tdf-security@lists.documentfoundation.org copied) on the same date
- Release date changed with a few delays in between
- Release on 5-Oct-2011
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 9:19 UTC (Thu) by epa (subscriber, #39769) [Link]
We do not consider a crash of a client application such as openoffice.org to be a security issue.Maybe it is a security issue, maybe not; but it is certainly a bug. I've been disappointed by this attitude from Red Hat in other cases too. If something crashes, it may not be the most important thing to fix, but there is no way it could be described as NOTABUG.
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 11:38 UTC (Thu) by rwmj (subscriber, #5474) [Link]
Nevertheless, the resolution here is correct. The component is set to Security Response, and it is not a *security* bug. And you can see that an explanation was given in comment 14. This is all correct according to the rules:
https://bugzilla.redhat.com/page.cgi?id=fields.html#status
What should probably have happened is the bug was cloned to the LibreOffice component, and fixed there. It appears that wasn't done, but although I'm not certain about the timeline, it looks like since it was already fixed in LO, there was no need to clone the bug and just close it straight afterwards.
So there you go, my strictly technical "by the book" explanation for this
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 14:04 UTC (Thu) by epa (subscriber, #39769) [Link]
The 'rules' document you mentioned defines NOTABUG as follows:The problem described is not a bug. An explaination of why this resolution has been chosen should be supplied.
Comment 14 in the bug report simply says that this is not a security issue.
My point is that while it may not be a security issue, it is a bug, and that therefore the NOTABUG resolution, as defined in the explanation document you gave, is not appropriate. It is defined as meaning "The problem described is not a bug", which is not at all the same as "It is a bug, but not the particular kind of bug appropriate to this component in Bugzilla".
Still, as you say, it looks like the bug was dealt with in this case because it was already fixed upstream; it's just the Bugzilla entry which is misleading.
It would be good for Bugzilla to have a MISFILED resolution for reports filed against the wrong component or whatever. That would provide a way to close them without making a claim that "this is not a bug" or "we will not fix it".
An odd vulnerability report for LibreOffice
Posted Oct 7, 2011 18:32 UTC (Fri) by daglwn (guest, #65432) [Link]
An odd vulnerability report for LibreOffice
Posted Oct 7, 2011 18:46 UTC (Fri) by intgr (subscriber, #39733) [Link]
Sounds like pointless bureaucracy. How about just reassigning the bug to the right component instead?
An odd vulnerability report for LibreOffice
Posted Oct 5, 2011 22:32 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link]
* new upstream release (keeping the old tarball, only using patches) (LP: #849855)
- http://bugs.freedesktop.org/show_bug.cgi?id=38955
- http://bugs.freedesktop.org/show_bug.cgi?id=30550
- http://bugs.freedesktop.org/show_bug.cgi?id=37057
- https://issues.apache.org/ooo/show_bug.cgi?id=118018
- handle busted emf lengths
- fix regression in SvGlobalName::operator <
- fix loss of init on merge
- valgrind: init some values
- merge these sprm finders and do it right
Collaborating In The Only Place Possible
Posted Oct 5, 2011 22:55 UTC (Wed) by webmink (guest, #47180) [Link]
It's unfortunate that the "securityteam" mailing list didn't include any AOO folks
It definitely did - I was forwarded the e-mail confirming it. Given the LO developers were barred from joining the Apache security list when it formed as it's only open to hand-picked Apache committers, the securityteam mailing list is the only remaining place for collaboration. Given the LO developers posted the report and the patches to that list, it's hard to see what more they could have done. S.
Collaborating In The Only Place Possible
Posted Oct 6, 2011 8:00 UTC (Thu) by dgm (subscriber, #49227) [Link]
What about sending them a maliciously crafted doc file that runs a script that silently pushes the patch to the repository?
See? it was not that hard!
An odd vulnerability report for LibreOffice
Posted Oct 6, 2011 10:40 UTC (Thu) by mmeeks (subscriber, #56090) [Link]
> community is hearing about the vulnerability, but that seems to
> be the case
Of course not - it was disclosed (with patches) on the shared vulnerability mailing list; and at least one Apache Committer: Malte Timmerman was subscribed there.
> Perhaps the project was waiting until distributions were able to update
> their LO packages (albeit silently)
Of course - that is standard practice.
> There is no good reason that LO and AOO can't work together on
> security issues, regardless of any other friction there may be
> between the two.
Some co-ordination is of course reasonable, however LibreOffice has developers actively working in this area - which involves fixing innumerable bugs of various risks. Few of these have associated CVE + circus.
Rob Weir - "monitoring" list where the patches were posted 2+ months ago
Posted Oct 7, 2011 13:42 UTC (Fri) by mmeeks (subscriber, #56090) [Link]
http://mail-archives.apache.org/mod_mbox/incubator-ooo-de...
from Rob Weir, and I quote:
"As I understand it now, the OpenOffice.org currently directs visitors
to report vulnerability reports to securityteam@openoffice.org. This
address is currently being monitored."
ie. Evidently, an AOO representative **was** added to the mailing list