Re: Questions on recent CVE fixes
Thanks for the response and confirmation, Mark.
On Wed, Mar 14, 2018 at 12:24 AM, Mark Thomas wrote:
> On 14/03/2018 01:04, Harish Krishnan wrote:
>
>> Hi All,
>>
>> Thanks for all the help and work you great people do.
>>
>> My question is regarding CVE-2018-1305
>> <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1305> and
>> CVE-2018-1304 <http://cve.mitre.org/cgi-bin/
>> cvename.cgi?name=CVE-2018-1304>
>> that
>> were fixed in the latest builds.
>> We use Tomcat 7.x.
>>
>> a) When can we expect the CVE scores determined for these vulnerabilities.
>> On NVD, it still says awaiting analysis.
>> This information would help us determine the SLA on when we can update
>> tomcat builds.
>>
>
> The Tomcat community does not provide CVSS scores. There are multiple
> reasons for this including:
> - they are too subjective;
> - the true score depends on how Tomcat is being used and that can only
> be determined by the user and can vary wildly from user to user for
> any one vulnerability.
>
> The correct thing to do is exactly what you are doing. Review the
> vulnerabilities, figure out of they impact you or not and, if they do
> impact you, figure out the extent of that impact, what you need to to to
> mitigate that impact and how quickly you need to do it.
>
> b) Regarding 1st CVE (#1305), we do not use annotation based security
>> constraints. Instead we configure it in our web.xml.
>> With this understanding, is it safe to consider we are not vulnerable?
>>
>
> Correct. You are not vulnerable because you do not define security
> constraints via annotations.
>
> c) Regarding 2nd CVE (#1304), the url pattern in all our security
>> constraints is of the format "/*".
>> * i believe would include everything.
>> To confirm with you, does this include the empty ("") string to make our
>> usage vulnerable too?
>>
>
> No. You are not vulnerable. The vulnerability only applies if the url
> pattern of the empty string is used to define a security constraint.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Questions on recent CVE fixes
Hi All,
Thanks for all the help and work you great people do.
My question is regarding CVE-2018-1305
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1305> and
CVE-2018-1304 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1304>
that
were fixed in the latest builds.
We use Tomcat 7.x.
a) When can we expect the CVE scores determined for these vulnerabilities.
On NVD, it still says awaiting analysis.
This information would help us determine the SLA on when we can update
tomcat builds.
b) Regarding 1st CVE (#1305), we do not use annotation based security
constraints. Instead we configure it in our web.xml.
With this understanding, is it safe to consider we are not vulnerable?
c) Regarding 2nd CVE (#1304), the url pattern in all our security
constraints is of the format "/*".
* i believe would include everything.
To confirm with you, does this include the empty ("") string to make our
usage vulnerable too?
regards
Harish Krishnan
Re: Enforcing server preference for cipher suites
Hi Chris, thanks for sharing your opinion. Just my last comment here to close this thread. BSAFE is anyways EOL now (or will be soon). We are already working on a replacement. Currently we are using the latest and greatest version of BSAFE with extended support. Once again, thank you all for the great support. I have another query (different topic) coming shortly...:-) Sent from my iPhone > On Oct 12, 2017, at 7:59 PM, Christopher Schultz > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Harish, > >> On 10/12/17 10:55 AM, Harish Krishnan wrote: >> Thank you all for the help and responses. We figured out what the >> problem was. What I did was correct in terms of the attribute >> setting, the tomcat version used and the JRE version used. However, >> I did not realize our JRE is running in FIPs mode using RSA BSAFE >> as the crypto provider. > FIPS strikes again! > > In this case, it's not really FIPS's fault, it's RSA's BSAFE. Anyone > using RSA's BSAFE these days ought to lose their job. Plow that thing > under with salt and use a trusted crypto provider (lol, Oracle, I guess) > . > >> When I tested and ran under standard JRE, then the server cipher >> suite order was preferred. > You are probably using an ancient version of BSAFE. Your random > numbers are probably all ones. Seriously, you need to dump BSAFE. > >> Now I will have to look into what RSA library is doing here. > > Leaking like a sieve, probably. > >> Probably they are setting that Java API too which could be >> overwriting our setting in tomcat. > > If that crypto provider is in use, then it'll likely affect the whole > JVM. It just occurred to me that Tomcat doesn't have a setting for the > crypto provider to use for TLS itself... only for the various > "stores", etc. We probably ought to add that, and then you could > choose "JSSE" as your provider and avoid BSAFE. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngLCgACgkQHPApP6U8 > pFjanhAAkTNcGk5/X6b9aK2gYcSDdTjkE879XA77KGYwWDF2L01jtSdF7ejnCcuN > 4lfivY/V5TaiKv0EZrU1YVC2psBZVK5CjfsCIfUZe5gOmqRRtxm8vRARULOY31oQ > tm4Hf3PHVXuKa/ZBQutLFOolJo7IhaYP3CtBqE+i7OWSlyy0dsqdqO40z9+vzt2n > DBiMRXl0Y2HGCeRsm0owdsFFDqA/j0xcCTBjgckgR6TcnRPc926FZVmr+q53DEQ1 > rYVo3Kfum7AnLP3y4rVT0SsxavjI48aXqCLKcM9RzRJ//D+p9teOeiHiUtu4CzHY > aQmkV22N6LC3M5uBwNNU1xXr62SNiarqY7euurPhPcOkbQSi4ckfknh48JzenQ41 > Ws7XvuLGOmTcLOv+rsKYjBd5s6IxuBH/+k5MfttPQaZ8mHAieMjEnVszmjZon2rE > Mqqcd+C5Z0q2/X9wUAwNAD3muQTzx2A8C3uucJHVygvwNy76UCUCoyLakQ98/8WL > 3SKN2l3EddObdi4OUrfga80ZTLf0AnBoflmKz+2UAbP3Xit++XHBs5dBgvN51Tji > d6IdBRJpSq/njZmnSGQYJ/4o07v31YgLjh+xZTS+8wxm5H3C4V6/IuWlsnYPZWi5 > YQRe0GPZw54IuLs9WZG6AbNcAzhGOW+OBIMGbzSKQukeLAVpjws= > =KUgn > -END PGP SIGNATURE- > > - > 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: Enforcing server preference for cipher suites
Thank you all for the help and responses. We figured out what the problem was. What I did was correct in terms of the attribute setting, the tomcat version used and the JRE version used. However, I did not realize our JRE is running in FIPs mode using RSA BSAFE as the crypto provider. When I tested and ran under standard JRE, then the server cipher suite order was preferred. Now I will have to look into what RSA library is doing here. Probably they are setting that Java API too which could be overwriting our setting in tomcat. Anyways, that's our problem to look into. Thanks again for the timely response and help! Sent from my iPhone > On Oct 10, 2017, at 10:26 AM, Konstantin Kolinko > wrote: > > 2017-10-09 19:31 GMT+03:00 Harish Krishnan : >> Hi All, >> >> Need your expert input here. >> Not sure what I am doing wrong, but I cannot get this server preference >> cipher suites feature working. >> >> My setup: >> Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute) >> Latest Java 1.8 build. >> >> No matter what value I set to this attribute (true OR false OR undefined >> which is by default), I always see the Clients preference picked. >> As an example, if clients order is ABCDEF, and servers order is DEFABC, no >> matter what value I set to this useServerCipherSuitesOrder attribute, always >> the order selected is ABC... > > It should work when running on Java 8. > > Maybe try debugging > e.g. with breakpoint in org.apache.tomcat.util.compat.Jre8Compat > setUseServerCipherSuitesOrder() > > https://wiki.apache.org/tomcat/FAQ/Developing#Debugging > > Best regards, > Konstantin Kolinko > > - > 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: Enforcing server preference for cipher suites
Thanks for the response, Konstantin. If debugging the tomcat code is the only option, then I will plan to do it sometime soon as it is bit additional work for me. We just use the tomcat binaries In our application. Meanwhile, if anybody have any other suggestions, that is greatly appreciated. Sent from my iPhone > On Oct 10, 2017, at 10:26 AM, Konstantin Kolinko > wrote: > > 2017-10-09 19:31 GMT+03:00 Harish Krishnan : >> Hi All, >> >> Need your expert input here. >> Not sure what I am doing wrong, but I cannot get this server preference >> cipher suites feature working. >> >> My setup: >> Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute) >> Latest Java 1.8 build. >> >> No matter what value I set to this attribute (true OR false OR undefined >> which is by default), I always see the Clients preference picked. >> As an example, if clients order is ABCDEF, and servers order is DEFABC, no >> matter what value I set to this useServerCipherSuitesOrder attribute, always >> the order selected is ABC... > > It should work when running on Java 8. > > Maybe try debugging > e.g. with breakpoint in org.apache.tomcat.util.compat.Jre8Compat > setUseServerCipherSuitesOrder() > > https://wiki.apache.org/tomcat/FAQ/Developing#Debugging > > Best regards, > Konstantin Kolinko > > - > 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: Enforcing server preference for cipher suites
Thanks for the response, Peter. The client is not doing anything other than a simple https connection to tomcat. The cipher sites used by the client is the default JRE 1.8 cipher suites. I have not configured or requesting for any particular cipher suite when connecting to Tomcat. During the handshake, a particular cipher is automatically selected after the client server negotiation. The question I have is, the cipher that is automatically selected, is in the client preference order and not tomcat order as per the attribute useServerCipherSuitesOrder setting. Are we on same page? Sent from my iPhone > On Oct 9, 2017, at 11:51 PM, Peter Kreuser wrote: > > Harish, > > >> Am 10.10.2017 um 00:00 schrieb Harish Krishnan : >> >> Thanks for the response, Chris. >> >> Below are my answers in order. >> To keep the response as short as possible, i have not included the ciphers >> list in the connector - >> >> a) Tomcat 7.0.79 (will be updating to 7.0.82) >> b) JRE 1.80_144 >> c) Our connector configuration is below. >> d) We are using NIO. >> e) I am using a simple java client that makes TLS connection to our tomcat >> on below port. I am capturing the SSL handshake. >> The way i tested the client preference is: Lets take the same example i >> gave in my first email i.e. clients preference is ABCDEF and the tomcat >> servers preference is DEFABC with *useServerCipherSuitesOrder* set to true. >> During the 1st handshake connection, "A" cipher suite was chosen. I removed >> "A" from my tomcat connector, restarted the service, and did the connection >> test again. >> "B" was chosen during this 2nd handshake. Same test was continued and >> observed that CDEF were chosen next in order. >> I am expecting DEFABC as the order of preference as per the >> *useServerCipherSuitesOrder* setting. > I believe that there is a misunderstanding. Your simple client does not seem > to handle the situation correctly (even not at all). > I think if you request cipher B you will get B. > > Please check with a ssl-tool like sslyze or testssl.sh. If your site is > available on the internet, you could try ssllabs.com. > > The settings seem to be OK, unless I do not see an incorrect formatting on my > phone. > > HTH, > > Peter > >> Let me know if i am missing anything or is my understanding is incorrect. >> >> > id="orion.server.https" >> acceptCount="100" >> *useServerCipherSuitesOrder*="true" >> ciphers="we have around 20 cipher suites listed..." >> clientAuth="want" >> >> compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" >> compression="on" >> compressionMinSize="2048" >> disableUploadTimeout="true" >> enableLookups="false" >> keystoreFile="keystore/xyz" >> keystorePass="" >> maxConnections="500" >> maxHttpHeaderSize="8192" >> maxKeepAliveRequests="500" >> maxThreads="250" >> minSpareThreads="25" >> noCompressionUserAgents="gozilla, traviata" >> port="8443" >> processorCache="500" >> protocol="org.apache.coyote.http11.Http11NioProtocol" >> scheme="https" >> secure="true" >> server="Undefined" >> sessionCacheSize="400" >> SSLEnabled="true" >> sslProtocol="TLS" >> sslEnabledProtocols="TLSv1.1, TLSv1.2" >> truststoreFile="keystore/xyz" >> truststorePass="" >> truststoreType="jks" >> URIEncoding="UTF-8" /> >> >> >> On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Harish, >>> >>>> On 10/9/17 12:31 PM, Harish Krishnan wrote: >>>> Need your expert input here. Not sure what I am doing wrong, but I >>>> cannot get this ser
Re: Enforcing server preference for cipher suites
Thanks for the response, Chris. Below are my answers in order. To keep the response as short as possible, i have not included the ciphers list in the connector - a) Tomcat 7.0.79 (will be updating to 7.0.82) b) JRE 1.80_144 c) Our connector configuration is below. d) We are using NIO. e) I am using a simple java client that makes TLS connection to our tomcat on below port. I am capturing the SSL handshake. The way i tested the client preference is: Lets take the same example i gave in my first email i.e. clients preference is ABCDEF and the tomcat servers preference is DEFABC with *useServerCipherSuitesOrder* set to true. During the 1st handshake connection, "A" cipher suite was chosen. I removed "A" from my tomcat connector, restarted the service, and did the connection test again. "B" was chosen during this 2nd handshake. Same test was continued and observed that CDEF were chosen next in order. I am expecting DEFABC as the order of preference as per the *useServerCipherSuitesOrder* setting. Let me know if i am missing anything or is my understanding is incorrect. On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Harish, > > On 10/9/17 12:31 PM, Harish Krishnan wrote: > > Need your expert input here. Not sure what I am doing wrong, but I > > cannot get this server preference cipher suites feature working. > > > > My setup: Latest tomcat 7.x build (which supports > > useServerCipherSuitesOrder attribute) Latest Java 1.8 build. > > > > No matter what value I set to this attribute (true OR false OR > > undefined which is by default), I always see the Clients preference > > picked. As an example, if clients order is ABCDEF, and servers > > order is DEFABC, no matter what value I set to this > > useServerCipherSuitesOrder attribute, always the order selected is > > ABC... > > What exact version of Tomcat are you using? > What exact version of Java are you using? > > Please post your configuration, minus any secrets. > > Do you know if you are using the BIO, NIO, or APR connector? > > How are you determining client-preference? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C > qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK > j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p > MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s > n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If > xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0 > RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR > /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O > GHAsqCD+8m3z/Oohi09Mi+pPebYAFuTHSERkK4s7rOHUinxzr1utx87s4g5m995R > qU97BpOc33+ouOS5cKx4t+xrGaZr5LfNb8lXEZluNSDmU7Lnb7qA/yrr6prXbniG > 5wv2zVlFit/8rKQInCEH0c/c2cD15RaU6iBujhfRpWYl1XWmOkWYQCzZ2xlLy/Hg > lPIZuxLUk5GBnA/vV8qtLIfK7cc= > =SuWg > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Enforcing server preference for cipher suites
Hi All, Need your expert input here. Not sure what I am doing wrong, but I cannot get this server preference cipher suites feature working. My setup: Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute) Latest Java 1.8 build. No matter what value I set to this attribute (true OR false OR undefined which is by default), I always see the Clients preference picked. As an example, if clients order is ABCDEF, and servers order is DEFABC, no matter what value I set to this useServerCipherSuitesOrder attribute, always the order selected is ABC... Regard Harish Krishnan Sent from my iPhone - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2017-12617 Apache Tomcat Possible additional RCE via JSP upload
Thank you for this latest update. Looking forward for the 7.x new build. Sent from my iPhone > On Sep 29, 2017, at 2:14 AM, Mark Thomas wrote: > > Hi all, > > Hopefully this will be the final update on this. > > The fixes for CVE-2017-12617 have now been applied to all current > versions. Releases for 9.0.x and 8.5.x are already in progress on the > dev@ list. The release process for 8.0.x and 7.0.x is expected to start > shortly. > > As per my previous e-mail, I expect the releases to be announced over > the weekend / early next week. > > Mark > > >> On 26/09/17 02:22, Harish Krishnan wrote: >> Thank you for the response and confirmation, Mark. >> >> Sent from my iPhone >> >>>> On Sep 25, 2017, at 12:36 PM, Mark Thomas wrote: >>>> >>>> On 25/09/17 18:12, Harish Krishnan wrote: >>>> Hi Mark, >>>> >>>> Thanks for the timely updates. >>>> My understanding is, there will be a new 7.x update available for >>>> addressing CVE-2017-12617. Is that correct? >>>> The current latest (7.0_81) resolves the initial 2 CVEs (CVE*12615 and >>>> CVE*12616). >>>> When can we expect the new update for 7.x? >>> >>> Over the weekend we received an additional report that demonstrated a >>> way of bypassing the fix for CVE-2017-12615. The changes we have already >>> made for CVE-2017-12617 also block this additional attack vector but not >>> as cleanly as we would like. Therefore we intend to make some additional >>> changes and re-tag 9.0.x and 8.5.x. >>> >>> Separately, testing has identified a regression in the 7.0.x back-port >>> which will need to be addressed before 7.0.x is tagged. >>> >>> Timings are hard to guarantee but I think we are looking at tags in the >>> next 24 hours or so, release votes complete in anything up 72 hours >>> after that (less if folks vote quickly) and the release on the mirrors 6 >>> to 12 hours after that. We might just make the weekend but early next >>> week seems more realistic. >>> >>> Mark >>> >>>> >>>> Sent from my iPhone >>>> >>>>> On Sep 22, 2017, at 2:21 AM, Mark Thomas wrote: >>>>> >>>>> Update: >>>>> >>>>> The review did not identify any further security concerns but it did >>>>> identify a handful of places where the code could benefit from some >>>>> clean-up. This clean-up makes the purpose of the code clearer and eases >>>>> future maintenance in this security-relevant area of the code base. >>>>> >>>>> The clean-up has been implemented and reviewed. Back-ports have been >>>>> completed for 8.5.x and 8.0.x. 7.0.x is in progress but requires a >>>>> little more time as 7.0.x uses the JNDI based resources implementation >>>>> that was replaced in 8.0.x onwards. >>>>> >>>>> The current expectation is that the releases will be tagged and votes >>>>> started later today. >>>>> >>>>> Mark >>>>> >>>>> >>>>>> On 20/09/17 17:37, Mark Thomas wrote: >>>>>> Update: >>>>>> >>>>>> We believe we have a set of patches [1],[2] that addresses this for >>>>>> 9.0.x. The plan is to give folks ~12 hours to review the proposed >>>>>> patches and then back-port the patches, tag and release. >>>>>> >>>>>> Further analysis has not identified any additional attack vectors or >>>>>> risks associated with this vulnerability. >>>>>> >>>>>> The recommended mitigations remain unchanged. >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> [1] http://svn.apache.org/viewvc?rev=1809011&view=rev >>>>>> [2] http://svn.apache.org/viewvc?rev=1809025&view=rev >>>>>> >>>>>> >>>>>>> On 20/09/17 13:20, Mark Thomas wrote: >>>>>>> Update: >>>>>>> >>>>>>> The issue has been confirmed. >>>>>>> >>>>>>> CVE-2017-12617 has been allocated. >>>>>>> >>>>>>> The issue is not limited to PUT requests. For the Default servlet, >>>>>>> DELETE is known to be affected. F
Re: [SECURITY] CVE-2017-12617 Apache Tomcat Possible additional RCE via JSP upload
Thank you for the response and confirmation, Mark. Sent from my iPhone > On Sep 25, 2017, at 12:36 PM, Mark Thomas wrote: > >> On 25/09/17 18:12, Harish Krishnan wrote: >> Hi Mark, >> >> Thanks for the timely updates. >> My understanding is, there will be a new 7.x update available for addressing >> CVE-2017-12617. Is that correct? >> The current latest (7.0_81) resolves the initial 2 CVEs (CVE*12615 and >> CVE*12616). >> When can we expect the new update for 7.x? > > Over the weekend we received an additional report that demonstrated a > way of bypassing the fix for CVE-2017-12615. The changes we have already > made for CVE-2017-12617 also block this additional attack vector but not > as cleanly as we would like. Therefore we intend to make some additional > changes and re-tag 9.0.x and 8.5.x. > > Separately, testing has identified a regression in the 7.0.x back-port > which will need to be addressed before 7.0.x is tagged. > > Timings are hard to guarantee but I think we are looking at tags in the > next 24 hours or so, release votes complete in anything up 72 hours > after that (less if folks vote quickly) and the release on the mirrors 6 > to 12 hours after that. We might just make the weekend but early next > week seems more realistic. > > Mark > >> >> Sent from my iPhone >> >>> On Sep 22, 2017, at 2:21 AM, Mark Thomas wrote: >>> >>> Update: >>> >>> The review did not identify any further security concerns but it did >>> identify a handful of places where the code could benefit from some >>> clean-up. This clean-up makes the purpose of the code clearer and eases >>> future maintenance in this security-relevant area of the code base. >>> >>> The clean-up has been implemented and reviewed. Back-ports have been >>> completed for 8.5.x and 8.0.x. 7.0.x is in progress but requires a >>> little more time as 7.0.x uses the JNDI based resources implementation >>> that was replaced in 8.0.x onwards. >>> >>> The current expectation is that the releases will be tagged and votes >>> started later today. >>> >>> Mark >>> >>> >>>> On 20/09/17 17:37, Mark Thomas wrote: >>>> Update: >>>> >>>> We believe we have a set of patches [1],[2] that addresses this for >>>> 9.0.x. The plan is to give folks ~12 hours to review the proposed >>>> patches and then back-port the patches, tag and release. >>>> >>>> Further analysis has not identified any additional attack vectors or >>>> risks associated with this vulnerability. >>>> >>>> The recommended mitigations remain unchanged. >>>> >>>> Mark >>>> >>>> >>>> [1] http://svn.apache.org/viewvc?rev=1809011&view=rev >>>> [2] http://svn.apache.org/viewvc?rev=1809025&view=rev >>>> >>>> >>>>> On 20/09/17 13:20, Mark Thomas wrote: >>>>> Update: >>>>> >>>>> The issue has been confirmed. >>>>> >>>>> CVE-2017-12617 has been allocated. >>>>> >>>>> The issue is not limited to PUT requests. For the Default servlet, >>>>> DELETE is known to be affected. For the WebDAV servlet DELETE, MOVE and >>>>> COPY are believed to be affected. >>>>> >>>>> The RCE via JSP upload using PUT is still believed to be the most severe >>>>> impact of this vulnerability. >>>>> >>>>> The recommended mitigations remain unchanged. >>>>> >>>>> Mark >>>>> >>>>> >>>>>> On 20/09/17 09:25, Mark Thomas wrote: >>>>>> All, >>>>>> >>>>>> Following the announcement of CVE-2017-12615 [1], the Apache Tomcat >>>>>> Security Team has received multiple reports that a similar vulnerability >>>>>> exists in all current Tomcat versions and affects all operating systems. >>>>>> >>>>>> Unfortunately, one of these reports was made via the public bug tracker >>>>>> [2] rather than responsibly via the Tomcat Security Team's private >>>>>> mailing list [3]. >>>>>> >>>>>> We have not yet completed our investigation of these reports but, based >>>>>> on the volume, and our initial investigation they appear to be valid. >>>>>> &g
Re: [SECURITY] CVE-2017-12617 Apache Tomcat Possible additional RCE via JSP upload
Hi Mark, Thanks for the timely updates. My understanding is, there will be a new 7.x update available for addressing CVE-2017-12617. Is that correct? The current latest (7.0_81) resolves the initial 2 CVEs (CVE*12615 and CVE*12616). When can we expect the new update for 7.x? Sent from my iPhone > On Sep 22, 2017, at 2:21 AM, Mark Thomas wrote: > > Update: > > The review did not identify any further security concerns but it did > identify a handful of places where the code could benefit from some > clean-up. This clean-up makes the purpose of the code clearer and eases > future maintenance in this security-relevant area of the code base. > > The clean-up has been implemented and reviewed. Back-ports have been > completed for 8.5.x and 8.0.x. 7.0.x is in progress but requires a > little more time as 7.0.x uses the JNDI based resources implementation > that was replaced in 8.0.x onwards. > > The current expectation is that the releases will be tagged and votes > started later today. > > Mark > > >> On 20/09/17 17:37, Mark Thomas wrote: >> Update: >> >> We believe we have a set of patches [1],[2] that addresses this for >> 9.0.x. The plan is to give folks ~12 hours to review the proposed >> patches and then back-port the patches, tag and release. >> >> Further analysis has not identified any additional attack vectors or >> risks associated with this vulnerability. >> >> The recommended mitigations remain unchanged. >> >> Mark >> >> >> [1] http://svn.apache.org/viewvc?rev=1809011&view=rev >> [2] http://svn.apache.org/viewvc?rev=1809025&view=rev >> >> >>> On 20/09/17 13:20, Mark Thomas wrote: >>> Update: >>> >>> The issue has been confirmed. >>> >>> CVE-2017-12617 has been allocated. >>> >>> The issue is not limited to PUT requests. For the Default servlet, >>> DELETE is known to be affected. For the WebDAV servlet DELETE, MOVE and >>> COPY are believed to be affected. >>> >>> The RCE via JSP upload using PUT is still believed to be the most severe >>> impact of this vulnerability. >>> >>> The recommended mitigations remain unchanged. >>> >>> Mark >>> >>> On 20/09/17 09:25, Mark Thomas wrote: All, Following the announcement of CVE-2017-12615 [1], the Apache Tomcat Security Team has received multiple reports that a similar vulnerability exists in all current Tomcat versions and affects all operating systems. Unfortunately, one of these reports was made via the public bug tracker [2] rather than responsibly via the Tomcat Security Team's private mailing list [3]. We have not yet completed our investigation of these reports but, based on the volume, and our initial investigation they appear to be valid. From an initial analysis of the reports received, the vulnerability only affects the following configurations: Default Servlet - Default Servlet configured with readonly="false" AND - Untrusted users are permitted to perform HTTP PUT requests WebDAV Servlet - WebDAV Servlet configured with readonly="false" AND - Untrusted users are permitted to perform HTTP PUT requests AND - The documented advice not to map the WebDAV servlet as the Default servlet has been ignored Please note that: - The WebDAV servlet is disabled by default - The default value for the readonly parameter is true for both the Default servlet and the WebDAV servlet Therefore, a default Tomcat installation is not affected by this potential vulnerability. Based on our understanding to date, the potential vulnerability may be mitigated by any of the following: - setting readonly to true for the Default servlet and WebDAV servlet - blocking HTTP methods that permit resource modification for untrusted users We will provide updates to the community as our investigation of these reports continues. Mark on behalf of the Apache Tomcat Security Team [1] http://markmail.org/message/xqfchebiy6fjmvjz [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=61542 [3] http://tomcat.apache.org/security.html - 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 >> >> >> - >> 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
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Thanks a lot for the clear explanation, Mark. I have all my questions answered, appreciate your help & you guys are Great! My apologies for the previous follow-up emails, I am still a novice in tomcat & failed in understanding the exact fix quicker. regards Harish Krishnan On Wed, Mar 16, 2016 at 4:38 AM, Mark Thomas wrote: > On 15/03/2016 20:58, Harish Krishnan wrote: > > Hello There, > > > > I am kind of blocked here in my project while applying your CVE fix in > our > > product & verify the fix. Any guidelines on what i am doing (mentioned in > > my previous email) wrong is highly appreciated. > > You are failing to follow the hints you have been given previously. > > > All i am trying to do is, disable the redirect for the root (Ex: > /manager & > > /examples in tomcat) of the webapp. If i know how to do this on the > > mentioned tomcat webapps, then i can apply the same for my webapps too. > > Looking for your response & help here. > > You CAN NOT disable the redirect. As the documentation for the two > redirect options makes clear, all they do is change WHERE the redirect > happens. > > The key point in all of this is that security constraints are applied > AFTER the Mapper and BEFORE the DefaultServlet. If the request is for a > protected resource and the redirects take place in the Mapper, then the > response will confirm whether that resource exists irrespective of > whether or not the user is authorized to access the resource. If the > redirect takes place in the Default Servlet, the response will reflect > the security constraints and the user's access rights if any. > > Again, you need to look at the security constraints for the Manager > application. /manager is NOT a protected resource so the redirect is > always going to happen. > > Mark > > > > > > > > regards > > Harish Krishnan > > > > On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan > > wrote: > > > >> Thanks again for the reply, Chris & Violeta! > >> Thanks for clarifying what the "protected directory" is, even i guessed > it > >> to be same. Now i understood the fix for the directories protected by a > >> security constraint. I also verified this & the redirect is no more > >> happening for these protected ones. Really appreciate your help here. > >> > >> However, i am still unable to disable the redirect for the root of the > >> webapp. This is what i did on the latest tomcat build (7.0.68) - > >> > >> a) Set the context attribute (mapperContextRootRedirectEnabled) to false > >> for manager webapp. Here is my context.xml (from > >> \webapps\manager\META-INF\) file - > >> > >> >> antiResourceLocking="false" privileged="true" > > >> > >> > >> b) Accessing http://localhost:8080/manager gets redirected to manger/. > >> > >> c) I have also set the above context attribute in the default > context.xml > >> (from \conf\context.xml) file as well. > >> > >> d) Accessing http://localhost:8080/examples gets redirected to > examples/. > >> > >> Not sure what i am missing here. Same behavior is seen on my web > >> application too. > >> Please let me know where i am doing wrong & help me on how to disable > the > >> redirect for the root of webapps. > >> > >> > >> regards > >> Harish Krishnan > >> > >> > >> > >> > >> > >> > >> > >> On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > >>> Harish, > >>> > >>> On 3/8/16 5:47 PM, Harish Krishnan wrote: > >>>> Thanks Chris for the reply. > >>>> Looks like my understanding of the fix is incorrect. > >>>> I assumed (my bad) that, with the fix for this CVE in place (tomcat > >>>> 7.0.68) + setting the additional context attribute > >>>> (mapperContextRootRedirectEnabled="false"), all the redirects for that > >>>> webapp where context attribute was set, will completely be disabled. > >>>> You mentioned that only "protected directories" inside the deployed > web > >>>> application is covered in this CVE fix. > >>>> Can you please help me understand what this protected directories are > & > >>> how > >>>> to configure this in tomcat ? > >>> > >>> A "protected directory" is one that has a in > >>> web.xml. That's not a spec-defined term... just one we've been using > >>> because it captures the meaning with fewer words. > >>> > >>> As for the redirects you are seeing that "expose" the availability of a > >>> particular web application, those are essentially impossible to > prevent, > >>> and not considered a part of the CVE. > >>> > >>> -chris > >>> > >>> - > >>> 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 about your recent security (CVE-2015-5345) fix in 7.0.68 build
Hello There, I am kind of blocked here in my project while applying your CVE fix in our product & verify the fix. Any guidelines on what i am doing (mentioned in my previous email) wrong is highly appreciated. All i am trying to do is, disable the redirect for the root (Ex: /manager & /examples in tomcat) of the webapp. If i know how to do this on the mentioned tomcat webapps, then i can apply the same for my webapps too. Looking for your response & help here. regards Harish Krishnan On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan wrote: > Thanks again for the reply, Chris & Violeta! > Thanks for clarifying what the "protected directory" is, even i guessed it > to be same. Now i understood the fix for the directories protected by a > security constraint. I also verified this & the redirect is no more > happening for these protected ones. Really appreciate your help here. > > However, i am still unable to disable the redirect for the root of the > webapp. This is what i did on the latest tomcat build (7.0.68) - > > a) Set the context attribute (mapperContextRootRedirectEnabled) to false > for manager webapp. Here is my context.xml (from > \webapps\manager\META-INF\) file - > > antiResourceLocking="false" privileged="true" > > > > b) Accessing http://localhost:8080/manager gets redirected to manger/. > > c) I have also set the above context attribute in the default context.xml > (from \conf\context.xml) file as well. > > d) Accessing http://localhost:8080/examples gets redirected to examples/. > > Not sure what i am missing here. Same behavior is seen on my web > application too. > Please let me know where i am doing wrong & help me on how to disable the > redirect for the root of webapps. > > > regards > Harish Krishnan > > > > > > > > On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Harish, >> >> On 3/8/16 5:47 PM, Harish Krishnan wrote: >> > Thanks Chris for the reply. >> > Looks like my understanding of the fix is incorrect. >> > I assumed (my bad) that, with the fix for this CVE in place (tomcat >> > 7.0.68) + setting the additional context attribute >> > (mapperContextRootRedirectEnabled="false"), all the redirects for that >> > webapp where context attribute was set, will completely be disabled. >> > You mentioned that only "protected directories" inside the deployed web >> > application is covered in this CVE fix. >> > Can you please help me understand what this protected directories are & >> how >> > to configure this in tomcat ? >> >> A "protected directory" is one that has a in >> web.xml. That's not a spec-defined term... just one we've been using >> because it captures the meaning with fewer words. >> >> As for the redirects you are seeing that "expose" the availability of a >> particular web application, those are essentially impossible to prevent, >> and not considered a part of the CVE. >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Any help on my previous question is really appreciated. Thank You! On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan wrote: > Thanks again for the reply, Chris & Violeta! > Thanks for clarifying what the "protected directory" is, even i guessed it > to be same. Now i understood the fix for the directories protected by a > security constraint. I also verified this & the redirect is no more > happening for these protected ones. Really appreciate your help here. > > However, i am still unable to disable the redirect for the root of the > webapp. This is what i did on the latest tomcat build (7.0.68) - > > a) Set the context attribute (mapperContextRootRedirectEnabled) to false > for manager webapp. Here is my context.xml (from > \webapps\manager\META-INF\) file - > > antiResourceLocking="false" privileged="true" > > > > b) Accessing http://localhost:8080/manager gets redirected to manger/. > > c) I have also set the above context attribute in the default context.xml > (from \conf\context.xml) file as well. > > d) Accessing http://localhost:8080/examples gets redirected to examples/. > > Not sure what i am missing here. Same behavior is seen on my web > application too. > Please let me know where i am doing wrong & help me on how to disable the > redirect for the root of webapps. > > > regards > Harish Krishnan > > > > > > > > On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Harish, >> >> On 3/8/16 5:47 PM, Harish Krishnan wrote: >> > Thanks Chris for the reply. >> > Looks like my understanding of the fix is incorrect. >> > I assumed (my bad) that, with the fix for this CVE in place (tomcat >> > 7.0.68) + setting the additional context attribute >> > (mapperContextRootRedirectEnabled="false"), all the redirects for that >> > webapp where context attribute was set, will completely be disabled. >> > You mentioned that only "protected directories" inside the deployed web >> > application is covered in this CVE fix. >> > Can you please help me understand what this protected directories are & >> how >> > to configure this in tomcat ? >> >> A "protected directory" is one that has a in >> web.xml. That's not a spec-defined term... just one we've been using >> because it captures the meaning with fewer words. >> >> As for the redirects you are seeing that "expose" the availability of a >> particular web application, those are essentially impossible to prevent, >> and not considered a part of the CVE. >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Thanks again for the reply, Chris & Violeta! Thanks for clarifying what the "protected directory" is, even i guessed it to be same. Now i understood the fix for the directories protected by a security constraint. I also verified this & the redirect is no more happening for these protected ones. Really appreciate your help here. However, i am still unable to disable the redirect for the root of the webapp. This is what i did on the latest tomcat build (7.0.68) - a) Set the context attribute (mapperContextRootRedirectEnabled) to false for manager webapp. Here is my context.xml (from \webapps\manager\META-INF\) file - b) Accessing http://localhost:8080/manager gets redirected to manger/. c) I have also set the above context attribute in the default context.xml (from \conf\context.xml) file as well. d) Accessing http://localhost:8080/examples gets redirected to examples/. Not sure what i am missing here. Same behavior is seen on my web application too. Please let me know where i am doing wrong & help me on how to disable the redirect for the root of webapps. regards Harish Krishnan On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Harish, > > On 3/8/16 5:47 PM, Harish Krishnan wrote: > > Thanks Chris for the reply. > > Looks like my understanding of the fix is incorrect. > > I assumed (my bad) that, with the fix for this CVE in place (tomcat > > 7.0.68) + setting the additional context attribute > > (mapperContextRootRedirectEnabled="false"), all the redirects for that > > webapp where context attribute was set, will completely be disabled. > > You mentioned that only "protected directories" inside the deployed web > > application is covered in this CVE fix. > > Can you please help me understand what this protected directories are & > how > > to configure this in tomcat ? > > A "protected directory" is one that has a in > web.xml. That's not a spec-defined term... just one we've been using > because it captures the meaning with fewer words. > > As for the redirects you are seeing that "expose" the availability of a > particular web application, those are essentially impossible to prevent, > and not considered a part of the CVE. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Thanks Chris for the reply. Looks like my understanding of the fix is incorrect. I assumed (my bad) that, with the fix for this CVE in place (tomcat 7.0.68) + setting the additional context attribute (mapperContextRootRedirectEnabled="false"), all the redirects for that webapp where context attribute was set, will completely be disabled. You mentioned that only "protected directories" inside the deployed web application is covered in this CVE fix. Can you please help me understand what this protected directories are & how to configure this in tomcat ? regards Harish Krishnan On Tue, Mar 8, 2016 at 7:59 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Harish, > > On 3/7/16 6:02 PM, Harish Krishnan wrote: > > Unfortunately, i still could not verify this vulnerability as it > > still appears not fixed & my requests get redirected. > > What makes you think that the requests should not be redirected? > > > Instead of using the manager webapp that comes default in tomcat, > > we created a sample webapp with the following security constraint > > - > > hello.html > > > > sercure-hello > > /* > > > > NONE > > > > > > Accessing http://localhost:8080/a (which exist) gets redirected to > > http://localhost:8080/a/ & then get 404. Accessing > > http://localhost:8080/b (does not exist) simply gets 404. > > Where did you deploy this sample web application? > > > I have set the context attribute (mapperContextRootRedirectEnabled) > > as well - > antiResourceLocking="false" privileged="true"> > > > > My question simply boils down to, What additional setting i need to > > do for the above redirect to NOT happen. > > Which redirect? A redirect for a protected directory inside of a > deployed web application (which is what this CVE covers) or the > redirect for a deployed web application (which is not what this CVE > covers)? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbe9twACgkQ9CaO5/Lv0PBaqQCeMMYqM8+hPnekw1NM8I5NNa0J > uaQAn2Kp35FIKikIFfZdlao4Un1NCNGe > =/uiq > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Thanks for the reply, Mark. Unfortunately, i still could not verify this vulnerability as it still appears not fixed & my requests get redirected. Instead of using the manager webapp that comes default in tomcat, we created a sample webapp with the following security constraint - hello.html sercure-hello /* NONE Accessing http://localhost:8080/a (which exist) gets redirected to http://localhost:8080/a/ & then get 404. Accessing http://localhost:8080/b (does not exist) simply gets 404. I have set the context attribute (mapperContextRootRedirectEnabled) as well - My question simply boils down to, What additional setting i need to do for the above redirect to NOT happen. Thanks for your help. regards Harish Krishnan On Mon, Mar 7, 2016 at 12:42 PM, Mark Thomas wrote: > On 07/03/2016 20:23, Harish Krishnan wrote: > > Hi There, > > > > I am verifying the fix that you made for CVE-2015-5345 & it appears to > be > > not fixed. I might be doing something wrong & hence sending out this > email > > to you. > > All i did was, > > a) Downloaded & installed the latest tomcat build 7.0.68. > > b) Added the following context attribute to manager webapp just for > testing > > - > > File: $CATALINA_HOME\webapps\manager\META-INF\context.xml > >> antiResourceLocking="false" privileged="true"> > > c) When i access http://localhost/8080/manager/images, it still gets > > redirected to /images/ there by confirming the folder location. Same > thing > > happens when accessing /manager/index.jsp too. > > > > Am i missing anything here ? > > Yes. Look at the security constraints defined for the Manager application. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
Hi There, I am verifying the fix that you made for CVE-2015-5345 & it appears to be not fixed. I might be doing something wrong & hence sending out this email to you. All i did was, a) Downloaded & installed the latest tomcat build 7.0.68. b) Added the following context attribute to manager webapp just for testing - File: $CATALINA_HOME\webapps\manager\META-INF\context.xml c) When i access http://localhost/8080/manager/images, it still gets redirected to /images/ there by confirming the folder location. Same thing happens when accessing /manager/index.jsp too. Am i missing anything here ? Please help me understand the exact fix for this issue. regards Harish Krishnan
