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
