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 Tue, 23 May 2017 18:09:37 GMT
Hash: SHA256


On 5/21/17 5:49 AM, Mark Thomas wrote:
> On 21/05/2017 00:30, Christopher Schultz wrote:
>> Mark,
>> On 5/19/17 3:45 PM, Mark Thomas wrote:
>>> On 19/05/2017 15:25, Christopher Schultz wrote:
>>>> 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).
> I disagree.
>> 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 application.
> The threat being considered here is malicious application code.
> The standard protection against malicious application code is
> running under a security manager. And even then, there are plenty
> of things an application can do to harm the server.
> while (true) { }
> being one of the simplest.
> What this quickly boils down to is 'Does placing malicious code in
> the XML parser enable an attacker to do something they could not
> otherwise do?' Does it enable them to bypass any of the security
> constraints imposed by the SecurityManager? I believe the answer to
> that question is no - hence I believe that using an XML parser
> provided by the application is not a security threat.

The reason I think it's a security threat is because, when Tomcat
calls the XML parser, the XML parser is being run with elevated
(Tomcat) privileges instead of with the privileges normally associated
with the application (that is, restricted privileges).

The billion laughs example was just an illustration. If running under
a SecurityManager, the application (usually) couldn't open the
/etc/passwd file, but if the app provides an XML parser
implementation, then it can get Tomcat to read that file for it...
again perhaps using XML entities.

A slightly more concrete example: <Context logEffectiveWebXml="true">;
the WEB-INF/web.xml file contains an entity reference to /etc/passwd;
Tomcat loads the web.xml file and replaces the entity with
/etc/passwd, then writes the effective web.xml to the logger. The
application presumably has access to its own logs (even after the
fact) and the application owner has read a file they ought not to have
access to.

> Keep in mind that this parser is only used for this application and
> is only used for web.xml (and fragments).
> If there was a single parser shared between all applications then
> this would be an issue. We'd have a memory leak as well as the
> potential for information disclosure across the web application
> boundary. We have had issues like that in the past (CVE-2009-0783)
> but this bug is not the same.
> Note that the previous XXE issues were possible partly because
> there was a single container level web.xml parser that executed
> with container permissions.

What do you mean by "single" here? Do you mean that the parser wasn't
being re-initialized (or, better yet, re-constructed) and so there may
have been some carry-over from a previous parse() call?

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


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

View raw message