On Wed, Oct 5, 2011 at 1:14 PM, FR web forum <[email protected]> wrote: > Good morning, > > TDF has published a fix for LibO: http://wp.me/p1byPE-bQ > > 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 OpenOffice.org 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 information. So I'd recommend that we update the "OpenOffice Security Team" website to state the following: 1) [email protected] 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? -Rob [1] http://blog.documentfoundation.org/2011/10/05/the-document-foundation-publishes-details-of-libreoffice-3-4-3-security-fixes/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=725668 [3] http://incubator.apache.org/openofficeorg/ [4] http://incubator.apache.org/openofficeorg/security.html [5] http://www.openoffice.org/security/
