CosmoCode is a Berlin based IT service provider focusing on CMS, Wikis and Web2.0
Great software. Bright people. Happy customers!
Mail info@cosmocode.deTel +49 (30) 814504070
We run our servers with Debian and our CMS runs on Tomcat (for the backend) and Jetty (for the frontend). To make sophisticated URL rewrites possible we rely on Apache's mod_rewrite module. After a recent update of the installed Debian packages, suddenly all internal rewrites failed. Redirects were still working fine.
This caused us a major headache until we found the problem.
I first tried to enable all kind of logs. Rewrite logs, logs for mod_jk - they all seemed to work. mod_jk was reporting the correct, rewritten URL!
I then looked at /usr/share/doc/libapache-mod-jk/changelog.Debian.gz which had this entry at the top:
libapache-mod-jk (1:1.2.18-3etch1) stable-security; urgency=high
* Forward unparsed URI to tomcat. Closes: #425836. CVE-2007-1860
Passing unparsed URIs? Well that's exactly the problem we where facing. CVE-2007-1860 describes a problem where attackers could force the use of a wrong worker.
A little bit more search finally brought up this bug report, which describes our exact problem. The mod_jk people promise a fix in the upcoming 1.2.24 release.
Unfortunately this release is not available yet. But a look at the updated mod_jk docs brought up the solution:
The directive JkOptions allow you to set many forwarding options […] The default value is “ForwardURICompatUnparsed” since version 1.2.23. Until version 1.2.22 the default value was “ForwardURICompat”.
So the solution was simple, putting
JkOptions +ForwardURICompat
into the httpd.conf solved the problem. However it makes the system vulnerable for the mentioned security bug again. Because we only use a single worker for all paths, it does not affect us and this fix is good enough until the next release of mod_jk is available.
Dude, you are a LIFESAVER!! I have been slamming my head against my desk for two hours trying to figure out why my properly mod_rewritten JSP URIs were being completely dissed by Tomcat, and it's because of that one switch! Thanks!
It seems that this default setting has changed again. I just discovered the very unfortunate circumstance that the recently released version 1.2.25 is shipped with the default +ForwardURIProxy. ForwardURIProxy may cause some trouble if you are passing path-elements containing encoded semicolons to your tomcat. Better use +ForwardURICompatUnparsed in this case. I would also be strongly recommended rather not to rely on any default setting and to configure your desired behaviour explicitly. ;o)
About CosmoCode
Subscribe
Rainer Jung
2007/08/01 00:12
We released 1.2.24 today.