Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Oracle WebLogic Server Web Container Subcomponent Reflected PartItem File Manipulation Remote Code Execution



On July 21 2016, ZDI and Oracle did a coordinated release of CVE-2016-3499 / ZDI-16-444. ZDI’s advisory indicates that the "PartItem class in WebLogic FileUpload allows remote attackers to write arbitrary files via NULL byte ... when used in conjunction with a specific version of Oracle Java. It also allows the attacker to copy any file into a different location." For those familiar with the recent slue of Java deserialization attacks, this description sounds very similar to Apache Commons FileUpload’s DiskFileItem attacks CVE-2013-2186 (NULL byte attack) and CVE-2016-1000031 (creating, copying, and deleting files).

A quick analysis of WebLogic’s PartItem (found in WebLogic’s com.oracle.weblogic.servlet.jar) revealed that is was obviously based on the Apache's DiskFileItem code. They are both loose wrappers around a DeferredFileOutputStream and the readObject / writeObject functions are identical. What is most interesting though, is that Oracle only partially fixed CVE-2016-3499. Oracle added a check to the readObject function to look for a NULL byte in the repository string (this code was copy and pasted from DiskFileItem in FileUpload 1.3.2). Incidentally, the NULL byte File attack has been "fixed" since Java 7 update 40 which was released in September of 2013. Any occurrence of a NULL byte in a File() call causes an exception.

However, Oracle did not fix the ability for a remote unauthenticated attacker to create and delete files using serialized PartItem. This attack is fairly well known having both been published by Tenable and Ysoserial. We verified this testing against WebLogic with Java 8 update 102 installed.

Serializing a PartItem

It might not be obvious at first that PartItem is serializable at all. While PartItem is declared as "public class PartItem implements Serializable, Part" it contains a non-serializable class member called Multipart. If we simply try to serialize PartItem after constructing the Object then we will get a NotSerializeableException which may cause some researchers to give up. However, we can just use reflection to set Multipart to NULL right before we serialize the object. Here is the code used to create a serialized PartItem that, upon deserialization, will write a file to C:\Users\Public\ with the contents "Save the lobsters!":

Multipart mp = new Multipart(request, "do", 80, 80, 999999);
PartItem test = new PartItem(mp, null, "not", "eat", false, "lobsters");
Reflections.setFieldValue(test, "repository", new File("C:\\Users\\Public\\"));
Reflections.setFieldValue(test, "sizeThreshold", 1024);
Reflections.setFieldValue(test, "cachedContent" , new String("Save the lobsters!").getBytes());

Reflections.setFieldValue(test, "sizeThreshold", 0);
Reflections.setFieldValue(test, "multipart", null);

FileOutputStream fos = new FileOutputStream("/tmp/t.tmp");
ObjectOutputStream oos = new ObjectOutputStream(fos);
Tenable produced a proof of concept for Oracle that, like the above, will write a file to C:\Users\Public\ with the contents "Save the lobsters!". The PoC attacks through the WebLogic t3 interface on TCP port 7001 just like the original Breen attack.


Oracle has released a patch for this issue in the April 2017 CPU. Customers can authenticate to the portal and access it here.

Disclosure Timeline

2016-07-25 - Issue discovered
2016-08-12 - Submitted to ZDI for consideration, case bainesjr0010 opened
2016-09-21 - Pinged ZDI for status
2016-09-21 - ZDI acks ping and indicates they will "nudge" this case.
2016-10-25 - Pinged ZDI for status
2016-10-31 - ZDI acknowledges ping. Will "nudge" this case.
2016-11-04 - ZDI kindly declines the vuln
2016-11-04 - Vendor notified via secalert_us@oracle.com
2016-11-04 - Vendor acks submission
2016-11-07 - Vendor opens ticket S0795751 for tracking
2016-11-22 - Oracle automated status, "Under investigation / Being fixed in main codeline"
2016-12-21 - Oracle automated status, "Under investigation / Being fixed in main codeline"
2017-01-24 - Oracle automated status, "Issue fixed in main codeline, scheduled for a future CPU"
2017-02-24 - Oracle automated status, "Issue fixed in main codeline, scheduled for a future CPU"
2017-03-24 - Oracle automated status, "Issue fixed in main codeline, scheduled for a future CPU"
2017-04-14 - Oracle status, issue fixed in upcoming CPU, provides CVE assignment in advance
2017-04-18 - Oracle April 2017 CPU released

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