In any situation where untrusted input is deserialised, there is a risk that remote code execution attacks are made possible because an attacker can control the code and data that are deserialised and executed.

Exactly what attacks are possible depend on the classes available within the application at the point at which the deserialisation occurs.

In Java, a serializable class can define a method named readObject which can be used to perform special handling during deserialization. The following code is from DiskFileItem in commons-fileupload-1.3.1.jar, which is available on the class path set in Xen Mobile:

private void readObject(ObjectInputStream in)
        throws IOException, ClassNotFoundException
{
    in.defaultReadObject();
    // ...
        FileInputStream input = new FileInputStream(this.dfosFile);
        IOUtils.copy(input, output);
        this.dfosFile.delete();
        this.dfosFile = null;
    }

    output.close();
    this.cachedContent = null;
}

Accepting serialised raw objects from untrusted sources is unsafe and should be avoided across the codebase in favour of safe data formats. As we control the value passed into this method, and we control the values of the attributes in this class, we can write a file to a location of our choosing with content of our choosing.

As we have write privileges to the Tomcat web directory, we can use this vulnerability to upload a JSP file containing arbitrary code.

2018-03-28 – Reported to Citrix and acknowledged immediately

2018-05-21 – Citrix report that they do not consider this issue to be a vulnerability:

Citrix have acknowledged this issue but have not addressed it on the basis that it is already mitigated:

[This issue is] already mitigated by the internal firewall that limits access to configuration services to localhost.  Because these are already mitigated, we did not list them in the Citrix security bulletin.

We acknowledge that the firewall does prevent this issue from being exploited externally. However the issue nonetheless exists, making the service vulnerable to local attack, and potentially to remote attack in the case that another vulnerability is found that allows the firewall to be circumvented.

As such, we still consider the issue relevant.