XStream deserialization vulnerability - Sonatype patch

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

XStream deserialization vulnerability - Sonatype patch

Richard Seddon

Just thought I'd let you know that we released a patched version of XStream to address the vulnerability our use of XStream deserialization caused in Sonatype Nexus.

The code can be found here:

https://github.com/sonatype/xstream-whitelist

This code is designed specifically for use in Nexus, it isn't intended as for use in other projects.

A high level overview of it is here (this link is for end users, so is simplified a lot):

https://sonatype.zendesk.com/entries/37551958-Configuring-Xstream-Whitelist

If any of the code in the github repo is of use to you please feel free to take it.

Regards,

Rich




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: XStream deserialization vulnerability - Sonatype patch

Jörg Schaible-2
Hi Rich,

Richard Seddon wrote:

>
> Just thought I'd let you know that we released a patched version of
> XStream to address the vulnerability our use of XStream deserialization
> caused in Sonatype Nexus.
>
> The code can be found here:
>
> https://github.com/sonatype/xstream-whitelist
>
> This code is designed specifically for use in Nexus, it isn't intended as
> for use in other projects.
>
> A high level overview of it is here (this link is for end users, so is
> simplified a lot):
>
> https://sonatype.zendesk.com/entries/37551958-Configuring-Xstream-Whitelist
>
> If any of the code in the github repo is of use to you please feel free to
> take it.

Well, normally I am happy, if someone contributes code, but here I wonder,
why suddenly an alternate implementation is presented to the existing one,
without further notice before, that you want to work on the stuff or which
requirements were not met with the existing code.

You implemented actually a slightly different approach than that what we
have in trunk. We have similar possibilities to allow/deny types.
Configuration will follow our standard pattern using the XStream facade.
Documentation is not finished and trunk has to be merged into the 1.4.x
branch, but that's done as soon as possible.

Regards,
Jörg


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: XStream deserialization vulnerability - Sonatype patch

Richard Seddon
Hi  Jörg,

In Nexus our use of xstream deserialization resulted in a vulnerability which allowed remote execution of arbitrary binaries on the server for some versions of Nexus.

Given the severity of this vulnerability we felt that we needed to have a fix in place immediately for our customers at the time we made this public.

Consequentially we felt that we couldn't go through the normal process, which would be to work with you directly.

None of us were happy about this, but we felt there was no alternative.  

I do apologize though, I can certainly understand your feelings on this matter.

Regards,

Rich
On Jan 14, 2014, at 5:53 PM, Jörg Schaible <[hidden email]> wrote:

> Hi Rich,
>
> Richard Seddon wrote:
>
>>
>> Just thought I'd let you know that we released a patched version of
>> XStream to address the vulnerability our use of XStream deserialization
>> caused in Sonatype Nexus.
>>
>> The code can be found here:
>>
>> https://github.com/sonatype/xstream-whitelist
>>
>> This code is designed specifically for use in Nexus, it isn't intended as
>> for use in other projects.
>>
>> A high level overview of it is here (this link is for end users, so is
>> simplified a lot):
>>
>> https://sonatype.zendesk.com/entries/37551958-Configuring-Xstream-Whitelist
>>
>> If any of the code in the github repo is of use to you please feel free to
>> take it.
>
> Well, normally I am happy, if someone contributes code, but here I wonder,
> why suddenly an alternate implementation is presented to the existing one,
> without further notice before, that you want to work on the stuff or which
> requirements were not met with the existing code.
>
> You implemented actually a slightly different approach than that what we
> have in trunk. We have similar possibilities to allow/deny types.
> Configuration will follow our standard pattern using the XStream facade.
> Documentation is not finished and trunk has to be merged into the 1.4.x
> branch, but that's done as soon as possible.
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: XStream deserialization vulnerability - Sonatype patch

Brian Fox
In reply to this post by Richard Seddon
 Well, normally I am happy, if someone contributes code, but here I wonder, why suddenly an alternate implementation is presented to the existing one, without further notice before, that you want to work on the stuff or which requirements were not met with the existing code.
You implemented actually a slightly different approach than that what we have in trunk. We have similar possibilities to allow/deny types. Configuration will follow our standard pattern using the XStream facade. Documentation is not finished and trunk has to be merged into the 1.4.x branch, but that's done as soon as possible.  

Hi Jorg,

I wanted to provide a little more color on Rich's email. We evaluated several different ways to patch this issue, including changes to Nexus and Nexus' Restlet Bridge module. In the end, due simply to the fact that of all the 2.x versions of Nexus, the version of xstream had the least variation, we opted to build a patch there. This allowed us to have a single patch that fixed all 2.x versions of Nexus, instead of several different Restlet Bridge patches and/or a whole bunch of Nexus patches. 

Obviously due to the nature of the vulnerability we needed to find a way to patch the issue internally which precluded a more open collaborative approach that would have been preferred.

We wanted to post this code as a heads up in case it is useful to the project or as inspiration to other users, but it was never the intention or expectation that this was going to solve a more generic issue for others as a patch to be consumed directly into xstream since we were aware that your team was already implementing a similar solution.

I hope that helps.

--Brian
Reply | Threaded
Open this post in threaded view
|

Re: XStream deserialization vulnerability - Sonatype patch

David Jorm
In reply to this post by Richard Seddon
On 01/15/2014 08:13 AM, Richard Seddon wrote:

> Just thought I'd let you know that we released a patched version of XStream to address the vulnerability our use of XStream deserialization caused in Sonatype Nexus.
>
> The code can be found here:
>
> https://github.com/sonatype/xstream-whitelist
>
> This code is designed specifically for use in Nexus, it isn't intended as for use in other projects.
>
> A high level overview of it is here (this link is for end users, so is simplified a lot):
>
> https://sonatype.zendesk.com/entries/37551958-Configuring-Xstream-Whitelist
>
> If any of the code in the github repo is of use to you please feel free to take it.
>
> Regards,
>
> Rich
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>

Thanks for the heads up, Rich. I'm just a bit confused as to whether it
is the correct thing moving forward for Nexus to use a different CVE ID
than XStream itself. MITRE assigned CVE-2013-7285 to this issue in XStream:

http://www.openwall.com/lists/oss-security/2014/01/10/1

It would make sense for Nexus to have its own CVE ID if the Nexus patch
was made to code independent of XStream, but it looks like the patch has
been made directly to the XStream library, and as discussed in this
thread, is basically an alternative implementation to XStream's own
patch for CVE-2013-7285. Based on my understanding of the CVE assignment
rules, the Nexus flaw should also be identified by CVE-2013-7285, but I
could be wrong. I absolutely understand why Nexus assigned a CVE ID
independently for this flaw, but I think it is a duplicate of
CVE-2013-7285. I have copied cve@mitre on this message for their input.

Thanks
David

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

    http://xircles.codehaus.org/manage_email