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
Comments
|
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 ; can you please provide more info, i.e.: how you would expect to remedy this issue. |
|
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. |
|
@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? |
|
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. |
|
Is it planned to fix anything? |
|
Actually CVE-2014-9515 is related to an old version of springframework while this has been fixed in spring ages ago. The only issue regarding dozer is that it calls arbitrary getters on a given input object. However, this applies to all bean mapping frameworks with such generic design. So the also applies for orika and many others. Claiming this a reasonable security vulnerability in dozer is IMHO unprofessional. You could also construct a dynamic proxy object that does something evil when the |
|
I'm doing a review of dozer usage in my organization and our composition analysis tools flag dozer for CVE-2014-9515. If I understand correctly, the justification being given here is that attacker (user) controlled objects should not be passed to mapper.map? However, I don't see any warnings in the documentation, or guidelines for performing secure code reviews of software using dozer. Such warnings would be insufficient, but would indicate to me that dozer developers were concerned with their user's security. From a security perspective, I'd be inclined to ask teams to simply not use dozer or other mapping tools and write their own setters/getters if this isn't addressed somehow. Convenience and security are always at odds. |
|
@dfj @Markimedes what is the mitigation you suggest to implement? This got flagged for me also while doing composition analysis |
|
I am not quite sure if this issue is an actual issue based on the answers here... Could the maintainer please clarify this? Thanks :) |
As far as I understand, the issue here is not Dozer's fault, but just the way reflection works. hohwille's comment is perfectly reasonable. I don't see why it would need a separate warning for it - it's just the basics of reflection. This is only a vulnerability if you have another vulnerability in your system, which somehow lets a malicious object through - and the object exploits dozer's mappings to execute its code. The only way to foolproof against this is not to use reflection at all - for example, by using mapstruct for mappings - but marking a whole library with a critical security issue simply because it uses reflection is very weird. |
|
hihi I'm a security engineer who ended up here because this project got flagged by our dependency scanner. I've read through the discussion thread and it seems as though the consensus of the project maintainers is that the issue is not with Dozer inherently and that, as such, the issue will not be patched. May I ask that someone from the Dozer team contact the CVE-team at Mitre to initiate the dispute process? This way the CVE can get marked as 'vendor disputed' and thus will pop differently on everyone's vulnerability scan reports. The CVE team at Mitre can be reached via this form. ty!! |
|
@dholiday ; the project is not in an active state, I'd suggest you get your devs to migrate away from dozer to fix this warning. |
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
The text was updated successfully, but these errors were encountered: