Knowledge Base/Sonatype Nexus/Troubleshooting

Configuring XStream Whitelist

Rich Seddon
posted this on January 7, 2014, 16:47

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

 

Comments

User photo
NGSA Vanguard
Vanguard

A reference to NEXUS-6102 and a statement that the user might get a message if there is a magic.mime entry containing ">>&1" should be added along with any action that should be taken.

January 14, 2014, 10:09