XenMobile includes a service listening on port 5001 within its firewall that accepts unauthenticated input. If this service is supplied with raw serialised Java objects, it deserialises them back into Java objects in memory, giving rise to a remote code execution vulnerability.
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 serialisable class can define a method named readObject
which can be used to perform special handling during deserialisation. The following code is from DiskFileItem
in commons-fileupload-1.3.1.jar
, which is available on the class path set in XenMobile:
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.
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.