Skip to main content

Configuring XStream Whitelist

Rich Seddon
Updated

Visit my.sonatype.com for documentation on Nexus Repository version 2.

Important Security Advisory
Due to CVE-2014-0792, Sonatype Nexus 2.7.1 and greater now ships with a modified version of the XStream library. Older Nexus versions should be upgraded or patched immediately. 

Symptoms You Need to Configure XStream Whitelist

In order to apply the instructions in this article, your Sonatype Nexus Repository 2 instance must be version 2.7.1 or greater, or be another Nexus 2.x version that is patched with a Sonatype modified XStream library.

The nexus.log file should contain one or more messages at WARN level from the com.thoughtworks.xstream.whitelist.TypeWhitelist  logger  with a message of the form:

Type NOT allowed: <type>

Explanation

The Sonatype modified XStream library restricts unmarshalling of Object types to those known to be safe. The list of allowed types is known as the "xstream white list". This white list is constructed using a combination pre-allowed packages, classes, and regular expressions, and (optionally) user contributions to the white list. Configuration of the XStream object via standard mechanisms (aliases, annotations, etc.) will also add to the white list.

If you are using third party Nexus Repository 2 plugins (not authored by Sonatype) which require XStream unmarshalling you may find that these plugins can no longer unmarshal request payloads into Java Objects.

Resolving Unmarshalling Problems

Should unmarshalling errors occur in your custom nexus plugins, you must determine which classes need to be added to the XStream white list. 

Look in the nexus.log file for Type NOT allowed: messages. The message should include information about the Object type attempting to be unmarshalled.

Once you have identified the types causing problems, verify that the request to unmarshal this type is a legitimate request. We advise contacting the plugin author for direct clarification.

Once the type is confirmed, edit $NEXUS_HOME/conf/nexus.properties ( for example nexus-professional-2.7.1-01/conf/nexus.properties ), using the below examples as a guide.

Example: Configuring a list of allowed types

# A comma delimited set of fully qualified class names.  Inner classes may be specified using "$"
com.thoughtworks.xstream.whitelist.TypeWhitelist.allowedTypes=org.some.plugin.SomeClass,org.some.plugin.An$InnerClass

Example: Configuring entire packages of types

# A comma delimited set of Java packages. Note that sub-packages are not automatically included, "a.b.c" does not allow "a.b.c.d":
com.thoughtworks.xstream.whitelist.TypeWhitelist.allowedPackages=org.some.package,org.some.other.package

To apply changes to nexus.properties a restart is required.

Attention: Third-Party Plugin Authors

The information in this section is intended for authors of Nexus plugins.

Types are automatically white-listed when they are configured via xstream:

  • type aliases
  • class aliases
  • field aliases (allows class field defined-in)
  • package aliases (allows package)
  • default implementations (type and impl)
  • attributes
  • local converters (defined-in type type)
  • immutable types
  • types explicitly processed for annotations

For example:

xstream.alias("my-type", com.myco.MyType.class);

This will automatically white-list the "com.myco.MyType" type.

Users that otherwise have no configuration can allow their types by processing each type for annotations (even if these types do not have any annotations):

xstream.processAnnotations(new Class[] { MyType1.class, MyType2.class });

java.lang.reflect Support Disabled

Support for java.lang.reflect types (java-class, method, constructor, field and dynamic-proxy) are disabled by default in Sonatype's patched xstream code.

Related articles