On 23/05/17 19:09, Christopher Schultz wrote:
> Mark,
>
> 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).
No, it isn't.
If the XML parser has been provide by the application, then restricted
application privileges apply.
> 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.
No, it can't.
>> 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?
No. The issue was that it was container (actually JRE) provided so it
ran with container permissions.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
