You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2019/02/13 19:19:01 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Posted by "Peter@Kreuser-Online" <lo...@kreuser.name>.
Michael,
> Am 13.02.2019 um 22:03 schrieb Adams, Michael <ma...@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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
FW: Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Posted by "Adams, Michael" <ma...@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. 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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org