OpenOffice and CVE-2015-1774

The Apache Software Foundation requires projects hosted under its umbrella to file quarterly reports to the foundation's board of directors; these reports are meant to enable the board to "evaluate the activity and health of the project". In the case of Apache OpenOffice, the process of writing the quarterly reports tends to be a bit fraught, since it rubs the project's nose in the fact that its health is not all that strong. This time around there is an additional factor in the discussion: the fact that OpenOffice has yet to patch a vulnerability announced back in April.

Jan Iversen announced the drafting of the July report at the end of June. The draft did not mince words with regard to the status of the project in general:

Simon Phipps was quick to suggest that the report was missing one key fact: the vulnerability known as CVE-2015-1774 remains unfixed in the released version (4.1.1) of OpenOffice. This vulnerability, disclosed at the end of April, affects the import filter for Hangul Word Processor (HWP) documents; a lack of input sanitizing there means that an attacker can, by way of a specially crafted HWP document, crash the program and, almost certainly, contrive to execute arbitrary code.

LibreOffice fixed this vulnerability in the 4.3.7 release on April 25. OpenOffice, instead, has limited itself to publishing a workaround that consists of telling users to delete the shared object implementing HWP support. The vulnerability will be fixed, it is promised, in the 4.1.2 release, but, as the draft report notes, "no real work has been done since last report" on getting that release out. So OpenOffice remains vulnerable and will continue to be until, somehow, the project is able to get some "real work" done on producing another release.

The rules for quarterly reports say nothing about highlighting open security issues; indeed, they make no mention of security at all. Simon clearly believes that the lack of action on this issue is relevant to the health of the project as a whole, and, thus, relevant to the report. Dennis Hamilton disagreed, though, saying that "very few users" would be affected by an exploit, and that the publication of a "straightforward mitigation" is sufficient. The failure to fix this vulnerability, he said, should not overshadow the more serious problem of the stalled 4.1.2 release.

For the purposes of the board report, Dennis may well be right; telling the board about this vulnerability will, in the end, protect few users from it. But he may be understating the severity of the vulnerability itself. It does not, as he suggests, just affect a small community of Korean users working with files created by an ancient word processor; instead, it affects anybody who can be convinced to open a file in the HWP format. Such files need not, incidentally, have a .hwp extension. There is no shortage of evidence showing that users will open dodgy email attachments from suspicious sources; there is no reason to believe that their behavior would be different in this case. Rather than affecting a small group, this vulnerability affects all OpenOffice users; given that the project loudly claims to have been downloaded over 100 million times, that is a lot of users.

He is also certainly overstating the "straightforward" nature of a mitigation that (1) must be actively sought out by users and (2) requires performing manual surgery on an OpenOffice installation. Few users, even those who download the program today, will notice that there is a vulnerability requiring action on their part to mitigate. A new release would inspire at least some users to update, but workaround instructions hidden away on their own page will bring about few secured systems — even if the instructions were readily discoverable, which these are not.

The moral of this story is that, whenever any of us uses a piece of software, we are depending on the organization behind it — whether it's a corporation or a free-software development community — to protect us from known vulnerabilities. Projects that are short of developers may not be able to live up to that expectation. At any given time, a typical Linux system probably contains a number of applications that lack security updates because their development community has faded away.

Unfortunately, projects that fall below a critical mass of developers rarely send out an advisory to that effect. OpenOffice is actually nearly unique in this regard as a result of the quarterly report requirement; it has informed the world that it is struggling, even though it did ultimately choose to omit information on this specific vulnerability from its quarterly report. In many other cases, projects simply go dark. Linux users are lucky in that distributors can (and often do) serve as a second line of defense for unmaintained projects; users of other operating systems tend to be on their own. In this case, distributors noticed which way the wind was blowing some time back; few of them ship OpenOffice at all. (Debian's recent decision to move away from libav can be seen as another example of this process in operation). Linux users, thus, will be relatively safe, but it appears that there are many millions of vulnerable users out there with no fix in sight.

Index entries for this article
Security	Bug reporting
Security	OpenOffice.org/LibreOffice

---

to post comments