On 01/09/2014 11:49 PM, Jörg Schaible wrote:
Hi David,
David Jorm 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.
No worries, I took my time too for the first 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.
That's what I proposed and implement currently. So, it's fine for me.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Thanks Jörg. MITRE has now assigned CVE-2013-7285 to this issue:
http://www.openwall.com/lists/oss-security/2014/01/09/15
David
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
