CVE ID for XStream deserialization security issue

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CVE ID for XStream deserialization security issue

David Jorm
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.

Thanks
--
David Jorm / Red Hat Security Response Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: CVE ID for XStream deserialization security issue

Jörg Schaible-2
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


Reply | Threaded
Open this post in threaded view
|

Re: CVE ID for XStream deserialization security issue

David Jorm
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


Reply | Threaded
Open this post in threaded view
|

Re: CVE ID for XStream deserialization security issue

Dinis Cruz

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" <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Re: CVE ID for XStream deserialization security issue

Jörg Schaible-2
In reply to this post by Jörg Schaible-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Re: CVE ID for XStream deserialization security issue

David Jorm
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