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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
