users@jersey.java.net

[Jersey] Re: Security scans of Jersey 1.17

From: Louis Crandell <crandell.louis_at_gmail.com>
Date: Fri, 11 Apr 2014 19:35:05 +0200

I believe this is not a concern of JAXB but rather of the parser the final
application will use.
Unfortunately the default is to allow DTD entity expansion. It's up to the
client to disable dtd expansion via an API or perhaps there's a system
property as well.
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing


On Fri, Apr 11, 2014 at 4:16 PM, Ivanov, Ivan <ivan.ivanov_at_sap.com> wrote:

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