users@jersey.java.net

[Jersey] Security scans of Jersey 1.17

From: Ivanov, Ivan <ivan.ivanov_at_sap.com>
Date: Fri, 11 Apr 2014 14:16:13 +0000

Hello!

I work for SAP and we are using Jersey in our tool. It's version 1.17 of the library. As part of the open source usage process, we run the tool Fortify from HP to scan all the code that we use. It caught some issues for Jersey, but most of them were classified by our security expert as bad practice or false positives. Now, there is a class of problems though, that I want to discuss with you. I would like to ask your opinion whether these can be treated as false positives, or maybe they are fixed in later version or if not, whether we can contribute a fix to the current development release.

Here is what Fortify found:

Abstract:
XML parser configured in JSONUnmarshallerImpl.java:77 does not prevent nor limit external entities resolution. This can expose the parser to an XML External Entities attack.

Explanation:
XML External Entities attacks benefit from an XML feature to build documents dynamically at the time of processing. An XML entity allows inclusion of data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote system. This behavior exposes the application to XML External Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.
The following XML document shows an example of an XXE attack.
<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

This example could crash the server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

And these are pieces of code where this issue manifests itself:

public class JSONUnmarshallerImpl extends BaseJSONUnmarshaller implements Unmarshaller {
                      public JSONUnmarshallerImpl(JAXBContext jaxbContext, JSONConfiguration jsonConfig) throws JAXBException {
                          super (jaxbContext, jsonConfig);
                      }

                      // Unmarshaller

                      public Object unmarshal(File file) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(file);
                      }

                      public Object unmarshal(InputStream inputStream) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(inputStream);
                      }

                      public Object unmarshal(Reader reader) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(reader);
                      }

                      public Object unmarshal(URL url) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(url);
                      }

                      public Object unmarshal(InputSource inputSource) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(inputSource);
                      }

                      public Object unmarshal(Node node) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(node);
                      }

                      public <T> JAXBElement<T> unmarshal(Node node, Class<T> type) throws JAXBException {
                          return this.jaxbUnmarshaller.unmarshal(node, type);
                      }

It's all the unmarshall method calls that are problematic. So, again, is this really a problem or Fortify was misled by the parameter name (entity)? I was told that this DTD entity resolving feature of the parser may be switched off. Do you see a possible contribution from our side that turns it down if for example a System property is set? Or maybe there is already such a property? I read something about -DentityExpansionLimit=1 and we have set that. Will this solve most of the possible DTD entity security attacks?

Thank you,
Ivan