> 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. Thanks -- David Jorm / Red Hat Security Response Team --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
