Re: Questions on recent CVE fixes

2018-03-14 Thread Harish Krishnan
Thanks for the response and confirmation, Mark.

On Wed, Mar 14, 2018 at 12:24 AM, Mark Thomas <ma...@apache.org> 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

2018-03-13 Thread Harish Krishnan
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

2017-10-13 Thread Harish Krishnan
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 
> <ch...@christopherschultz.net> 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

2017-10-12 Thread Harish Krishnan
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 <knst.koli...@gmail.com> 
> wrote:
> 
> 2017-10-09 19:31 GMT+03:00 Harish Krishnan <harish@gmail.com>:
>> 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

2017-10-11 Thread Harish Krishnan
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 <knst.koli...@gmail.com> 
> wrote:
> 
> 2017-10-09 19:31 GMT+03:00 Harish Krishnan <harish@gmail.com>:
>> 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

2017-10-10 Thread Harish Krishnan
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 <l...@kreuser.name> wrote:
> 
> Harish,
> 
> 
>> Am 10.10.2017 um 00:00 schrieb Harish Krishnan <harish@gmail.com>:
>> 
>> 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 doi

Re: Enforcing server preference for cipher suites

2017-10-09 Thread 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.

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

2017-10-09 Thread 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...

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

2017-09-29 Thread Harish Krishnan
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 <ma...@apache.org> 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 <ma...@apache.org> 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 <ma...@apache.org> 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=rev
>>>>>> [2] http://svn.apache.org/viewvc?rev=1809025=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,
>>>

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Possible additional RCE via JSP upload

2017-09-25 Thread Harish Krishnan
Thank you for the response and confirmation, Mark.

Sent from my iPhone

> On Sep 25, 2017, at 12:36 PM, Mark Thomas <ma...@apache.org> 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 <ma...@apache.org> 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=rev
>>>> [2] http://svn.apache.org/viewvc?rev=1809025=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 v

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Possible additional RCE via JSP upload

2017-09-25 Thread Harish Krishnan
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=rev
>> [2] http://svn.apache.org/viewvc?rev=1809025=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: 

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

2016-03-19 Thread Harish Krishnan
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 <ma...@apache.org> 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 <harish@gmail.com>
> > 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

2016-03-15 Thread Harish Krishnan
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 <harish@gmail.com>
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

2016-03-14 Thread Harish Krishnan
Any help on my previous question is really appreciated.
Thank You!

On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan <harish@gmail.com>
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

2016-03-11 Thread Harish Krishnan
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

2016-03-08 Thread Harish Krishnan
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

2016-03-07 Thread Harish Krishnan
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 <ma...@apache.org> 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

2016-03-07 Thread Harish Krishnan
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