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

[Jörg Schaible]

Hi Rich,

Post by 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.
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
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

[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

Post by Jörg Schaible
Hi Rich,

Post by 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.
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
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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Brian Fox]

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

[David Jorm]

Post by 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.
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.
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
---------------------------------------------------------------------
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 ***@mitre on this message for their input.

Thanks
David