New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential remote code execution via dozer's reflection-based type conversion #217

Open
dfj opened this Issue Dec 5, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@dfj

dfj commented Dec 5, 2014

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. security@apache.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

@dfj

This comment has been minimized.

Show comment
Hide comment
@dfj

dfj Dec 14, 2014

I now have a working exploit achieving RCE if a vulnerable copy of Spring exists on the server classpath; see the github link above.

dfj commented Dec 14, 2014

I now have a working exploit achieving RCE if a vulnerable copy of Spring exists on the server classpath; see the github link above.

@garethahealy

This comment has been minimized.

Show comment
Hide comment
@garethahealy

garethahealy Apr 5, 2017

Collaborator

@dfj ; can you please provide more info, i.e.: how you would expect to remedy this issue.

Collaborator

garethahealy commented Apr 5, 2017

@dfj ; can you please provide more info, i.e.: how you would expect to remedy this issue.

@normuk

This comment has been minimized.

Show comment
Hide comment
@normuk

normuk May 12, 2017

I can't help too much, but there is a discussion on an xstream fix here.

http://xstream.10960.n7.nabble.com/Security-Guidance-to-use-XStream-safely-td8614.html

It had a similar issue.

normuk commented May 12, 2017

I can't help too much, but there is a discussion on an xstream fix here.

http://xstream.10960.n7.nabble.com/Security-Guidance-to-use-XStream-safely-td8614.html

It had a similar issue.

@hoomanb1

This comment has been minimized.

Show comment
Hide comment
@hoomanb1

hoomanb1 Jan 5, 2018

@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?

hoomanb1 commented Jan 5, 2018

@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?

@hoomanb1

This comment has been minimized.

Show comment
Hide comment
@hoomanb1

hoomanb1 Jan 11, 2018

I had a closer look at the poc and I think the serialization/deserialization of dynamic proxy is a little confusing as it does not seem to be related to dozer. If the malicious dynamic proxy object however, gets passed to mapper.map(..) it'll be executed, true.

hoomanb1 commented Jan 11, 2018

I had a closer look at the poc and I think the serialization/deserialization of dynamic proxy is a little confusing as it does not seem to be related to dozer. If the malicious dynamic proxy object however, gets passed to mapper.map(..) it'll be executed, true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment