Hi (sorry for not being very active on these threads but I've been super busy with work related projects)
Another area to look at are applications that use XStream as part of their APIs who might not take these mitigations into account and leave their users in a vulnerable/exploitable state (or they could be using an older version of XStream) Dinis Cruz On 9 Jan 2014 06:03, "David Jorm" <[email protected]> wrote: > On 01/08/2014 05:13 AM, Jörg Schaible wrote: > >> Hi David, >> >> David Jorm wrote: >> >> Hi All >>> >>> I am the security response manager for Red Hat's middleware products, >>> many of which ship XStream. I've been following the discussion in the >>> "Security Guidance to use XStream safely" thread, trying to determine >>> whether the fix for this issue is going to be in XStream itself, or >>> whether each application using XStream would be considered independently >>> vulnerable if it was passing arbitrary user-supplied content to XStream. >>> Based on the discussion on this list, it sounds like a fix is going to >>> be possible in XStream itself, based on one of the two options Joe >>> Walnes outlined. I would like to request that a CVE ID be assigned to >>> this flaw, with the resolution to that CVE ID mapped to the version of >>> XStream which introduces the fix. Before requesting a CVE ID on the >>> oss-security list, I wanted to confirm that the XStream developer >>> community is happy to say that XStream will ship a fix, and not simply >>> document the issue and defer to users of XStream to fix their individual >>> applications. If that was the case, assigning a CVE ID for XStream >>> itself would probably not be the right approach. >>> >>> Please let me know if it is appropriate for me to go ahead and request >>> assignment of a CVE ID. >>> >> As you might have seen from the discussion, there's no general solution >> for >> all cases. We have the following situations: >> >> 1/ Known exploit by injecting an EventHandler instance >> >> This case is handled in trunk and branch and will be part of the next >> release 1.4.7. >> >> 2/ Prevent injection of directly harmful instances >> >> As there might be another harmful combination of instances based on well >> known and common 3rd party libs as CGLIB or ASM, we can introduce some >> kind >> of rules for the allowed types. Since it is not possible to provide a >> default that matches the types of the user's object domain, XStream has to >> be configured by code, i.e. such a new XStream version is no longer a >> simple >> drop-in replacement. Therefore we cannot activate such an security mode in >> 1.4.x by default, that has to be 1.5.0. However, it is possible to provide >> the possibility for 1.4.7 if a customer is willing to activate this >> feature >> in his own code. For 1.5.0 he will have to though. >> >> 3/ Injection of indirectly harmful instances >> >> This one cannot be handled by XStream directly. E.g. if an application >> reads >> (and expects) a list of String instances and someone injects an Integer >> into >> the list, the application might crash somewhere later on. The only >> prevention is to create a schema, use a validating parser for XStream and >> setup XStream to read and write schema compliant XML. This does already >> work, but is effort. >> >> The question is now, what situation do you intent to describe in the CVE? >> >> Cheers, >> Jörg >> > > My apologies for the delayed reply. I propose that the CVE ID describes > the security problem in general, and that situation #2 is what is > considered to be the resolution to the CVE ID. As Joe has proposed: > > "Since I already proposed an upcoming 1.5.0 to require Java 6 and 1.4.x to > stay compatible, the best compromise is to turn whitelisting on for 1.5.x > and port the mechanism back into the 1.4.x branch, without activating it by > default. Since the code base is currently not yet really different, it > should be easy." > > So both the 1.5.0 release and the 1.4.x update that provides the > whitelisting option would be considered to resolve the issue. Please let me > know if you're happy with that, and if so I will go ahead and request the > CVE ID. > > Thanks > David > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
