[Bug 57767] Websocket client proprietary configuration

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=57767

--- Comment #19 from J Fernandez  ---
Are there any additional proposed changes for this patch? I would like to
leverage some of the functionality for
https://bz.apache.org/bugzilla/show_bug.cgi?id=59758.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61554] New: Add excludes to rat-excludes.txt for Tomcat9

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61554

Bug ID: 61554
   Summary: Add excludes to rat-excludes.txt for Tomcat9
   Product: Tomcat 9
   Version: 9.0.0.M26
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
  Assignee: dev@tomcat.apache.org
  Reporter: chr...@apache.org
  Target Milestone: -

Created attachment 35345
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35345&action=edit
Patch for rat-excludes in tomcat9

Rat is not producing reports for Tomcat9 as the xml output contains invalid
characters. 

Please see bug 60170 for reference. 

-Chris T.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Draft EOL announcement for Tomcat Native 1.1.x

2017-09-20 Thread Konstantin Kolinko
2017-09-19 23:45 GMT+03:00 Mark Thomas :
> Updated with Konstantin's feedback.
>
> Further comments, feedback etc welcome.
>
>
>
> The Apache Tomcat Team announces that support for Apache Tomcat Native
> 1.1.x will end on 30 September 2018.
>
> This means that after 30 September 2018:
> - releases from the 1.1.x branch are highly unlikely
> - bugs affecting only the 1.1.x branch will not be addressed
> - security vulnerability reports will not be checked against the 1.1.x
>   branch
> - Apache Tomcat releases of 7.0.x after this date may require 1.2.x as a
>   minimum
>
> Three months later (i.e. after 31 December 2018)
> - the 1.1.x download pages will be removed
> - the latest 1.1.x release will be removed from the mirror system
> - the links to the 1.1.x documentation will be removed from
>   tomcat.apache.org
>
> The latest binary releases of 1.1.x for Windows are not built with a

"Microsoft Windows"

> current version of OpenSSL and will therefore be removed from the
> download pages with immediate effect.
>
> Please also note the following additional information:
>
> Tomcat 8.5.x and 9.0.x require a minimum of Tomcat Native 1.2.x and are
> therefore unaffected by this notice.
>
> Tomcat 8.0.x will reach end of life on 30 June 2018 and is therefore
> unaffected by this notice.
>
> Only Tomcat 7.0.x is affected by this notice.
>
> Tomcat 7.0.x has shipped with Tomcat Native 1.2.x since 7.0.70 (June 2016).
>
> All 1.1.x releases will always be available from the archive.
>
> Tomcat Native 1.2.x is a drop-in replacement for 1.1.x although it does
> require OpenSSL 1.0.2 as a minimum.
>
> All Tomcat Native releases from 1.1.34 onwards have indicated that users
> should use 1.2.x in preference to 1.1.x.
>
> The most recent release of 1.1.x (1.1.34) was released in December 2015.
> It is likely that 1.1.34 will be the final 1.1.x release unless a
> security vulnerability is discovered in 1.1.x that cannot be worked
> around without a new release.
>
> --
> The Apache Tomcat Team

+1. Looks good.
s/Windows/Microsoft Windows"/

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1809011 - in /tomcat/trunk: java/org/apache/catalina/servlets/DefaultServlet.java java/org/apache/catalina/webresources/AbstractFileResourceSet.java test/org/apache/catalina/webresour

