I'm not 100% sure how, but in order to feel "safe" for this use-case, I'd want to be able to constrain XStream to deserialize certain packages only. A guard if you will that'd fast fail. If packages are not sealed, then I'd want to constrain to a code-source. I'm sure there's a way of participating in the instantiation of classes, that allows for a just in time veto of that instantiation. Whether that's as clean as a purpose-built guard interface, isn't clear.
Full disclosure: I've not read the article. - Paul On Sun, Dec 22, 2013 at 7:12 AM, Dinis Cruz <[email protected]> wrote: > Hi, I wrote this blog post XStream "Remote Code Execution" exploit on > code from "Standard way to serialize and deserialize Objects with XStream" > article<http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html> > which > is based on the research that Alvaro mentioned in his Is it possible to > unregister the DynamicProxyConverter using the SpringOXM > wrapper<https://www.mail-archive.com/[email protected]/msg00602.html> > post > here. > > As you can see on my blog, at the moment the users of XStream are not > really aware of the problems that can occur when untrusted (i.e. > potentially maliciously controlled) XML data is fed to XStream > *fromXml*function. Which is specially problematic when APIs are used that > wrap the > use of XStream and hide its use. > > You can also read that I'm currently not 100% sure on the best way to > mitigate this issue and what should be the advise to give developers (and > pentesters/code-reviewers) in order for them to detect and fix their > applications. > > So my question is: *What are the best practices and Security Guidance to > use XStream safely?* > > Note that although the Remote-code-execution PoC that I presented is good > for demos (and to raise the awareness of the issue), I think that in most > real-world apps (with large codebases) there will be other massive security > vulnerabilities if XStream is allowed to create any class currently > available in the class path (for example in a banking app, it might be > possible to create transactions objects and other business sensitive > actions (the exploit will depend on the capabilities of the target > application)). > > Thanks > > Dinis Cruz >
