An odd vulnerability report for LibreOffice

Posted Oct 5, 2011 22:32 UTC (Wed) by jake (editor, #205)
In reply to: An odd vulnerability report for LibreOffice by mjw
Parent article: An odd vulnerability report for LibreOffice

> 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

Posted Oct 6, 2011 7:50 UTC (Thu) by huzaifas (guest, #45244) [Link]

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

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

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

An odd vulnerability report for LibreOffice

Posted Oct 6, 2011 9:19 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

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] (3 responses)

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

Posted Oct 6, 2011 14:04 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

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]

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

An odd vulnerability report for LibreOffice

Posted Oct 7, 2011 18:46 UTC (Fri) by intgr (subscriber, #39733) [Link]

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