2017-09-20 Thread Konstantin Kolinko
2017-09-20 20:09 GMT+03:00 Konstantin Kolinko :
> 2017-09-20 15:23 GMT+03:00  :
>> Author: markt
>> Date: Wed Sep 20 12:23:44 2017
>> New Revision: 1809011
>>
>> URL: http://svn.apache.org/viewvc?rev=1809011&view=rev
>> Log:
>> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61542
>> Partial fix for CVE-2017-12617
>> This moves a check from the Default servlet where it applied to GET, POST, 
>> HEAD and OPTIONS to the resources implementation where it applies to any 
>> method that expects the resource to exist (e.g.DELETE)
>> Still need to address the case where the resource does not exist (e.g. PUT)
>>
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
>> 
>> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>> 
>> tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java
>>
>> Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java 
>> (original)
>> +++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Wed 
>> Sep 20 12:23:44 2017
>> @@ -820,20 +820,6 @@ public class DefaultServlet extends Http
>>  return;
>>  }
>>
>> -// If the resource is not a collection, and the resource path
>> -// ends with "/" or "\", return NOT FOUND
>> -if (resource.isFile() && (path.endsWith("/") || 
>> path.endsWith("\\"))) {
>> -// Check if we're included so we can return the appropriate
>> -// missing resource name in the error
>> -String requestUri = (String) request.getAttribute(
>> -RequestDispatcher.INCLUDE_REQUEST_URI);
>> -if (requestUri == null) {
>> -requestUri = request.getRequestURI();
>> -}
>> -response.sendError(HttpServletResponse.SC_NOT_FOUND, 
>> requestUri);
>> -return;
>> -}
>> -
>>  boolean included = false;
>>  // Check if the conditions specified in the optional If headers are
>>  // satisfied.
>>
>> Modified: 
>> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
>> ==
>> --- 
>> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>>  (original)
>> +++ 
>> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>>  Wed Sep 20 12:23:44 2017
>> @@ -57,6 +57,14 @@ public abstract class AbstractFileResour
>>  name = "";
>>  }
>>  File file = new File(fileBase, name);
>> +
>> +// If the requested names ends in '/', the Java File API will 
>> return a
>> +// matching file if one exists. This isn't what we want as it is not
>> +// consistent with the Servlet spec rules for request mapping.
>> +if (file.isFile() && name.endsWith("/")) {
>
> I think this has to be
>
>if (name.endsWith("/") && !file.isDirectory())
>
> Two concerns:
> 1) performance:  do in-memory checks first and I/O performing ones later
> 2) "isFile()" tests whether "this is a normal file". The definition of
> "normal file" is OS-dependent.

My bad:

"if (... !file.isDirectory())" check would be wrong

I missed that isFile()/isDirectory() also checks for existence, and
there is "mustExist" flag in this method.

Thinking about

  if (name.endsWith("/") && file.exists() && !file.isDirectory())

it looks odd.

Falling back to

   if (name.endsWith("/") && file.isFile()) {

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1809011 - in /tomcat/trunk: java/org/apache/catalina/servlets/DefaultServlet.java java/org/apache/catalina/webresources/AbstractFileResourceSet.java test/org/apache/catalina/webresour

2017-09-20 Thread Konstantin Kolinko
2017-09-20 15:23 GMT+03:00  :
> Author: markt
> Date: Wed Sep 20 12:23:44 2017
> New Revision: 1809011
>
> URL: http://svn.apache.org/viewvc?rev=1809011&view=rev
> Log:
> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61542
> Partial fix for CVE-2017-12617
> This moves a check from the Default servlet where it applied to GET, POST, 
> HEAD and OPTIONS to the resources implementation where it applies to any 
> method that expects the resource to exist (e.g.DELETE)
> Still need to address the case where the resource does not exist (e.g. PUT)
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
> 
> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
> 
> tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java
>
> Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java 
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Wed 
> Sep 20 12:23:44 2017
> @@ -820,20 +820,6 @@ public class DefaultServlet extends Http
>  return;
>  }
>
> -// If the resource is not a collection, and the resource path
> -// ends with "/" or "\", return NOT FOUND
> -if (resource.isFile() && (path.endsWith("/") || 
> path.endsWith("\\"))) {
> -// Check if we're included so we can return the appropriate
> -// missing resource name in the error
> -String requestUri = (String) request.getAttribute(
> -RequestDispatcher.INCLUDE_REQUEST_URI);
> -if (requestUri == null) {
> -requestUri = request.getRequestURI();
> -}
> -response.sendError(HttpServletResponse.SC_NOT_FOUND, requestUri);
> -return;
> -}
> -
>  boolean included = false;
>  // Check if the conditions specified in the optional If headers are
>  // satisfied.
>
> Modified: 
> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
> ==
> --- 
> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>  (original)
> +++ 
> tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
>  Wed Sep 20 12:23:44 2017
> @@ -57,6 +57,14 @@ public abstract class AbstractFileResour
>  name = "";
>  }
>  File file = new File(fileBase, name);
> +
> +// If the requested names ends in '/', the Java File API will return 
> a
> +// matching file if one exists. This isn't what we want as it is not
> +// consistent with the Servlet spec rules for request mapping.
> +if (file.isFile() && name.endsWith("/")) {

I think this has to be

   if (name.endsWith("/") && !file.isDirectory())

Two concerns:
1) performance:  do in-memory checks first and I/O performing ones later
2) "isFile()" tests whether "this is a normal file". The definition of
"normal file" is OS-dependent.


