Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize
On Mon, Jul 20, 2020, 10:24 Ruediger Pluem wrote: > > > On 7/20/20 4:45 PM, Yann Ylavic wrote: > > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener wrote: > >> > >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem > wrote: > >>> > >>> > >>> > >>> On 6/24/20 1:27 PM, Eric Covener wrote: > > > > ProxyMappingDecoded is not needed anymore (and was removed). > > The mapping= tells mod_proxy at which stage ([pre_]translate) it > > should map the request path. > +1 > > >>> > >>> Getting back to an old topic. Shouldn't we have a directive similar to > >>> AllowEncodedSlashes that allows us to block URI's that contain > >>> URL fragments like /.; and /..; in order to avoid that someone plays > >>> silly games that bypass Location settings and RewriteRules > >>> that might be used with a servlet engine in the backend? Happy > >>> to have that set to a default that allows /.; and /..;. > >> > >> +, but I'd want the safer default. > > > > Is this something we should care about outside the proxy mapping=servlet > case? > > In the other cases, "/.;" and "/..;" are nothing but plain text (they > > won't be treated as "/." and "/.." on the filesystem AFAICT), so we > > could let them 404 normally. > > I think for the default handler this is no problem. As you state such > URL's likely produce just a 404 and we are done. > > > In the mapping=servlet case, servlet normalization is applied to > > r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/.. matchings > > use the same uri-path than the backend. > > But only if you have an appropriate ProxyPass in place. With RewriteRules > this does not work. > Hence I think we need an additional mechanism to handle this in case of no > ProxyPass directives. > I still fail to see a real use case for /..; and /.; segments. Hence I > think denying them should > be possible with a simple option without the need for a ProxyPass > directive or an additional > RewriteRule. This would also keep path parameters in other segments as > they are. > As said I am even happy if the default of this directive would keep the > current behavior. > > > This sounds a bit like we want to reject "/.;" or "/..;" for the > > servlet case but still accept "/." and "/.." unconditionally for the > > non-servlet case. So possibly we want a general "AllowPathTraversal" > > directive (off by default) for the core to allow/reject "." and ".." > > AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and probably > > "/;" too since it's the same as "/.;" when MergeSlashes applies)? > > I don't want to allow/deny '.' and '..'. Without path parameters I just > want to remove ('.') / shrink them ('..') without going > past root like we do today. > >From the beginning of this dialog, that isn't the function of an HTTP/1 proxy. We have no business in that PER THE SPECS. I don't understand why the Tomcat project and other servlet providers, after given evidence they broke the spec, and downgrade of their reservations of the ;params logic out of the URI spec, keep insisting the behavior is necessary for the HTTP transport providers to consider. I don't understand why, Ruediger, some keep defending the .; or ..; as a normative acceptable path element, and refuse to consider the idea that every such occurance is malicious, without evidence of a single legit application of that formation. If you don't want to let them slide, we *could* deny \.;.* and \.\.;.* by default. Or we already *can* when ajp users would like to add rewrite rules.
Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize
On 7/20/20 4:45 PM, Yann Ylavic wrote: > On Thu, Jul 16, 2020 at 10:31 PM Eric Covener wrote: >> >> On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem wrote: >>> >>> >>> >>> On 6/24/20 1:27 PM, Eric Covener wrote: > > ProxyMappingDecoded is not needed anymore (and was removed). > The mapping= tells mod_proxy at which stage ([pre_]translate) it > should map the request path. +1 >>> >>> Getting back to an old topic. Shouldn't we have a directive similar to >>> AllowEncodedSlashes that allows us to block URI's that contain >>> URL fragments like /.; and /..; in order to avoid that someone plays >>> silly games that bypass Location settings and RewriteRules >>> that might be used with a servlet engine in the backend? Happy >>> to have that set to a default that allows /.; and /..;. >> >> +, but I'd want the safer default. > > Is this something we should care about outside the proxy mapping=servlet case? > In the other cases, "/.;" and "/..;" are nothing but plain text (they > won't be treated as "/." and "/.." on the filesystem AFAICT), so we > could let them 404 normally. I think for the default handler this is no problem. As you state such URL's likely produce just a 404 and we are done. > In the mapping=servlet case, servlet normalization is applied to > r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/.. matchings > use the same uri-path than the backend. But only if you have an appropriate ProxyPass in place. With RewriteRules this does not work. Hence I think we need an additional mechanism to handle this in case of no ProxyPass directives. I still fail to see a real use case for /..; and /.; segments. Hence I think denying them should be possible with a simple option without the need for a ProxyPass directive or an additional RewriteRule. This would also keep path parameters in other segments as they are. As said I am even happy if the default of this directive would keep the current behavior. > This sounds a bit like we want to reject "/.;" or "/..;" for the > servlet case but still accept "/." and "/.." unconditionally for the > non-servlet case. So possibly we want a general "AllowPathTraversal" > directive (off by default) for the core to allow/reject "." and ".." > AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and probably > "/;" too since it's the same as "/.;" when MergeSlashes applies)? I don't want to allow/deny '.' and '..'. Without path parameters I just want to remove ('.') / shrink them ('..') without going past root like we do today. Regards RĂ¼diger
Re: hardening mod_write and mod_proxy like mod_jk with servletnormalize
On Thu, Jul 16, 2020 at 10:31 PM Eric Covener wrote: > > On Thu, Jul 16, 2020 at 3:31 PM Ruediger Pluem wrote: > > > > > > > > On 6/24/20 1:27 PM, Eric Covener wrote: > > >> > > >> ProxyMappingDecoded is not needed anymore (and was removed). > > >> The mapping= tells mod_proxy at which stage ([pre_]translate) it > > >> should map the request path. > > > +1 > > > > > > > Getting back to an old topic. Shouldn't we have a directive similar to > > AllowEncodedSlashes that allows us to block URI's that contain > > URL fragments like /.; and /..; in order to avoid that someone plays > > silly games that bypass Location settings and RewriteRules > > that might be used with a servlet engine in the backend? Happy > > to have that set to a default that allows /.; and /..;. > > +, but I'd want the safer default. Is this something we should care about outside the proxy mapping=servlet case? In the other cases, "/.;" and "/..;" are nothing but plain text (they won't be treated as "/." and "/.." on the filesystem AFAICT), so we could let them 404 normally. In the mapping=servlet case, servlet normalization is applied to r->[parsed_]uri (no "/.;" or "/..;" anymore), so Location/.. matchings use the same uri-path than the backend. This sounds a bit like we want to reject "/.;" or "/..;" for the servlet case but still accept "/." and "/.." unconditionally for the non-servlet case. So possibly we want a general "AllowPathTraversal" directive (off by default) for the core to allow/reject "." and ".." AND proxy mapping=servlet to extend it to "/.;" or "/.;" (and probably "/;" too since it's the same as "/.;" when MergeSlashes applies)? Regards; Yann.
Re: svn commit: r1879641 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS server/util_script.c
On 7/18/20 10:11 AM, Luca Toscano wrote: > Hi Ruediger, > > On Wed, Jul 15, 2020 at 10:04 AM Ruediger Pluem wrote: >> >> >> On 7/15/20 9:06 AM, Luca Toscano wrote: >>> Hi everybody, >>> >>> getting back on this. I checked mergeinfo and r1879253 r1879348 are >>> not listed, what is the best path forward to fix this? (Asking because >>> I have never merged from trunk, and I am not sure what is the best >>> path forward). >> >> Try >> >> svn merge --record-only -c 1879253,1879348 >> https://svn.apache.org/repos/asf/httpd/httpd/trunk . >> >> in a freshly svn up'ed working copy of 2.4.x. > > Thanks for the answer. IIUC the above command takes care of updating > mergeinfo with the missing revs, but the problem is (I think) that > they didn't get merged in the first place along with the others (so > they are missing from 2.4.x). Since I never merged commits into 2.4.x, > I was wondering what to do to avoid messing up the state :) Good catch. The backport was incomplete as only the first of the list of revisions was backported. Fixed in r1880060. Regards RĂ¼diger