-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
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: >>> https://svn.apache.org/viewvc?view=revision&revision=1731216 >> >>>> 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 application. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkg0a4ACgkQHPApP6U8 pFg20g/9G7hHrLSaPFF7jhZ/LLhbOHhf8c1eCttSDQx8FoUDmH/zzeYjUKDCKsvu XceUeOhSGL42NqCfUffztttt/jo3+LObFYBxDjrx0PA5pIatJi/1ISh85W2CcbP/ OcNHPM9QIzGeXJ3mxXFodDiZQYesZXtysqwI7YapdqUujNaWOiy15pJMSN5M/ij4 bUJuzeUnwcsJ5xRn6Lsnqf/4Nq8N7nbzQVzE2tX/evmn9p2BBdvpcMoyyHB+V9hx IUb9hHMtoOQrFOZTQ/noQ6h7CI+fiyQm5RCH08Eq4ZMJ662K521E00dyBQpxNGxq D7u8yHnc7WpOjXx7Mf+ECVDeHlVGkE7Q4skBYbdxkUjCUhTmjvvYFiCEI7aFymF6 kd5YAvr2IxsfBGPyyAD5eeBoKrKLUE+GeT+jikGjWKxgbD/jwRMwJw8E9xaO7P6T SmzR4FMySdmGKXuTozCDjS0IKiHrT567DDBg3yZ5QLX8qKMByxVbCJ88VBlTj3Xy +wGrlApX/C0BMmsY+5uIS/wZqzA8u6uqkfIhas7+th9CbrBsJq1FZfvgZLUROw0M jQGsUHiclE2PmrALFeGV/pqzpKX1BvxeIMcDspd8HpJxQAcKSOFCSKUtNZ5skG2f EVopsN97eNgeqV6ZaLHqzsJTqhFEFfvOoJ7B2syvTCHqcDUuMOk= =fzQH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