> +return null;
> +}
> +

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1809025 - in /tomcat/trunk: java/org/apache/catalina/webresources/DirResourceSet.java test/org/apache/catalina/webresources/AbstractTestResourceSet.java webapps/docs/changelog.xml

2017-09-20 Thread Mark Thomas
On 20/09/17 14:04, Mark Thomas wrote:
> On 20/09/17 13:52, ma...@apache.org wrote:
>> Author: markt
>> Date: Wed Sep 20 12:52:47 2017
>> New Revision: 1809025
>>
>> URL: http://svn.apache.org/viewvc?rev=1809025&view=rev
>> Log:
>> Partial fix for CVE-2017-12617
>> This ensures that a path specified for creation of a file does not end in 
>> '/' since that is dropped by the File API.
> 
> I think the fix for 9.0.x is complete but I want to do some more testing
> around the edge cases to make sure. Additional testing welcome.
> 
> Once we are satisfied the fix is complete, I'll start back-porting.

I've done some testing to see how Windows behaves with all possible
characters at the end of a file name.

The behaviour falls into 1 of four options:
a) getCanonicalPath() throws an IOException
b) getCanonicalPath() != getAbsolutePath()
c) getCanonicalPath() == getAbsolutePath() and the file name is
   unaltered from that provided.
d) getCanonicalPath() == getAbsolutePath() but the file name is
   unaltered from that provided.

The only characters that trigger d) are '/' and '\'.

Before today, cases a), b) and c) were handled correctly.

On Windows '\' is always converted to '/' so only '/' needs to be handled.

The patches I made today handle '/' so I believe that the fix is complete.

An extra pair of eyes or two on the proposed patch and the thinking
above would be appreciated.

At this point, I'm thinking back-port tomorrow morning and then tag and
release.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

Guillermo Grandes  changed:

   What|Removed |Added

 CC||guillermo.gran...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

--- Comment #6 from Mark Thomas  ---
Nope. That will fail for directories where the trailing '/' is provided since
it will have been removed from the absolute and canonical paths.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

--- Comment #5 from Mark Thomas  ---
Maybe a better check would be that, given the path will already have been
normalised, if the the absolute path ends with the given name.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

--- Comment #4 from Remy Maucherat  ---
Well, every time there's surprising normalization, it causes security issues so
it's a big API mistake :) The normalization of the input path should only
happen for getCanonicalPath, that's the whole point.

Of course, I probably knew about this behavior a while ago then since there's
the '/' check for get. On the plus side the issue is not that serious (readonly
needed) so it's not the end of the world.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1809025 - in /tomcat/trunk: java/org/apache/catalina/webresources/DirResourceSet.java test/org/apache/catalina/webresources/AbstractTestResourceSet.java webapps/docs/changelog.xml

2017-09-20 Thread Mark Thomas
On 20/09/17 13:52, ma...@apache.org wrote:
> Author: markt
> Date: Wed Sep 20 12:52:47 2017
> New Revision: 1809025
> 
> URL: http://svn.apache.org/viewvc?rev=1809025&view=rev
> Log:
> Partial fix for CVE-2017-12617
> This ensures that a path specified for creation of a file does not end in '/' 
> since that is dropped by the File API.

I think the fix for 9.0.x is complete but I want to do some more testing
around the edge cases to make sure. Additional testing welcome.

