tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
Date Wed, 06 Jun 2007 11:50:52 GMT
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

>>> 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?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message