Michael, > Am 13.02.2019 um 22:03 schrieb Adams, Michael <mad...@fnni.com.invalid>: > > 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.
Not saying that the update would not be worth it, but to get around the version check, you should set the ErrorReportValve like so: <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" /> That will remove the version info from the 404 or error-pages. I assume that you removed the Default ROOT and examples webcontext. The are a couple more hardening suggestions. But keep the updates coming. 8.5.13 is a bit aged and the next scan will come. Just the 2cts of an application security guy. Peter > 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 > > ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖ֖âW6W'2×Vç7V'67&–&TFöÖ6Bæ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W'2Ö†VÇFöÖ6Bæ6†Ræ÷&pÐ > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org