Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Michael, > Am 13.02.2019 um 22:03 schrieb Adams, Michael : > > 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: 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. >> default >> org.apache.catalina.servlets.DefaultServlet ass> >> >> > >> debug 0 >> listings >> false >> readonly true >> 1 >> >> 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 >
FW: Re: Question regarding mitigating the CVE-2017-12617 vulnerability
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. > default > org.apache.catalina.servlets.DefaultServlet > > > debug 0 > listings > false > readonly true > 1 > > 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-
FW: Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Mark, Thanks for your input. It was very helpful. 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. Mike -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, February 13, 2019 1:20 PM To: users@tomcat.apache.org Subject: [External] Re: Question regarding mitigating the CVE-2017-12617 vulnerability Mike, You have nothing to worry about. As long as readonly was never explicitly set to false, you have not been vulnerable to CVE-2017-12617 at any point. readonly is true by default. CVE-2017-12617 only applies if readonly is false which requires explicit configuration. I'm curious what tests Tripwire is performing to determine that this vulnerability is present. I wonder if it is relying on an OPTIONS request to determine if PUT is enabled? The problem with that is that OPTIONS tells you what is supported, not what is permitted. Mark On 13/02/2019 18:35, Adams, Michael wrote: > TomCat users. > I currently am running Apache Tomcat > https://urldefense.proofpoint.com/v2/url?u=http-3A__8.5.13.0=DwICaQ=LkAXfnqL6_MvrMPL5JzdE3Ild0DUTpmjbCJvMv5_TcQ=p3_goTYT-PvEzXC6jGr9rg=EyqQRJjlE-MS2UtSwB36b0JrzdT5stm5F4mjaEAE7Mw=_4_hoZTjRXAb-gUL3WJvsPiWcIqUBuEFWbO2Kr_y3S8= > 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? > > 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. > > The following should make the context read-only and HTTP commands like PUT > and DELETE to be rejected. > > default > > org.apache.catalina.servlets.DefaultServlet > > debug > 0 > > > listings > false > > > readonly > true > > 1 > > > Your help in the following matter would be much appreciated. > > Mike > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Mike, You have nothing to worry about. As long as readonly was never explicitly set to false, you have not been vulnerable to CVE-2017-12617 at any point. readonly is true by default. CVE-2017-12617 only applies if readonly is false which requires explicit configuration. I'm curious what tests Tripwire is performing to determine that this vulnerability is present. I wonder if it is relying on an OPTIONS request to determine if PUT is enabled? The problem with that is that OPTIONS tells you what is supported, not what is permitted. Mark On 13/02/2019 18:35, Adams, Michael wrote: > TomCat users. > 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? > > 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. > > The following should make the context read-only and HTTP commands like PUT > and DELETE to be rejected. > > default > > org.apache.catalina.servlets.DefaultServlet > > debug > 0 > > > listings > false > > > readonly > true > > 1 > > > Your help in the following matter would be much appreciated. > > Mike > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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. > default > org.apache.catalina.servlets.DefaultServlet > > > debug 0 > listings > false > readonly true > 1 > > 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
Question regarding mitigating the CVE-2017-12617 vulnerability
TomCat users. 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? 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. The following should make the context read-only and HTTP commands like PUT and DELETE to be rejected. default org.apache.catalina.servlets.DefaultServlet debug 0 listings false readonly true 1 Your help in the following matter would be much appreciated. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] tomcat 8.5.37, Http11Nio2Protocol (OpenSSL), clientAuth or certificateVerification options
On 12/02/2019 22:26, Christopher Schultz wrote: > Mark, > > On 2/12/19 13:27, Mark Thomas wrote: >> Try again. Prompted for certificate. Select valid cert. Connection >> refused. Ah. the trust store again. Switch back to the OpenSSL >> config. > > This is a real point of confusion for users... the difference between > configuring for OpenSSL versus JSSE (especially when using OpenSSL via > JSSE). > > Is there any technical reason why we can't accept either type of > certificate for either type of connector? I can't think of a reason > why we couldn't convert from one to the other if necessary. > > Sure, it's a bunch of plumbing code that we have to babysit, but the > configuration will be *so* much nicer, regardless of the user's > preference (e.g. PEM-encoded DER files, just like $diety intended, or > the hellspawn that is certificate keystores). Some of that is already in place but there are gaps. Likewise we have merged some of the configuration options but could probably do more. A good starting point would be a wiki page or similar that documented the current state and then we could start to fill in the gaps. Just thinking out loud, a nice way to test this would be with a single set of key/cert files and multiple connectors on different ports that each used a different combination. Testing would then be a case of start Tomcat and check the homepage on a handful of different ports (which could easily be made into a unit test). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
