Dear reader,
I am not sure if I am contacting through the right email address but someone
said I should e-mail you guys.
I found an RCE functionality in the Apache UNO API which could give an attacker
control over a machine, or use a machine already compromised in the network to
exfiltrate data, etc.
The company that posted this issue on their blog is the company I did my
internship. Copy-paste from the advisory on there:
[START OF ADVISORY]
CVE reference: not yet assigned (see below)
CVSS score: 9.8 (critical)
CVSS vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected systems
Apache OpenOffice, all recent versions including current version 4.1.6, all
platforms
LibreOffice, all recent versions including current version 6.2.0 / 6.1.5,
all platforms
We don't know when the vulnerable API was introduced. Code for it seems to be 5
years old, judging from timestamps.
Note that normal use of OpenOffice or LibreOffice as a "client" does not expose
this vulnerability. OpenOffice/LibreOffice must explicitly be told to run as an
"office server" and to listen on a network port for it to expose this API call.
Overview
The Apache UNO API is exposed to the network if OpenOffice or LibreOffice is
run as an "office server" using a command such as this:
soffice --accept='socket,host=0.0.0.0,port=2002;urp;StarOffice.Service'
The API contains a call named XSystemShellExecute which will execute an
arbitrary command sent to it as a parameter. No authentication is required,
only knowledge of the protocol.
Details (without Proof-of-Concept code for now) is available in Axel's blog
post.
Impact
The impact of this issue can be severe. Any user account used to launch
OpenOffice or LibreOffice in office server mode can be compromised with
relative ease.
There are two mitigating factors:
The "office server" mode is rarely used
Although examples tend to use port numbers just above 2000, there is no
default port number, so scanning for this issue is not trivial.
Solution
Unfortunately, after five months of trying, we have not been able to convince
the Apache Security Team that this is, in fact, a security issue. So there is
no patch.
This is also why there is no CVE number. Apache assigns their own CVE numbers
(they are a "CNA", a "CVE Numbering Authority", themselves), and they are not
recognising this as a security issue.
We can only recommend, if using OpenOffice or LibreOffice in server mode is
absolutely necessary, to use a firewall (possibly host-based) to limit which
systems can connect to the API, and to run it in a container using a
low-priviliged user account.
We have also made available a Snort rule to detect the use of this API call on
your network:
alert tcp any any -> any any (msg: "Apache API XSystemShellExecute Detected";
content:"com.sun.star.system.XSystemShellExecute"; flow:to_server; sid:31337;
rev:1)
Technical details
See Axel's excellent blog post for many more details of this issue.
Responsible disclosure timeline
18-Sep-2018: RCE disclosed to Apache Security Team
06-Dec-2018: E-mailed Apache to ask about the status of investigation
11-Dec-2018: Apache said they are aiming for a new release in January,
asking us to postpone the disclosure of the RCE until 31-Jan-2019
18-Dec-2018: New OpenOffice release (4.1.6) without a fix for this issue or
any communications from Apache
25-Jan-2019: E-mailed Apache to ask about the status of investigation
05-Feb-2019: Received e-mail from Apache that they don't consider this to
be a security issue because the configuration is so uncommon, but are willing
to work together to fix this in OpenOffice 4.1.7
07-Feb-2019: E-mailed Apache to confirm that we're willing to work with
them on this issue
22-Feb-2019: E-mailed Apache to let them know we're planning to release
27-Feb-2019: Release of this post and advisory
Vendor advisory
None as yet.
[END OF ADVISORY]
Advisory: https://hackdefense.com/blog/security-advisory-rce-in-apache-uno-api/
Write-up:
https://hackdefense.com/blog/finding-RCE-capabilities-in-the-apache-uno-api/
Feel free to message me for more information about the proof of concept code.
With kind regards,
Axel Boesenach
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
