Mladen Turk wrote: > Mark Thomas wrote: >>> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404 >>> from Tomcat becasue it will pass the original uri, not the one Httpd >>> already unfolded) >> This is correct and provides consistent behaviour for direct to Tomcat >> access and access via mod_jk. > > It is not correct behavior, because we are stripping down the > entire Httpd filter chain.
This bit I understand. I now see how the fix for CVE-2007-1860 causes problems. >>> mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount >>> /appB/* >> This double decoding prevents legitimate access to perfectly valid >> files that contain the % character in their name. > > How many times I have to repeat. The uri is *not* decoded twice. > It is decoded *only once* by the Apache Httpd. Yes it is decoded only once by httpd, but it is decoded again by Tomcat. This is what I meant by decoded twice. > Did I mention that uri is *not* decoded twice? You did and I still don't agree. The root cause of CVE-2007-1860 was a double decoding. Once in httpd/mod_jk and once in Tomcat. > mod_jk is present for years, and now suddenly changing the > default behavior makes users surprised with mod_rewrite not > working any more. This change was accepted and made only as > a temporary solution to CVE 2007-0774, and as such must be resolved, > rather then hidden inside. Agreed. Ideally, we need a solution that: - doesn't open up a security hole - doesn't break existing configurations - correctly maps http://host/appA/%252e%252e/appB/ to the directory %2e%2e/appB/ within appA My current understanding is: 1. httpd takes original uri 2. httpd decodes uri (I might not have this at quite the correct point) 3. httpd may modify this (mod_rewrite etc) 4. httpd passes the uri to mod_jk 5. mod_jk maps the uri to a worker 6. mod_jk passes the uri to tomcat 7. tomcat decodes the uri (again) 8. tomcat maps the request and processes it As I understand it, the fix for CVE-2007-1860 caused mod_jk map the original uri to Tomcat, bypassing both httpd's decoding (good) and any httpd modifications (bad). As I see it, we have two options: a) Prevent Tomcat from decoding the uri a second time at step 7 above b) Re-encode the uri in mod_jk between steps 5 and 6 The problem with b) is that we can't easily tell what characters were previously encoded and need to be re-encoded. b) is also inefficient. Doesn't this mean a) is really the only option? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
