Christopher, Thanks for your input. It was very helpful. This afternoon, my InfoSecurity technician who runs the Tripwire app believes Apache Tomcat vs 8.5.13 is being flagged for the CVE-2017-12617 vulnerability solely off of the version. Tripwire isn't trying to see if HTTP PUT is enabled. He is opening a false positive ticket with the Tripwire vendor to get more information on their check.
Thanks again, Mike -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, February 13, 2019 1:19 PM To: users@tomcat.apache.org Subject: [External] Re: Question regarding mitigating the CVE-2017-12617 vulnerability -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Michael, On 2/13/19 13:35, Adams, Michael wrote: > I currently am running Apache Tomcat 8.5.13.0 on Windows Server > 2012 R2 servers to support a NCR Aptra Vision application. A > Tripwire vulnerability scan showed the servers have the Apache > Tomcat CVE-2017-12617 Vulnerability. To mitigate I see I could > upgrade to Apache Tomcat 8.5.23 or later. Instead of upgrading to > 8.5.23 or later, I am wanting to 'turn off' HTTP PUT > functionality.> I have this simple question: Is it possible to > mitigate the vulnerability by just adding/setting the init-param > readonly param value to true for the DefaultServer in the Apache > TomCat instance ../conf/web.xml file? Or is Tomcat 8.5.23 or higher > required for Apache TomCat to properly process the DefaultServer's > setting when I set the readonly parameter to true? Yes and no. First of all, conf/web.xml should default to readonly=true and it would be a huge security vulnerability to set it to false. It is never safe to set readonly=false in conf/web.xml because it would affect all applications deployed that do not explicitly set the readonly flag for DefaultServlet... and most don't. Which brings me to the "no" part of the above. If an individual application specifies readonly=false in its web.xml file (found in WEBAPP/WEB-INF/web.xml), then the setting at the top-level will not disable PUT and DELETE requests. AFAIK, there is no way to completely disable it on the server, overriding the configuration of the deployed web applications. > The reason I ask is this: The Tripwire test still found the Tomcat > CVE-2017-12617 Vulnerability even after I did the following on the > Windoww Server 2012 R2 servers: Stopped Apache Tomcat intance, made > the configuration change to the ../conf/web.xml file shown below, > and re-started Apache Tomcat. I can think of two possible reasons: 1. One of your web applications is specifying readonly=false for the DefaultServlet. This would (a) be very uncommon if true and (b) usually means that the application *absolutely must* have it set up that way. It's an unusual configuration mistake to make... you really have to go out of your way to make this unsafe. 2. Your TripWire scan is checking the version number of the server and complaining about everything that could possibly be in it, rather than giving you a honest report of what vulnerabilities are actually exploitable in your environment. > The following should make the context read-only and HTTP commands > like PUT and DELETE to be rejected. <servlet> > <servlet-name>default</servlet-name> > <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-cl ass> > > <init-param> > <param-name>debug</param-name> <param-value>0</param-value> > </init-param> <init-param> <param-name>listings</param-name> > <param-value>false</param-value> </init-param> <init-param> > <param-name>readonly</param-name> <param-value>true</param-value> > </init-param> <load-on-startup>1</load-on-startup> </servlet> > > Your help in the following matter would be much appreciated. That should be fine, but it should also be the default and therefore unnecessary. Check each of the deployed web applications to see if they are defining the default servlet. You should be able to do a "FIND" on each of the app/WEB-INF/web.xml for DefaultServlet to see if anything is in there. If that doesn't show any re-definitions of the DefaultServlet, they it looks like a version bump is the only thing that will make TripWire happ y. Fortunately, upgrading Tomcat between point-releases should not be a very traumatic experience. If you'd like some help with that, just ask. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxkbaQACgkQHPApP6U8 pFjsjg//VMeNY7moedueSgNJv7TkPJ63EikCffigqe6Dr8w7ox0Tt54zgQtX34QM O8kE4IHAFzYMUZ9AiBL2gRDFpuwqPo1Tu40g3uPZ5I/jAdog6ihtg9b0X/5srGp3 rFnHwTSrzog1g2s4hKqiasFbN0SSdetB0uEl8UFJQNvOHLJfekfka4ohyGcRcgys RgCFHWEz9joIVs5TQj0b8gPNZ333Ku4Lz5Gh1UyLD/lYVTv/zvxwGglA4aQybLpH c7Lvfp5xCqIgxO6GRH3Hoj5KQnPfW5xDnNBbMETuO1SJbAQ5GE6/BAMGFy/LvC11 pr624x1Vv/kOAdUSxBTrzZxH1jOcQMWijGxUn0bEzyYOxmJ8Szg43qzMFsE5BcoR 7A+zKyFwx9gFutBKzw9/eBXY8H2QhnSgO2GB/CrjteZNevqzOqMZTsnGdBfJZndK cZVA71vrXMkacb4aS0xG9QnJsVi8t9PU7LNt59oRbsZLLFQd81wy4Q7vChCNgiSO bhOekQOPGDeKDf+n/g0hmlubEQsy9og4m3In+NHz5+K07ZJ4ONW9jao/KVvpi2ZV kJl7UYkQPLjyFh7+n9seSw04r/ZJwbDgOMmRMvuKtBWJ4gngYrm9R98+H+8St/Od CwcE+K1R49GjLb6744D7whLo+QuI1v/XYGgUz8XYue3sU3FKM34= =6INv -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
