[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #13 from Guido Jäkel --- (In reply to Rainer Jung from comment #11) > Hi Guido, > > I didn't have the time to follow the discussoin in detail, but would using > > AllowEncodedSlashes NoDecode > > help in any way? > Dear Rainer, i would you *please* to take the time to read it carefully. This "NoDecode" is a prerequisite at all. yours Guido -- 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #12 from Guido Jäkel --- Dear Mark, I miss something important about the "directory traversal": If is set "AllowEncodedSlashes NoEncode" and "JkOptions +ForwardURICompatUnparsed", then with the example setup, the URI /examples/foo/..%2F../doc is also passed as is to the backend ad it's also up to the backend to do the right thing, i.e. not to treat '%2F' in a path element as a '/'. Therefore, my patch don't "introduce" this "challenge" for the backend, it just prevent mod_jk from breaking the URL with "JkOptions +ForwardURIProxy". -- 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
--- Comment #11 from Rainer Jung ---
Hi Guido,
I didn't have the time to follow the discussoin in detail, but would using
AllowEncodedSlashes NoDecode
help in any way?
I think we as just one module can not simply define our special sequence as
e,.g. %%. But if you want to do experiments, you can check for the current
AllowEncodedSlashes settings like this:
...
#include http_core.h
...
core_dir_config *cfg;
cfg = (core_dir_config *)ap_get_core_module_config(r->per_dir_config);
if (!cfg->allow_encoded_slashes) {
/* AllowEncodedSlashes Off */
} else if (!cfg->decode_encoded_slashes) {
/* AllowEncodedSlashes Nodecode */
} else {
/* AllowEncodedSlashes On */
}
The snippet does not work in jk_canonenc, because that function is a standalone
function called by Apache httpd and by IIS, so it does not know about Apache
specifics. But you can use it for example in mod_jk.c before calling
jk_canonenc there.
--
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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Guido Jäkel changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #10 from Guido Jäkel ---
(In reply to Mark Thomas from comment #9)
> (In reply to Guido Jäkel from comment #8)
> > To point this out: You see a "directory traversal" issue IF
> > AllowEncodedSlashes is OFF?
>
> Yes.
>
> > Maybe here, in this function. But then, an URL
> > containing slashes will rejected by the http anyway.
>
> JkMount /examples/*
>
> URI /examples/foo/..%252F../docs
>
> Now gets passed as /examples/foo/..%2F../docs
>
> What happens then depends on what back-end the URI is passed to and how that
> back-end is configured. Some will reject it. Some will process it. For those
> that process it, this is a directory traversal.
I fully agree: It's in the concern of the backend - in the same way it's in the
concern of the httpd frontend parser to deal with it.
> What you are asking for is logically impossible. If mod_jk sees the sequence
> "%2F" it has no way to determine if this is the result of decoding "%252F"
> or not decoding "%2F". Therefore it cannot correctly reverse the encoding.
Maybe this shows us the core problem and and a solution: "AllowEncodedSlashes"
must *replace* the encoded slash ('%2F') by a *distinguishable* special
representation and this special representation have to bee re-encoded later
(before any proxying by mod_jk or others) to the encoded slash.
Perhaps this special representation might be coded as an "illegal percent
encoding" using other digits as the hexadecimals, e.g. '%%/'
Mark, may you please support me by a code snipped to check the actual value of
"AllowEncodedSlashes" within the mod_jk's jk_canonenc function or in the
context of it's caller?
--
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 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #17 from Konstantin Kolinko --- Please add the following line to your catalina.properties file: org.apache.catalina.connector.RECYCLE_FACADES=true as documented at https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Troubleshooting_unexpected_Response_state_problems -- 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 Mark Thomas changed: What|Removed |Added Resolution|FIXED |WONTFIX --- Comment #9 from Mark Thomas --- (In reply to Guido Jäkel from comment #8) > To point this out: You see a "directory traversal" issue IF > AllowEncodedSlashes is OFF? Yes. > Maybe here, in this function. But then, an URL > containing slashes will rejected by the http anyway. JkMount /examples/* URI /examples/foo/..%252F../docs Now gets passed as /examples/foo/..%2F../docs What happens then depends on what back-end the URI is passed to and how that back-end is configured. Some will reject it. Some will process it. For those that process it, this is a directory traversal. > Yes, this is the core point. I'm not familiar with this software, but (IMHO) > there CANNOT a '%252F' appear here. I see no reason why a user agent would be unable to present "%252F". Keep in mind that any solution has to be completely generic, not specific to any one use case and there may well be an ID scheme somewhere where a valid, unencoded ID includes the sequence "%2F" which would then be encoded as "%252F" when it appears in the path. > > The only viable option is to use: > > > > JkOptions +ForwardURICompatUnparsed > > > > which has the significant disadvantage that mod_rewrite etc. cannot be used. > ... and is a non-option for us because we need exactly this other things, > too. And in the meanwhile, it's urgent. What you are asking for is logically impossible. If mod_jk sees the sequence "%2F" it has no way to determine if this is the result of decoding "%252F" or not decoding "%2F". Therefore it cannot correctly reverse the encoding. -- 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: Help with windows tcnative crash
On 22/08/18 14:47, Mark Thomas wrote: > On 22/08/18 13:41, Christopher Schultz wrote: >> All, >> >> Can someone take a quick look at my analysis of the tcnative crash >> described here: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 >> >> Without a debugger in Windows, I don't think I'll be able to find the >> line of code where the problem is. There is an offset into the DLL where >> the error is happening and I'm assuming that if you have Visual Studio, >> you can open the binary DLL and the source and see the mapping between >> the two and find where this failure is happening much more easily than I >> can via code inspection. > > Any Apache committer can request a free MSDN license which includes > Azure credits and licenses for just about any MS software including > Visual Studio. I have one that I use for building Tomcat Native for > Windows and for ISAPI testing (I have a VM for each of the current > supported Windows OSes each with IIS installed). > > I don't tend to use Visual Studio but I think I have a copy installed on > a VM somewhere. Let me have a look. I'm not that familiar with using > Visual Studio but I'll see if I can figure out which line number we need > to be looking at. Ah. Jean-Frederic built 1.2.17 and he'll have the pdb files we'll need to do this. You'll also need ildasm.exe If you have set up the Native build environment as per the wiki you should already have this tool in: C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin >> Unless there is some native stack-info missing, the fault is actually in >> sendbb() It is sendb()... >> which doesn't have much in the way of data-writes in it at >> all (and it looks like the segfault occurs while trying to *write* to an >> out-of-bounds address rather than reading one). Looks like it is crashing during the HTTP/2 close. I wonder if the underlying socket has been closed but Tomcat is still trying to write. It should be possible to force that with a debugger. If that is the root cause, it should crash just as easily on Linux as Windows. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Help with windows tcnative crash
Am 22.08.2018 um 15:47 schrieb Mark Thomas: On 22/08/18 13:41, Christopher Schultz wrote: All, Can someone take a quick look at my analysis of the tcnative crash described here: https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 Without a debugger in Windows, I don't think I'll be able to find the line of code where the problem is. There is an offset into the DLL where the error is happening and I'm assuming that if you have Visual Studio, you can open the binary DLL and the source and see the mapping between the two and find where this failure is happening much more easily than I can via code inspection. Any Apache committer can request a free MSDN license which includes Azure credits and licenses for just about any MS software including Visual Studio. I have one that I use for building Tomcat Native for Windows and for ISAPI testing (I have a VM for each of the current supported Windows OSes each with IIS installed). I don't tend to use Visual Studio but I think I have a copy installed on a VM somewhere. Let me have a look. I'm not that familiar with using Visual Studio but I'll see if I can figure out which line number we need to be looking at. Mark Unless there is some native stack-info missing, the fault is actually in sendbb() which doesn't have much in the way of data-writes in it at all (and it looks like the segfault occurs while trying to *write* to an out-of-bounds address rather than reading one). Thanks, -chris Not totally sure, but I think if you have a minidump from the crash, then visual studio can show you symbols from windows DLLs (loading the symbols from an MS symbol server). But for our own code one would need to run the dll with installed pdb (debug symbol) files which can be generated during building the code using a debug target in stead of a release target. Those pdb files typically get installed in the same directory as the original dll. I doubt (but I'm not sure), that you can create a pdb later and pass it to Visual Studio to resolve the symbols at analyze time. I might be wrong though. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Help with windows tcnative crash
On 22/08/18 13:41, Christopher Schultz wrote: > All, > > Can someone take a quick look at my analysis of the tcnative crash > described here: > https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 > > Without a debugger in Windows, I don't think I'll be able to find the > line of code where the problem is. There is an offset into the DLL where > the error is happening and I'm assuming that if you have Visual Studio, > you can open the binary DLL and the source and see the mapping between > the two and find where this failure is happening much more easily than I > can via code inspection. Any Apache committer can request a free MSDN license which includes Azure credits and licenses for just about any MS software including Visual Studio. I have one that I use for building Tomcat Native for Windows and for ISAPI testing (I have a VM for each of the current supported Windows OSes each with IIS installed). I don't tend to use Visual Studio but I think I have a copy installed on a VM somewhere. Let me have a look. I'm not that familiar with using Visual Studio but I'll see if I can figure out which line number we need to be looking at. Mark > > Unless there is some native stack-info missing, the fault is actually in > sendbb() which doesn't have much in the way of data-writes in it at > all (and it looks like the segfault occurs while trying to *write* to an > out-of-bounds address rather than reading one). > > Thanks, > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Help with windows tcnative crash
All, Can someone take a quick look at my analysis of the tcnative crash described here: https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 Without a debugger in Windows, I don't think I'll be able to find the line of code where the problem is. There is an offset into the DLL where the error is happening and I'm assuming that if you have Visual Studio, you can open the binary DLL and the source and see the mapping between the two and find where this failure is happening much more easily than I can via code inspection. Unless there is some native stack-info missing, the fault is actually in sendbb() which doesn't have much in the way of data-writes in it at all (and it looks like the segfault occurs while trying to *write* to an out-of-bounds address rather than reading one). Thanks, -chris signature.asc Description: OpenPGP digital signature
[Bug 57946] Configuration example for mod_jk should be updated to follow Apache 2.4 syntax scheme
https://bz.apache.org/bugzilla/show_bug.cgi?id=57946 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Thomas --- Fixed in 1.2.x for 1.2.44 onwards. -- 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: r1838632 - in /tomcat/jk/trunk: conf/httpd-jk.conf xdocs/common_howto/loadbalancers.xml xdocs/common_howto/workers.xml xdocs/jk2/vhosthowto.xml xdocs/miscellaneous/changelog.xml xdocs/webs
Author: markt Date: Wed Aug 22 12:24:46 2018 New Revision: 1838632 URL: http://svn.apache.org/viewvc?rev=1838632&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=57946 Update the documentation to use httpd 2.4.x style access control directives. Modified: tomcat/jk/trunk/conf/httpd-jk.conf tomcat/jk/trunk/xdocs/common_howto/loadbalancers.xml tomcat/jk/trunk/xdocs/common_howto/workers.xml tomcat/jk/trunk/xdocs/jk2/vhosthowto.xml tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml tomcat/jk/trunk/xdocs/webserver_howto/apache.xml Modified: tomcat/jk/trunk/conf/httpd-jk.conf URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/httpd-jk.conf?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/conf/httpd-jk.conf (original) +++ tomcat/jk/trunk/conf/httpd-jk.conf Wed Aug 22 12:24:46 2018 @@ -80,16 +80,12 @@ LoadModule jk_module modules/mod_jk.so # Inside Location we can omit the URL in JkMount JkMount jk-status -Order deny,allow -Deny from all -Allow from 127.0.0.1 +Require ip 127.0.0.1 # Inside Location we can omit the URL in JkMount JkMount jk-manager -Order deny,allow -Deny from all -Allow from 127.0.0.1 +Require ip 127.0.0.1 # If you want to put all mounts into an external file Modified: tomcat/jk/trunk/xdocs/common_howto/loadbalancers.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/common_howto/loadbalancers.xml?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/xdocs/common_howto/loadbalancers.xml (original) +++ tomcat/jk/trunk/xdocs/common_howto/loadbalancers.xml Wed Aug 22 12:24:46 2018 @@ -222,9 +222,7 @@ HTTP Servers use: # Enable the JK manager access from localhost onlyJkMount jkstatus -Order deny,allow -Deny from all -Allow from 127.0.0.1 +Require ip 127.0.0.1 Modified: tomcat/jk/trunk/xdocs/common_howto/workers.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/common_howto/workers.xml?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/xdocs/common_howto/workers.xml (original) +++ tomcat/jk/trunk/xdocs/common_howto/workers.xml Wed Aug 22 12:24:46 2018 @@ -301,9 +301,7 @@ HTTP Servers use: # Enable the JK manager access from localhost only JkMount jkstatus -Order deny,allow -Deny from all -Allow from 127.0.0.1 +Require ip 127.0.0.1 Modified: tomcat/jk/trunk/xdocs/jk2/vhosthowto.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/jk2/vhosthowto.xml?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/xdocs/jk2/vhosthowto.xml (original) +++ tomcat/jk/trunk/xdocs/jk2/vhosthowto.xml Wed Aug 22 12:24:46 2018 @@ -566,8 +566,7 @@ DirectoryIndex index.html index.jsp -Order allow,deny -Deny from all +Require all denied Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Wed Aug 22 12:24:46 2018 @@ -49,6 +49,10 @@ since there has not been a supported version of Netware available for over five years. (markt) + +57946: Apache: Update the documentation to use httpd 2.4.x +style access control directives. (markt) + 58287: Common: Use Local, rather than Global, mutexs on Windows to better support multi-user environments. (markt) Modified: tomcat/jk/trunk/xdocs/webserver_howto/apache.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/webserver_howto/apache.xml?rev=1838632&r1=1838631&r2=1838632&view=diff == --- tomcat/jk/trunk/xdocs/webserver_howto/apache.xml (original) +++ tomcat/jk/trunk/xdocs/webserver_howto/apache.xml Wed Aug 22 12:24:46 2018 @@ -845,8 +845,7 @@ directive when jk and alias/userdir URLs Options Indexes MultiViews AllowOverride None - Order allow,deny - Allow from all + Require all granted JkMount /* myssys-xxx - To unsubscribe, e-mail: dev-unsubscr.
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 Guido Jäkel changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #8 from Guido Jäkel --- (In reply to Mark Thomas from comment #7) Thank you a lot for discussion! > The proposed patch enables a directory traversal vulnerability with the > default configuration. Therefore, it can't be applied in its current form. > > Even if the patch's behaviour is restricted to only be enabled with: > > AllowEncodedSlashes NoDecode > [...] To point this out: You see a "directory traversal" issue IF AllowEncodedSlashes is OFF? Maybe here, in this function. But then, an URL containing slashes will rejected by the http anyway. Please explain, if i'm wrong with this. > mod_jk needs to differentiate between %252F and %2F in the original URI to > correctly re-encode the processed (mod_rewrite etc.) URI which it is not > going to be able to do in all circumstances. The problem is that both "%252F > and "%2F" are identical in decoded form if "%2F" is not decoded and there is > no way to tell them apart. Yes, this is the core point. I'm not familiar with this software, but (IMHO) there CANNOT a '%252F' appear here. And if, then it's garbage-in because there incoming URL can be expected to be fully decoded here. If you think (or even know), this CAN and is valid -- e.g. for some other part of the URL than the path elements section, THEN my suggestion may be extended to have the "syntactical knowledge" to act only on path elements. > The only viable option is to use: > > JkOptions +ForwardURICompatUnparsed > > which has the significant disadvantage that mod_rewrite etc. cannot be used. ... and is a non-option for us because we need exactly this other things, too. And in the meanwhile, it's urgent. -- 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 59897] Buffer Overflow in FD_SET in nb_connect (jk_connect.c) leading to apache2 crash
https://bz.apache.org/bugzilla/show_bug.cgi?id=59897 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Thomas --- Many thanks for the patch. Applied to 1.2.x for 1.2.44 onwards. -- 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: r1838631 - in /tomcat/jk/trunk: native/common/jk_connect.c xdocs/miscellaneous/changelog.xml
Author: markt
Date: Wed Aug 22 12:13:07 2018
New Revision: 1838631
URL: http://svn.apache.org/viewvc?rev=1838631&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=59897
Apache: Use poll rather than select to avoid the limitations of select
triggering an httpd crash.
Patch provided by Koen Wilde.
Modified:
tomcat/jk/trunk/native/common/jk_connect.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/jk/trunk/native/common/jk_connect.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1838631&r1=1838630&r2=1838631&view=diff
==
--- tomcat/jk/trunk/native/common/jk_connect.c (original)
+++ tomcat/jk/trunk/native/common/jk_connect.c Wed Aug 22 12:13:07 2018
@@ -231,9 +231,75 @@ static int nb_connect(jk_sock_t sd, jk_s
JK_TRACE_EXIT(l);
return 0;
}
+#elif defined(HAVE_POLL_H)
+/* POSIX implementation using poll(2) */
+/** Non-blocking socket connect
+ * @param sd socket to connect
+ * @param addr address to connect to
+ * @param source optional source address
+ * @param timeout connect timeout in seconds
+ * (<=0: no timeout=blocking)
+ * @param llogger
+ * @return -1: some kind of error occured
+ * 0: success
+ */
+static int nb_connect(jk_sock_t sd, jk_sockaddr_t *addr, jk_sockaddr_t *source,
+ int timeout, jk_logger_t *l) {
+int rc = 0;
+char buf[64];
+
+JK_TRACE_ENTER(l);
+
+if (source != NULL) {
+if (bind(sd, (const struct sockaddr *)&source->sa.sin, source->salen))
{
+JK_GET_SOCKET_ERRNO();
+jk_log(l, JK_LOG_ERROR,
+ "error during source bind on socket %d [%s] (errno=%d)", sd,
+ jk_dump_hinfo(source, buf, sizeof(buf)), errno);
+}
+}
+if (timeout > 0) {
+if (sononblock(sd)) {
+JK_TRACE_EXIT(l);
+return -1;
+}
+}
+do {
+rc = connect(sd, (const struct sockaddr *)&addr->sa.sin, addr->salen);
+} while (rc == -1 && errno == EINTR);
+
+if ((rc == -1) && (errno == EINPROGRESS || errno == EALREADY)
+ && (timeout > 0)) {
+struct pollfd pfd;
+socklen_t rclen = (socklen_t)sizeof(rc);
+pfd.fd = sd;
+pfd.events = POLLOUT;
+rc = poll(&pfd, 1, timeout * 1000);
+if (rc <= 0) {
+/* Save errno */
+int err = errno;
+soblock(sd);
+errno = err;
+JK_TRACE_EXIT(l);
+return -1;
+}
+rc = 0;
+#ifdef SO_ERROR
+ if (getsockopt(sd, SOL_SOCKET, SO_ERROR,
+(char *)&rc, &rclen) < 0 || rc) {
+if (rc)
+errno = rc;
+rc = -1;
+}
+#endif
+}
+soblock(sd);
+JK_TRACE_EXIT(l);
+return rc;
+}
#else
-/* POSIX implementation */
+/* POSIX implementation using select(2) */
/** Non-blocking socket connect
* @param sd socket to connect
* @param addr address to connect to
Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1838631&r1=1838630&r2=1838631&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Wed Aug 22 12:13:07 2018
@@ -54,6 +54,11 @@
Windows to better support multi-user environments. (markt)
+59897: Apache: Use poll rather than select to avoid the
+limitations of select triggering an httpd crash. Patch provided by Koen
+Wilde. (markt)
+
+
60745: ISAPI: Remove the check that rejects requests that
contain path segments that match WEB-INF or META-INF as it duplicates
a check that Tomcat performs and, because ISAPI does not have
visibility
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 Mark Thomas changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #7 from Mark Thomas --- The proposed patch enables a directory traversal vulnerability with the default configuration. Therefore, it can't be applied in its current form. Even if the patch's behaviour is restricted to only be enabled with: AllowEncodedSlashes NoDecode mod_jk needs to differentiate between %252F and %2F in the original URI to correctly re-encode the processed (mod_rewrite etc.) URI which it is not going to be able to do in all circumstances. The problem is that both "%252F and "%2F" are identical in decoded form if "%2F" is not decoded and there is no way to tell them apart. The only viable option is to use: JkOptions +ForwardURICompatUnparsed which has the significant disadvantage that mod_rewrite etc. cannot be used. Unfortunately, I don't see any other alternatives at this point. -- 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
--- Comment #6 from Guido Jäkel ---
(In reply to Mark Thomas from comment #5)
> Thanks. I see what you are trying to do now. This is going to be an
> interesting problem to solve. I suspect that it will require fixes / changes
> in multiple components.
For my requirements, no other fixes as the attached patch to mod_jk are needed.
I don't take a look on Tomcat because i'm using Wildfly as the backend. Also,
i', using AJP as the transport and i don't look on HTTP here.
> For those following along, take a look at the examples here:
> https://restfulapi.net/resource-naming/
IMHO the RFC states that an URL/URI consist of (others and) path elements. This
path elements are separated/delimited by a slash character ('/'). Therefore, if
the payload of a path element contain a slash, this MUST be percent-encoded.
The current semantic behavior of mod_jk is to escape "everything that need
this". And that's correct for the most cases. The Apache httpd framework have
already "normalized" the URL many steps before. If mod_jk find a special
character here, it have to encode it for a proper transport to the downstream
server. If there is a single percent sign here (after decoding by the httpd!),
it have to be escaped to '%25'.
The exception here is that the httpd is instructed (by AllowEncodedSlashes
NoDecode) to keep some slashes (only within path elements) undecoded. There is
no special "information tagging" about this, but the only source for the
apperance of the character sequence '%2F' at this point within the mod_jk code
is that it is the result of this intended unescaping of a slash. Note that this
holds only for this entity 'slash' used as the path element separator and not
for and %XX at common.
For the convenience to see what i'm talking about, I embed here the content of
the short patch:
--- native/common/jk_url.c.20150101-212250 2015-01-01 21:22:50.0
+0100
+++ native/common/jk_url.c 2018-06-27 09:12:28.250361091 +0200
@@ -88,6 +88,11 @@
y[j] = ch;
continue;
}
+/* don't double-escape a following '%2F' ('/'), just pass the '%' and continue
*/
+if (ch == '%' && x[i+1] == '2' && strchr("fF", x[i+2])) {
+y[j] = ch;
+continue;
+}
/* recode it, if necessary */
if (!jk_isalnum(ch) && !strchr(allowed, ch)) {
if (j+2
[Bug 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #5 from Mark Thomas --- Thanks. I see what you are trying to do now. This is going to be an interesting problem to solve. I suspect that it will require fixes / changes in multiple components. For those following along, take a look at the examples here: https://restfulapi.net/resource-naming/ The issue at hand is that if a resource ID contains a "/" it needs to be encoded else the URI will not be interpreted correctly. Other relevant information: RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT equivalent to the decoded form. That begs the question at what point - if any - should Tomcat decode these sequences. -- 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
