LWN: Comments on "An odd vulnerability report for LibreOffice"

An odd vulnerability report for LibreOffice

intgr — Fri, 07 Oct 2011 18:46:27 +0000

> It would be good for Bugzilla to have a MISFILED resolution

Sounds like pointless bureaucracy. How about just reassigning the bug to the right component instead?

An odd vulnerability report for LibreOffice

daglwn — Fri, 07 Oct 2011 18:32:18 +0000

Or just change the component it's assigned to. Why is that so hard?

Rob Weir - "monitoring" list where the patches were posted 2+ months ago

mmeeks — Fri, 07 Oct 2011 13:42:40 +0000

Oh, and now I take a look at the public apache mail archive, I see this:

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

An odd vulnerability report for LibreOffice

epa — Thu, 06 Oct 2011 14:04:40 +0000

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

rwmj — Thu, 06 Oct 2011 11:38:51 +0000

The "NOTABUG" designation does cause some consternation, because it sounds like we're saying it's "not a bug", which of course it is.

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

mmeeks — Thu, 06 Oct 2011 10:40:51 +0000

> 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

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.

An odd vulnerability report for LibreOffice

epa — Thu, 06 Oct 2011 09:19:45 +0000

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

mjw — Thu, 06 Oct 2011 09:06:39 +0000

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?).

RHBZ725668#c14:

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

Collaborating In The Only Place Possible

dgm — Thu, 06 Oct 2011 08:00:33 +0000

>it's hard to see what more they could have done.

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

huzaifas — Thu, 06 Oct 2011 07:50:36 +0000

It is not exploitable (atleast on linux) because its an OOB Read. It results in parsing of some out of bounds junk values.

Debian & general comment

steffen780 — Thu, 06 Oct 2011 02:56:36 +0000

3.3.4 has been in Gentoo-testing since 17Aug, stable on x86 on 4Sep *. Tho I'm not sure if Gentoo counts as a major distro.
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...

Collaborating In The Only Place Possible

webmink — Wed, 05 Oct 2011 22:55:14 +0000

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.

An odd vulnerability report for LibreOffice

csamuel — Wed, 05 Oct 2011 22:32:31 +0000

Ubuntu have pushed a 3.3.4 release for Natty today, though it's not yet listed as a USN and the changelog associated with it doesn't (obviously) list any security related bugs (unless the OOo bugzilla entry about a document that locks up OOo is it).

* 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

An odd vulnerability report for LibreOffice

jake — Wed, 05 Oct 2011 22:32:07 +0000

> Looks like Red Hat bugzilla has all LO patches and a backport patch for OOo

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

mjw — Wed, 05 Oct 2011 22:16:31 +0000

Looks like Red Hat bugzilla has all LO patches and a backport patch for OOo:
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?

Debian & general comment

Curan — Wed, 05 Oct 2011 21:47:23 +0000

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.