Once we are satisfied the fix is complete, I'll start back-porting.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

--- Comment #3 from Mark Thomas  ---
The File API certainly isn't helping.

When a file named '/test.jsp' exists '/test.jsp/' -> '/test.jsp' is surprising.
Less so when it doesn't exist because it could be referring to a directory and
both forms are valid for a directory.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1809025 - in /tomcat/trunk: java/org/apache/catalina/webresources/DirResourceSet.java test/org/apache/catalina/webresources/AbstractTestResourceSet.java webapps/docs/changelog.xml

2017-09-20 Thread markt
Author: markt
Date: Wed Sep 20 12:52:47 2017
New Revision: 1809025

URL: http://svn.apache.org/viewvc?rev=1809025&view=rev
Log:
Partial fix for CVE-2017-12617
This ensures that a path specified for creation of a file does not end in '/' 
since that is dropped by the File API.

Modified:
tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java

tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java?rev=1809025&r1=1809024&r2=1809025&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/webresources/DirResourceSet.java Wed 
Sep 20 12:52:47 2017
@@ -217,6 +217,12 @@ public class DirResourceSet extends Abst
 return false;
 }
 
+// write() is meant to create a file so ensure that the path doesn't
+// end in '/'
+if (path.endsWith("/")) {
+return false;
+}
+
 File dest = null;
 String webAppMount = getWebAppMount();
 if (path.startsWith(webAppMount)) {

Modified: 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java?rev=1809025&r1=1809024&r2=1809025&view=diff
==
--- 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java 
(original)
+++ 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java 
Wed Sep 20 12:52:47 2017
@@ -447,14 +447,8 @@ public abstract class AbstractTestResour
 public final void testWriteDirB() {
 WebResource d1 = resourceRoot.getResource(getMount() + "/d1/");
 InputStream is = new ByteArrayInputStream("test".getBytes());
-if (d1.exists()) {
+if (d1.exists() || d1.isVirtual()) {
 Assert.assertFalse(resourceRoot.write(getMount() + "/d1/", is, 
false));
-} else if (d1.isVirtual()) {
-Assert.assertTrue(resourceRoot.write(
-getMount() + "/d1/", is, false));
-File file = new File(getBaseDir(), "d1");
-Assert.assertTrue(file.exists());
-Assert.assertTrue(file.delete());
 } else {
 Assert.fail("Unhandled condition in unit test");
 }
@@ -490,6 +484,14 @@ public abstract class AbstractTestResour
 }
 }
 
+@Test
+public final void testWriteWithTrailingSlash() {
+String newFileName = getNewFileName() + "/";
+InputStream is = new ByteArrayInputStream("test".getBytes());
+Assert.assertFalse(resourceRoot.write(
+getMount() + "/" + newFileName, is, false));
+}
+
 protected abstract String getNewFileName();
 
 // -- 
getCanonicalPath()

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1809025&r1=1809024&r2=1809025&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Sep 20 12:52:47 2017
@@ -45,6 +45,15 @@
   issues do not "pop up" wrt. others).
 -->
 
+  
+
+  
+61542: Fix CVE-2017-12617 and prevent JSPs from being
+uploaded via a specially crafted request when HTTP PUT was enabled.
+(markt)
+  
+
+  
   
 
   



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] Apache Tomcat Remote Code Execution via JSP Upload bypass

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

Remy Maucherat  changed:

   What|Removed |Added

Summary|none|Apache Tomcat Remote Code
   ||Execution via JSP Upload
   ||bypass

--- Comment #2 from Remy Maucherat  ---
Hum, actually this looks like a File API issue. With the (correct) /1.jsp/ path
input, (new File(name)).getPath() just strips the trailing '/', and of course
getAbsolutePath, which is used for the safety net check, also does it. There's
a problem there.

Restoring the BZ name since it's pointless.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1809011 - in /tomcat/trunk: java/org/apache/catalina/servlets/DefaultServlet.java java/org/apache/catalina/webresources/AbstractFileResourceSet.java test/org/apache/catalina/webresources/

2017-09-20 Thread markt
Author: markt
Date: Wed Sep 20 12:23:44 2017
New Revision: 1809011

