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
