Bug 237656 (CVE-2007-1860)

Summary: CVE-2007-1860 mod_jk sends decoded URL to tomcat
Product: [Other] Security Response Reporter: Mark J. Cox <mjc>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jclere, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-11 08:57:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 237657, 237658, 240947, 242451, 430726, 430727, 449337    
Bug Blocks: 444136    
Attachments:
Description Flags
Patch for tomcat-connectors change the default value of JK_OPT_FWDURIDEFAUL none

Description Mark J. Cox 2007-04-24 15:06:36 UTC
It was reported that the patch CVE-2007-0450 was insufficient as a carefully
crafted encoded URL could still bypass a proxy.  However this is due to an
interaction with mod_jk, where mod_jk sends a decoded URL to Tomcat but it
should send a raw URL.

Jean-Frederic writes:

What mod_jk sends to Tomcat
+++
12 34 01 A9 02 02 00 08 48 54 54 50 2F 31 2E 31  - .4......HTTP/1.1
00 00 1A 2F 6D 79 61 70 70 2F 25 32 45 25 32 45  - .../myapp/%2E%2E
2F 6D 61 6E 61 67 65 72 2F 68 74 6D 6C 00 00 0C  - /manager/html...
+++
Tomcat decodes the %2E%2E into .. and normalises /myapp/../manager/html
to /manager/html.

The Tomcat security team give this advice:

Due to the impossibility to guarantee that all URLs are handled by Tomcat as
they are in every possible proxy server, Tomcat should always be secured as if
no proxy restricting context access was used. 

Note that this issue is not yet public.

Comment 1 Mark J. Cox 2007-04-24 15:12:46 UTC
Jean-Frederic said that "JkOptions ForwardURICompatUnparsed" should prevent
the problem and mod_jk code should be changed to use it as default value.
(The actual value ForwardURICompat breaks the spec's).


Comment 2 Vivek Lakshmanan 2007-04-24 18:47:08 UTC
(In reply to comment #1)
> Jean-Frederic said that "JkOptions ForwardURICompatUnparsed" should prevent
> the problem and mod_jk code should be changed to use it as default value.
> (The actual value ForwardURICompat breaks the spec's).

ForwardURICompat is the default option and can be overriden with something like
JkOptions +ForwardURICompatUnparsed in the conf file. Note that we dont install
a conf files for mod_jk - we have samples, so the change cant be made in the
conf file. Our samples dont mention JkOptions either so customers using them
will use the default.

Is Jean-Frederic suggesting that the code be made to use
ForwardURICompatUnparsed by default? Is there a patch for this? Note that
documentation would need to be updated for this as well since most of it
suggests that the default is ForwardURICompat.


Comment 3 Vivek Lakshmanan 2007-04-24 18:54:50 UTC
[Adding Jean-Frederic to CC list]
JF - Can you take a look at the above and let me know what you think?
 

Comment 4 Jean-frederic Clere 2007-04-24 21:02:13 UTC
Yes the mod_jk code should be made to use ForwardURICompatUnparsed by default.
No there isn't a patch for the moment.

Comment 5 Vivek Lakshmanan 2007-04-25 14:16:59 UTC
(In reply to comment #4)
> Yes the mod_jk code should be made to use ForwardURICompatUnparsed by default.
> No there isn't a patch for the moment.
Thanks for the clarification. Please update the BZ when a patch is available.



Comment 7 Jean-frederic Clere 2007-05-15 16:12:21 UTC
Created attachment 154748 [details]
Patch for tomcat-connectors change the default value of JK_OPT_FWDURIDEFAUL

Patch for svn.apache.org/repos/asf/tomcat/connectors/trunk (15/05/2007).
It changes the default behaviour of mod_jk and have not yet been committed in
te ASF repos.

Comment 8 Mark J. Cox 2007-05-23 09:27:58 UTC
this is now public at http://tomcat.apache.org/security-jk.html, removing embargo