CVE Request: LibreOffice -- several issues

[Alexander Cherepanov <cherepan () mccme ru>]

On 2014-11-26 19:48, Caolán McNamara wrote:
> On Wed, 2014-11-26 at 18:43 +0300, Alexander Cherepanov wrote:
> > https://www.libreoffice.org/about-us/security/advisories/ , which
> > happily lists several DoS issues: CVE-2012-4233, CVE-2013-4156. IMHO
> > this reaffrims the default security policy.
>
> > From our side, the page is generally intended to just list all resolved
> CVEs which were opened wrt LibreOffice (and a few which were opened
> against libraries bundled into upstream provided LibreOffice builds).
> There's no filtering out of any CVEs logged about LibreOffice that might
> be considered not significant.
>
> Again, from our side, when presented with DoS documents we do tend to
> push back against granting them security bug status. Not that we don't
> think they are serious, just that we think they don't merit extra
> special (time expensive) security level handing. I *think* 2012-4233 was
> issued/requested directly by the discoverer high-tech bridge security
> research. Maybe it initially looked a bit more serious than it turned
> out.
>
> In other cases e.g. 2012-4156 the affected application is really Apache
> OpenOffice not LibreOffice but the same document that corrupts AOO
> causes us to deref a NULL and fall over so it got listed there because
> we people asked about it, given our shared code base origin. (maybe
> something similar was also the case for 2012-4233, I forget, it was
> years ago)

1. Thanks for the info, it's interesting and explains a bit of history. 
OTOH I didn't imply that you somehow filtered the page or something. 
(The list of CVEs indeed looks suspicious -- such a large project cannot 
have so little CVES. But that's another question.) Nevertheless the pair 
of pages (.../security/ and .../security/advisories/) looks misleading.

2. In fact, I don't care too much if you treat DoS documents as security 
issues or if CVEs are assigned for them. I don't yet have a strong 
opinion about it. What bothers me is the disconnect between an assumed 
and a real security (and security process) of LO. If you have a security 
policy which is not default I think it should be clearly communicated to 
an end user.

3. IMHO the usual use-case for LO is to open untrusted files in various 
formats and I thought that security of LO would be akin to the one of 
browsers. For comparison, I was aware that `strings` has some problems 
but the situation with LO took me by surprise. Perhaps it's just me (I 
don't use LO actively). Actually, hints are there: LO in Debian Stable 
is last updated 1.5 years ago and a list of CVEs for LO is ridiculously 
short.

All this leads to the thought that non-security treatment of DoS issues 
is just the tip of the iceberg. Assuming that many security bugs were 
fixed in current versions of LO the fact that LO in Debian Stable isn't 
updated for a long time probably means that security fixes are not 
marked as such and hence are not backported. Please correct me if I'm wrong.

--
Alexander Cherepanov