Apache OpenOffice 4 (including 4.1.7, the latest version tested) is vulnerable to remote code execution; if a victim is convinced to open a crafted .odt document on Windows, attackers could gain full control over their computer.
The problem is, the product does not handle script:event-listener handlers as macro execution (like LibreOffice does). Using a construct like this:
<office:scripts>
<office:event-listeners>
<script:event-listener script:language="ooo:script"
xlink:href=".uno:OpenHyperlinkOnCursor" script:event-name="dom:load"/>
</office:event-listeners>
</office:scripts>
One can trigger opening URLs without any confirmation dialogs in OpenOffice, including special .uno or .service link handlers that were designed for internal use only.
PoC document uploaded, popping the calculator on Windows. UNC targets are also supported, in that case they're subject of the "mark of the web" security warning of the OS.
Triggering .uno or .service actions works on Linux as well - though I couldn't find a practical way to turn it into code execution on that OS.
Apache OpenOffice 4 versions before 4.1.8.
No. Even though Apache is an official CVE Numbering Authority, they didn't assign a CVE to this flaw. When asking for an ID, I was told they are about to use CVE-2018-16858, which is a Libreoffice specific, unrelated bug. They are different even in nature: path traversal (CWE-23) vs protection mechanism failure (CWE-693). In the follow up Apache claimed to reuse CVE-2019-9847 instead as they thought the issue was the same but their original fix was incomplete.
CVE-2019-9847 looks indeed much closer to the flaw I reported, but again, it is about Libreoffice. The behavior described there (clicking on links invokes executables without any additional user warning/prompt) is actually still true for OpenOffice, actually that is the reason why I started looking for simulating clicks without user interaction. I'm uncertain whether the fix of security issues among the office forks are ported or not, but CVE-2019-9847 was never remediated for OpenOffice.
Update: see time line.
Upgrade to Apache OpenOffice.
2020-04-28: report to security@openoffice.apache.org 2020-05-01: vulnerability acknowledged 2020-06-05: asking for updates 2020-09-05: asking for a timeline, offering embargo until October 2020-09-06: confirming there is no timeline for the fix 2020-10-01: full disclosure 2020-10-01: securityweek.com requests Apache for comments 2020-10-02: commitment made to fix the flaw and to release it within the next two weeks 2020-10-05: CVE-2020-13958 assigned 2020-11-10: Apache OpenOffice 4.1.8 released along with the fix