URL: http://svn.apache.org/viewvc?rev=1809011&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61542
Partial fix for CVE-2017-12617
This moves a check from the Default servlet where it applied to GET, POST, HEAD 
and OPTIONS to the resources implementation where it applies to any method that 
expects the resource to exist (e.g.DELETE)
Still need to address the case where the resource does not exist (e.g. PUT)

Modified:
tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java

tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java

Modified: tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java Wed Sep 
20 12:23:44 2017
@@ -820,20 +820,6 @@ public class DefaultServlet extends Http
 return;
 }
 
-// If the resource is not a collection, and the resource path
-// ends with "/" or "\", return NOT FOUND
-if (resource.isFile() && (path.endsWith("/") || path.endsWith("\\"))) {
-// Check if we're included so we can return the appropriate
-// missing resource name in the error
-String requestUri = (String) request.getAttribute(
-RequestDispatcher.INCLUDE_REQUEST_URI);
-if (requestUri == null) {
-requestUri = request.getRequestURI();
-}
-response.sendError(HttpServletResponse.SC_NOT_FOUND, requestUri);
-return;
-}
-
 boolean included = false;
 // Check if the conditions specified in the optional If headers are
 // satisfied.

Modified: 
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java 
Wed Sep 20 12:23:44 2017
@@ -57,6 +57,14 @@ public abstract class AbstractFileResour
 name = "";
 }
 File file = new File(fileBase, name);
+
+// If the requested names ends in '/', the Java File API will return a
+// matching file if one exists. This isn't what we want as it is not
+// consistent with the Servlet spec rules for request mapping.
+if (file.isFile() && name.endsWith("/")) {
+return null;
+}
+
 if (!mustExist || file.canRead()) {
 
 if (getRoot().getAllowLinking()) {

Modified: 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java?rev=1809011&r1=1809010&r2=1809011&view=diff
==
--- 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java 
(original)
+++ 
tomcat/trunk/test/org/apache/catalina/webresources/AbstractTestResourceSet.java 
Wed Sep 20 12:23:44 2017
@@ -132,6 +132,13 @@ public abstract class AbstractTestResour
 }
 
 @Test
+public final void testGetResourceFileWithTrailingSlash() {
+WebResource webResource =
+resourceRoot.getResource(getMount() + "/d1/d1-f1.txt/");
+Assert.assertFalse(webResource.exists());
+}
+
+@Test
 public final void testGetResourceCaseSensitive() {
 WebResource webResource =
 resourceRoot.getResource(getMount() + "/d1/d1-F1.txt");



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61545] ProxyConnection.invoke() does not handle javax.sql.PooledConnection method calls

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61545

Nils Winkler  changed:

   What|Removed |Added

 CC||nils.wink...@fisglobal.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61542] none

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61542

--- Comment #1 from Mark Thomas  ---
This additional issue has been confirmed and CVE-2017-12617 has been allocated.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Preventing security reports on Bugzilla

2017-09-20 Thread Emmanuel Bourg
Hi,

What about creating a 'security' component for Tomcat in Bugzilla with
an all caps description explaining it should go to
secur...@tomcat.apache.org instead? This may prevent some accidental
reports sent to Bugzilla.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 61545] New: ProxyConnection.invoke() does not handle javax.sql.PooledConnection method calls

2017-09-20 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=61545

Bug ID: 61545
   Summary: ProxyConnection.invoke() does not handle
javax.sql.PooledConnection method calls
   Product: Tomcat Modules
   Version: unspecified
  Hardware: PC
OS: Mac OS X 10.1
Status: NEW
  Severity: normal
  Priority: P2
 Component: jdbc-pool
  Assignee: dev@tomcat.apache.org
  Reporter: nils.wink...@fisglobal.com
  Target Milestone: ---

I've found an issue with tomcat-jdbc and XA connections, where Tomcat Pool's
ProxyConnection class does not handle invocations done using the
javax.sql.PooledConnection interface.

I'm seeing this with Tomcat v7.0.78, but the same code is used in Tomcat's 8.5
codebase. My use case involves the following setup:

