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:

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:

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:

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.