incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Vulnerability fixed in LibreOffice
Date Sun, 09 Oct 2011 19:26:02 GMT
On Wed, Oct 5, 2011 at 1:14 PM, FR web forum <> wrote:
> Good morning,
> TDF has published a fix for LibO:
> Do you know if OOo is impacted too?
> Thank you

Possibly, but without details it is hard to tell.  But please note
that although the LO press release [1]  says, that the "flaw could
have been used for nefarious purposes, such as installing viruses,
through a specially-crafted file", the Red Hat researcher who found
the issues originally now says that this is not true, writing [2],
"This issue results in an OOB [Ed. "Out of Bounds"] read which is not
exploitable for arbitrary code execution and can simply cause a crash.
We do not consider this as a security issue."

In other words, if you have a corrupted documented, it can cause
LibreOffice to crash.  It is a slow news week when that warrants a
press release.  Luckily I was on vacation, so it was even a slower
week for me ;-)

Reading binary file formats, including the legacy MS Office formats,
is notoriously difficult to do robustly.  This is one reason why
Microsoft has moved on to using OOXML format as their default.  It is
a good argument also for OOo users to stick with ODF.  We'll need to
keep our eyes open for issues like this, since in some cases they can
lead to more serious exploits.

>From reading other responses to this note it sounds like there is some
confusion about how security vulnerabilities should be reported to
this project.  It is actually quite simple.  Go to the project's home
page [3].  Look for the "Security Report" link.  Go to that page [4]
and follow the instructions.  I don't think that there is anything
ambiguous about those instructions.  The language is copied from the
main Apache security page.

Of course, like most things in the project we probably have
conflicting information on the legacy website pointing reporters to a
different page.  We've seen that in other areas as well, multiple
wikis, multiple Bugzilla instances, multiple statements on project
license, multiple users lists, multiple source repositories, multiple
dev lists, etc.  During the transition to Apache infrastructure things
are confusing to the casual observer.  We should try to do better.

Remember, the typical security reporter is not a core project member.
They could be a security researcher, maybe associated with a vendor
selling a security testing/analysis software or services, looking to
bolster their reputation.  Or an academic testing a new approach to
security analysis.  They voluntarily report issues to vendors and open
source projects.  It is a win-win situation.  We get to fix issues and
they get acknowledgement of their contribution.  They do the analysis
voluntarily, but I would not assume that they will spend time trying
to decipher what parts of the website are still
current, and which areas are now preempted by AOOo podling pages.
That is not a reasonable expectation.  We on the project have the
responsibility to make sure that legacy site does not have incorrect

So I'd recommend that we update the "OpenOffice Security Team" website
to state the following:

1) may be discontinued in the future

2) That security reports should be sent to successor project's
security contacts.

3) We should list the AOOo's ooo-security list, as well as the TDF/LO
security list, and contacts for IBM Symphony, RedOffice, as well as
Oracle and Novell since they may have outstanding support contacts for
legacy release of OOo.

Who has write access to that page [5] now?

It is quite natural for representatives of other products based on the
same source code to want to be on AOOo's ooo-security list, to discuss
and resolve issues and co-develop patches.  This is a very natural
desire and has a very natural solution:  Become a committer.  That is
how to get involved.

But if someone wasn't want to do that, then they are not totally
excluded.  Participants on the AOOo ooo-security mailing list have the
authority and ability to share predisclosure information with other
projects, open source, and commercial, that may be impacted by
vulnerabilities that are reported to us.  Everything that I've seen
suggests that we will use that ability responsibly and where
appropriate.  This alternative may lack the immediacy of joining
ooo-security directly, but that is the trade-off.  Return the iCLA and
become a committer and you can easily be on the ooo-security list.
Don't return the iCLA and you can't.

It would be interesting to hear from the experience of other Apache
projects in this area.  Obviously, AOOo is not the only Apache project
that is rebuilt and redistributed by other entities.  This occurs
frequently with native apps, like Subversion to Httpd.  So they
regularly need to receive security reports and develop patches.  How
do they deal with expectations of downstream consumers of the code (as
opposed to binary) releases?



View raw message