icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

[R1] Oracle MySQL Enterprise Monitor Multiple Library readObject() Function Java Object Deserialization Remote Code Execution



Oracle MySQL Enterprise Monitor is vulnerable to several Java object deserialization attacks that result in remote code execution. While Oracle has addressed one of these vectors (Apache Commons Collections InvokerTransformer Class) in WebLogic Server (VulnDB 130288, CVE-2015-4852), no advisory or CPU has mentioned MySQL Enterprise Monitor being affected. In addition to the InvokerTransformer vector, the same type of attack can be conducted via the readObject() call in the implementation of Apache Commons FileUpload as well as their implementation of SpringFramework. This is the first product we've seen to actually be vulnerable to the SpringFramework vector (published by Chris Frohoff in ysoserial on 2015-01-28, VulnDB 130185, no CVE), so that was fun! All testing was performed against an installation on Windows 7, but exploitation can be trivially modified to work against Linux as well.

Exploit Vector

Oracle MySQL Enterprise Monitor offers an authenticated REST API. One of the URLs for this API is https://[target]:18443/v3/dataflow/0/0. This URL accepts HTTP POST requests with a content type of “application/octet-stream”. POSTing to this URL invokes the DataflowRouter.class post() function (part of the com.mysql.etools.springboard.rest package in mysql-etools-springboard- The post() function eventually leads to loading the payload of the HTTP POST request into an ObjectInputStream and calling readObject().

Apache Commons FileUpload Exploitation

Apache Commons FileUpload contains an object called DiskFileItem, which is normally harmless. However, the object can be modified after it is serialized to behave in ways that were not intended. Specifically we can modify DiskFileItem to:

  1. Create a new file anywhere the Java process has permission.
  2. Write anything we would like to that new file.
  3. We can also move (copy and delete) any file on the remote system that we have permission to.

There are two limitations though:

  1. We don’t control the filename. This is generated by DiskFileItem class as “upload_$uuid_$counter.tmp".
  2. Files are created using the File.createTempFile() interface. That means the lifetime of the file is totally dependent on the usage of deleteOnExit(), how long the JVM runs, and if it is moved after creation (If the move is done by the exploit then it will still be deleted. However, if the move is done by the InvokerTransformer exploit then it will not be deleted). It is our observation that files appear to last ~30 seconds when creating them via the DataFlowRouter interface, which is more than enough time for most nefarious purposes.

Apache Commons Collections Exploitation

There has been plenty said about using various Commons Collections Objects to invoke cmd.exe. We will not rehash it here, but simply point to the FoxGlove Security article for background. To verify this vulnerability, we created a serialized object that invokes the shell and creates the directory "cheese" in C:\Users\Public. Due to CVE abstraction for the Apache Commons Collections issue being tracked on a per-vendor basis, this vector will fall under CVE-2015-4852, and is somehow only the second Oracle product to be found vulnerable (?!). Despite that, Oracle issued a new CVE for this specific product being affected.

SpringFramework Exploitation

Although Chris Frohoff released proof of gaining shell access via SpringFramework Object deserialization back in early 2015, this technique has not gained the infamy that the Commons Collections techniques have. This is largely due to the fact that fairly new versions of spring-core and spring-beans are required (4.1.4.RELEASE), which many products don't use. Unfortunately, MySQL Enterprise Monitor has these libraries on its classpath.

Oracle has classified this as a High access complexity for exploitation, likely due to it relying on varying factors related to which library is present. However, a rather vanilla install of the product allows for trivial exploitation and just requires credentials. As such, we are classifying the access complexity as low.

Apache vs Vendors, Attributing Blame

We brought the FileUpload issue to Apache's attention and they do not see it as a vulnerability. In their response to us, they stated:

"Having reviewed your report we have concluded that it does not represent a valid vulnerability in Apache Commons File Upload. If an application deserializes data from an untrusted source without filtering and/or validation that is an application vulnerability not a vulnerability in the library a potential attacker might leverage."

Tenable argued that if an application intends to deserialize DiskFileItems then they are still vulnerable to the altered object and they could have files written anywhere on their server, which seems to cross the privilege boundaries intended by the library based on the code.

Based on our research, there is no warning about distrusting this object included in their library, or mentioning the potential for problems. It seems like there could be a few lines of code to prevent the unintended aspect of this (files written to arbitrary locations), while still maintaining the functionality of the library. In doing that, it would add a layer of protection for companies that implement the library (which many do, and we are finding vulnerable).

After another Apache person mentioned that "java.io.File is serializable, too .. And, I assume that an intruder who manages to have a DiskFileItem created and getInputStream() invoked on it, can just as well create a File (or a String), and invoke new File(Input|Output)Stream?" We reminded them that the act of deserializing a DiskFileItem can cause arbitrary files to be written to disk. The attacker does not need to invoke a new outputstream because DiskFileItem's readObject() function has already done that for him. This is not expected behavior as best we can tell. This is also not at all like deserializing a Java.io.File. That said, we respect Apache's stance on this and are contacting vendors that implement the Commons FileUpload library in a way that makes their software vulnerable.


Oracle has released a patch to address this issue, as part of the April, 2016 CPU.

Disclosure Timeline

2016-01-29 - Issues discovered to impact Oracle MySQL Enterprise Monitor
2016-02-04 - Submitted to ZDI for consideration, case bmartin006
2016-03-03 - ZDI declines submission
2016-03-25 - Reported to secalert_us@oracle.com
2016-03-25 - Oracle responds, will investigate
2016-03-31 - Oracle asks us to test the latest versions, assigns S0711261 for tracking. Free QA for them, yo?
2016-04-01 - Tenable doesn't have latest version, asks for copy so we can join their QA team.
2016-04-01 - Oracle checking on how to provide a copy. They really want us on their QA team...
2016-04-19 - Oracle patches the issue in the April 2016 CPU without notifying us
2016-04-20 - Oracle informs us the issue is patched, provides CVE
2016-04-25 - Oracle automated email notifies us CPU was issued.

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email advisories@tenable.com