tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 8.5: wrong classloader used during context startup?
Date Sat, 20 May 2017 23:30:57 GMT
Hash: SHA256


On 5/19/17 3:45 PM, Mark Thomas wrote:
> On 19/05/2017 15:25, Christopher Schultz wrote:
>> Mark,
>> On 5/18/17 1:01 PM, Mark Thomas wrote:
>>> On 17/05/2017 14:32, Michael Heinen wrote:
>>>> I am currently migrating a web app from Tomcat 7.0.73 to
>>>> 8.5.15. An embedded Tomcat is used on development systems.
>>>> The web-inf/lib folder of the application contains a jar with
>>>> a SAXParserFactory implementation. This SAXParserFactory is
>>>> now used with TC 8.5 by the WebXmlParser in order to parse
>>>> the web.xml (and fails unfortunately). The ServiceLoader
>>>> finds the jar because the ParallelWebappClassLoader is used
>>>> for the lookup.
>>>> TC 7.0.73 uses the sun.misc.Launcher$AppClassLoader and does 
>>>> therefore not use the jar under web-inf\lib. It creates the 
>>>> webXml Digester in the init() phase of the stanrardContext.
>>>> TC 8.5 does this in the startInternal() phase where the 
>>>> ParallelWebappClassLoader is instantiated and bound to the 
>>>> current thread.
>>>> Specifying "javax.xml.parsers.SAXParserFactory" as VM param 
>>>> solves the issue of course.
>>> I think this is the fix that triggered this: 
>>>> My question: Is this behaviour expected?
>>> It looks like an unintended side-effect of the change.
>>>> Should Tomcat use libraries of the web app for the startup of
>>>> a context, here for web-xml parsing?
>>> The change has been in place for over a year and this is the
>>> first problem we have seen. I'm curious, what exactly was the
>>> problem you saw?
>>> I'd probably lean towards fixing this on the grounds that you
>>> want to parsing of web.xml to be deterministic rather than
>>> dependent on what may, or may not, be included in the app.
>>> What do others think?
>> +1
>> Also, for an untrusted application (admittedly a minority use
>> case), having Tomcat parse the app-provided XML with an
>> application-provided XML parser might have security
>> implications.
> I don't believe it does in this case. The file being parsed is
> web.xml which is application provided anyway so any manipulation a
> malicious app could do via the parser could just be done directly
> in web.xml.

That's exactly my point: Tomcat is using an untrusted XML parser to
parse untrusted XML. If the XML parser is trusted, then parsing the
untrusted XML is safe(r).

Take for example XML billion laughs or external entity attacks. These
attacks are typically prevented through disabling external entities or
DTDs themselves.

If the XML parser is provided by the application, those capabilities
can be left enabled even if Tomcat attempts to disable them by setting
the proper properties on the parser.

If Tomcat (or the JVM) provides the XML parser, then those security
precautions can be relied upon to protect the JVM from such an

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message