Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Potential remote code execution via dozer's reflection-based type conversion #217
Dozer uses a reflection-based approach to type conversion. If dozer is used to map attacker-supplied object instances, then the attacker can provide a dynamic proxy that implements an interface matching what dozer expects, but then use an event handler to execute all methods in that interface. As soon as dozer tries to execute any getter/setter methods, they'll trigger the event handler. So if the attacker declares an event handler like:
EventHandler.create(Collection.class, new ProcessBuilder("/usr/bin/evince"), "start")
Evince will be run as soon as dozer tries to map that object.
The exploitable use case seems to be rather limited so far. There must either be an object being mapped to with a getter/setter method that matches a method in an interface on the server classpath, or a manual XML mapping that allows an attacker to force the issue. Apache Camel supports dozer, so this would be a feasible vector for processing attacker-supplied input. Camel may also allow an attacker to supply an XML mapping (I'm not sure if this is true or not), in which case this would be a pretty serious flaw (at least for Camel). There is, however, one remaining barrier to exploitation in a real-world scenario. How can an attacker provide a malicious proxy instance that survives serialization and deserialization, such that they could feasibly send it to a camel route (or other vulnerable endpoint)?
EventHandler is not serializable, and I couldn't easily find another InvocationHandler that was serializable and would permit this kind of attack. firstname.lastname@example.org has been notified of this issue and has never replied.
For more details, including a PoC exploit, please see: https://github.com/pentestingforfunandprofit/research/tree/master/dozer-rce
I can't help too much, but there is a discussion on an xstream fix here.
It had a similar issue.
@dfj , I'm not quite sure if this could be a dozer issue. As far as I understand this, the poc seems to leverages JDK's dynamic proxy to create a malicious proxy object using DefaultAopProxyFactory. So at runtime as soon as a proxy object for that particular instance is created (L#101) the payload gets executed. This process goes on anytime this proxy object gets passed to various code based and eventually reaches dozer's execution point at (L#138). Due to the nature of the Corgi object being an executable proxy, as soon as mapper.map(...) gets called, again the payload gets executed. From then, while the mapping is being performed I can't seem to be able to see any payload execution happening! Am I missing anything here?