* Database: MySQL, PostgreSQL or Oracle - same issue on all three of them.
* Tomcat Pool is used to define a context-specific XADataSource to be used by
the web application.
* The web application uses Spring for setup, and Jencks as an XA transaction
manager.
* Jencks uses tranql-connector under the hood (version 1.7 or 1.8 show the same
behavior).

The issue can be seen from Tranql's code:
http://grepcode.com/file/repo1.maven.org/maven2/org.tranql/tranql-connector/1.8/org/tranql/connector/jdbc/ManagedXAConnection.java?av=f#55

Here, tranql gets an XAConnection from the pool (Tomcat Pool in this case) and
tries to set a ConnectionEventListener on the connection:

   this.xaConnection = xaConnection;
 xaConnection.addConnectionEventListener(new ConnectionEventListener()
{
 public void connectionClosed(ConnectionEvent event) {
 //we should be handling this independently
 }

 public void connectionErrorOccurred(ConnectionEvent event)
{
 Exception e = event.getSQLException();
 unfilteredConnectionError(e);
 }
 });

The xaConnection.addConnectionEventListener gets propagated through the
JdbcInterceptor hierarchy in Tomcat Pool, all the way to the
ProxyConnection.invoke() method:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ProxyConnection.java?view=markup#l92

Since the addConnectionEventListener method is defined on
javax.sql.PooledConnection, none of the if-clauses in the
ProxyConnection.invoke() method match and the code finally ends up in line 126,
where the "addConnectionEventListener" is invoked on the java.sql.Connection
instance, which of course does not implement the javax.sql.PooledConnection
interface:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ProxyConnection.java?view=markup#l126

PooledConnection poolc = connection;
if (poolc!=null) {
return method.invoke(poolc.getConnection(),args);
} else {
throw new SQLException("Connection has already been closed.");
}

The error that is shown looks like this:

Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:126)
at
org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:109)
at
org.apache.tomcat.jdbc.pool.interceptor.AbstractCreateStatementInterceptor.invoke(AbstractCreateStatementInterceptor.java:80)
at
org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:109)
at
org.apache.tomcat.jdbc.pool.interceptor.AbstractCreateStatementInterceptor.invoke(AbstractCreateStatementInterceptor.java:80)
at
org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:109)
at
org.apache.tomcat.jdbc.pool.interceptor.ConnectionState.invoke(ConnectionState.java:153)
at
org.apache.tomcat.jdbc.pool.JdbcInterceptor.invoke(JdbcInterceptor.java:109)
at
org.apache.tomcat.jdbc.pool.TrapException.invoke(TrapException.java:41)
... 111 more

In the case of Oracle, the "poolc.getConnection()" call returns an instance of
oracle.jdbc.driver.LogicalConnection, which does not implement
javax.sql.PooledConnection.

Since javax.sql.XAConnection extends the javax.sql.PooledConnection interface,
the reason for the error stems from the check in line 106 of
ProxyConnection.java:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ProxyConnection.java?view=markup#l106

} else if (method.getDeclaringClass().equals(XAConnection.class)) {
try {
return method.invoke(connection.getXAConnection(),args);
 

[SECURITY] Apache Tomcat Possible additional RCE via JSP upload

2017-09-20 Thread Mark Thomas
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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Tagging Tomcat 7/8.0

2017-09-20 Thread Violeta Georgieva
2017-09-20 10:09 GMT+03:00 Mark Thomas :
>
> On 19/09/17 14:32, Violeta Georgieva wrote:
> > Hi,
> >
> > I'm planning to start preparing Tomcat 7/8.0 for a release later today.
> > If you would like to include something in addition, please reply here.
>
> Please delay those tags for BZ 61542

ok

>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>


Re: Tagging Tomcat 7/8.0

2017-09-20 Thread Mark Thomas
On 19/09/17 14:32, Violeta Georgieva wrote:
> Hi,
> 
> I'm planning to start preparing Tomcat 7/8.0 for a release later today.
> If you would like to include something in addition, please reply here.

Please delay those tags for BZ 61542

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org