Hi David, David Jorm wrote:
>> Hello, >> >> the XStream project is pleased to announce the release of XStream 1.4.7. >> >> The release is primarily a security release to address CVE-2013-7285. >> XStream will no longer handle any java.bean.EventHandler instance as >> immediate consequence. If you know what you do, you may still register >> the ReflectionConverter for this type. Unless you unmarshal such objects, >> XStream 1.4.7 is meant as drop-in replacement. >> >> XStream contains now on top of this a security framework, where you can >> fine- control any type that is permitted by XStream to unmarshall. All >> security related aspects are described in this new documentation: >> >> http://xstream.codehaus.org/security.html >> >> Check it out yourself: >> >> http://xstream.codehaus.org/downloads.html >> >> Enjoy, >> XStream Committers > > Thanks very much for shipping this release! > > I am currently working on backporting patches to older versions of XStream > that ship in Red Hat products. The oldest is XStream 1.3.1, and I am > unable to reproduce an exploit of this issue on 1.3.1. When using a PoC > exploit based on the details published by Dinis Cruz (I won't attach it as > that would only encourage usage by unskilled attackers), it works against > XStream 1.4.x, but not 1.3.1. I had to modify the exploit XML in two ways > to make it compatible with 1.3.1: > > 1) Use <tree-set> rather than <sorted-set> due to: > http://jira.codehaus.org/browse/XSTR-573 > > 2) Add a <no-comparator> element due to: > http://jira.codehaus.org/browse/XSTR-576 > > Even with these changes, instead of executing the process defined by the > EventHandler in the XML, I get: > > com.thoughtworks.xstream.converters.ConversionException: Cannot construct > java.beans.EventHandler as it does not have a no-args constructor : Cannot > construct java.beans.EventHandler as it does not have a no-args > constructor ---- Debugging information ---- > message : Cannot construct java.beans.EventHandler as it does > not have a no-args constructor > cause-exception : > com.thoughtworks.xstream.converters.reflection.ObjectAccessException > cause-message : Cannot construct java.beans.EventHandler as it does > not have a no-args constructor > class : java.util.TreeSet > required-type : java.beans.EventHandler > path : /tree-set/dynamic-proxy/handler > ------------------------------- > > This leads me to question whether XStream <= 1.3.1 is actually affected by > this issue. At this point, I must profess ignorance. I know very little > about XStream, I only really started looking at it in order to address > this security issue. Can any of the developers provide any input? Is 1.3.1 > missing a feature that is necessary to exploit this issue? Or does the > exploit just require further modification? > > Please feel free to reply to me directly if 1.3.1 is exploitable and you > don't want to publicly circulate details regarding exploitation. I will > handle any information given in private as strictly confidential. XStream 1.3.1 does nothing know about Oracle as Java vendor, so it uses the PureJavaReflectionProvider as fallback which requires a default constructor in return. Simply use an old Java 6 or directly Java 5 and you'll see that the exploit "works"... or provide a Sun14ReflectionProvider instance as constructor argument to XStream. Even 0.x versions of XStream have a DynamicProxyConverter, a ReflectionConverter and a Sun14ReflectionProvider and might potentially be affected. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
