Apache OpenOffice and CVE-2016-1513

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

The Apache OpenOffice (AOO) project has suffered from a lack of developers for some time now; releases are infrequent and development of new features is relatively slow. But a recent security advisory for CVE-2016-1513 is rather eye-opening in that it further shows that the project is in rough shape. Announcing a potential code execution vulnerability without quickly providing a new release of AOO may be putting users of the tool at more risk than they realize.

The bug is a memory corruption problem that can occur when opening crafted .odp or .otp presentation files in the Impress presentation editor. The advisory says that "the conditions under which arbitrary code can be executed are complex and difficult to achieve in an undetected manner"; it has been given a "Medium" severity level by the project. The patch shows that a condition enforced in debug mode needs to also be enforced at runtime. The fix is simple and straightforward, which should seemingly make it relatively easy to get an updated release into the hands of users.

There is an anti-virus signature available to detect these kinds of crafted files and there are no known exploits in the wild—at least there were no exploits known when the advisory was published on July 21. Since that time, it is not hard to imagine that some folks with a malicious bent might well have worked something up. And, while creating a reliable exploit may take some work, it certainly isn't all that hard to get users to open slide decks from email or elsewhere—a spear phishing attack where the targets are known may even make that easier.

The advisory notes that keeping anti-virus software up to date is one defense, as is running AOO without administrative privileges. Another workaround for documents of unknown provenance includes a recommendation to use competing office suites:

For .ODP and .OTP files from unknown or suspicious sources, any automatic closing on opening or failing of OpenOffice Impress can be checked by opening the file in an OpenDocument Presentation application that is not vulnerable to the defective document formatting involved in CVE-2016-1513. Current releases of LibreOffice and Microsoft Office PowerPoint (for .ODP files), including PowerPoint Online, are known to avoid the defect.

Just after the advisory was published, Dennis E. Hamilton posted a note to the AOO development mailing list announcing the vulnerability and an effort to test some "hot fix" binaries that would fix the problem. Hamilton is the chair of the AOO project management committee (PMC) and he was looking for more users to help test the fix:

In addition, the Apache OpenOffice security team has developed candidate "hot fix" binaries. These are single shared-library files that can be manually installed by users in place of the same file in the program directory of their Apache OpenOffice 4.1.2 installation. There are two crucial concerns for the eventual release of a hotfix in this manner. First, we must have more testing of the hotfix substitution to ensure that there is no regression of any kind. Secondly, the introduction of a hotfix is something that casual users must be able to perform with confidence and reliability. For that, we need to ensure that the procedures provided are complete and reliable (and that users have a way to recover from any misstep). So we also require community assistance in reviewing, applying, and revising the procedure.

A few days later, PMC member Andrea Pescetti posted a follow-up with an outline of the steps to take to address the vulnerability. "I assume we will want to keep the effort minimal", he said. Notably absent from his outline is making a full binary release of AOO with the updated code in the near term, or really any provisions for regular users, though he did expect to get to that eventually:

Once this is done, we will probably want to open another discussion and see how we can coordinate for a release that incorporates more fixes or features and is made available in full form, with all localized installers, to end users. But the above is mostly aimed in having an official way to ship the existing patch.

For now, he suggested simply applying the patch to the 4.1 branch and making a 4.1.2.1 source release, as well as providing "repaired libraries for power users". The new version of the libraries would still be marked as version 4.1.2. That would not give users or administrators a way to tell whether an AOO installation was vulnerable, however, which concerned Don Lewis: "Not being able to tell at a glance whether a copy of AOO has been fixed or not is bad."

Lewis suggested making the hash of the library available, so that the different versions could be distinguished. That would not work for anyone who built the library from source, though. He also suggested adding a static string (e.g. "CVE-2016-1513 Fixed") to the library so that tools like strings could be used to make the distinction between the versions.

Unfortunately, changing the library would invalidate some the testing that had already been done with the binary hot fix, as Hamilton noted. He suggested that a combination of file size and creation date (coupled with the hash of the new library) would be enough to indicate updated versions. Lewis agreed with that plan.

So far, though, the new binaries have not been released, so users are left either building their own or using other tools to avoid the flaw. One of the more surprising things, perhaps, is that there is no established procedure to quickly produce an updated version in the presence of a security vulnerability. This not the first time that the project has struggled to get out a release for a security vulnerability, so it would seem that being a bit better prepared would be in order.

That is especially true when considering that a recent report shows 600,000-850,000 AOO downloads per week. That's an awful lot of potentially vulnerable software being installed weekly, which makes prompt security updates all that much more important.

Even if this particular vulnerability is hard or impossible to exploit, that may well not be true for the (inevitable) next vulnerability. If a project cannot keep up with its vulnerabilities—especially for a program that often deals with untrusted, complex input like document files—it is likely doing its users an extreme disservice by trying to keep up appearances. It seems clear that AOO needs more developers, builders, testers, and so on, so that it can get out security updates (at least) in a timely fashion. In the meantime, though, users should probably strongly consider moving on from the project.