DO NOT REPLY [Bug 30539] New: - possible security hole: mod_jk2 bypassed when client issues Host: header with an invalid port number

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30539>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30539

possible security hole: mod_jk2 bypassed when client issues Host: header with an invalid port number

           Summary: possible security hole: mod_jk2 bypassed when client
                    issues Host: header with an invalid port number
           Product: Tomcat 5
           Version: 5.0.24
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Connector:AJP
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: aleksander.adamowski.apache@altkom.pl


I have a specific mod_jk2 2.0.4 configuration which maps 2 different port
numbers (running different Apache 2.0.49 virtual hosts) to 2 different Tomcat
5.0.24 services.

I managed to do this by using the following workers2.properties configuration (I
provide relevant directives only):

--- BEGIN SNIP ---

[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
group=ajp13:localhost:8009

[ajp13:localhost:8010]
channel=channel.socket:localhost:8010
group=ajp13:localhost:8010

[channel.socket:localhost:8009]
port=8009
host=localhost
group=ajp13:localhost:8009
 
[channel.socket:localhost:8010]
port=8010
host=localhost
group=ajp13:localhost:8010

# URI mappings
[uri:*:80/*.jsp]
group=ajp13:localhost:8009

[uri:*:443/*.jsp]
group=ajp13:localhost:8009

# mapping from the second Apache virtual host (running on secret port XXXX)
# to the second Tomcat service:

[uri:*:XXXX/*.jsp]
group=ajp13:localhost:8010

--- END SNIP ---

This configuration works fine, but there's a security problem we've recently
discovered that I suspect to be the mod_jk2's fault:

If a HTTP client requests a JSP page and supplies a "Host:" HTTP header, and
provides a port there, and the port is not valid (that is, it's not 80, 443, or
XXXX), then Apache spills out the JSP file's source instead of putting it
through mod_jk2 to be serviced by Tomcat!

This can be easily reproduced with livehttpheaders extension for Mozilla.

Steps to reproduce:
1) install the livehttpheaders extension in Mozilla:
http://livehttpheaders.mozdev.org/
2) open the livehttpheaders window (Tools->Web Development->Live HTTP Headers)
3) load a JSP page from Apache, it should display normally
4) select the URL line over "GET XXXX.jsp" line in the livehttpheaders window
5) click "Replay..."
6) change the "Host:" header to use an invalid port number, e.g. "Host:
www.example.com:1234"
7) click "Replay" - In my case, I received the source of JSP page (as text/plain).


I've tried remedying the problem by supplying additional "catch-all" URI
mappings at the end of workers2.properties, using various patterns:
"[uri:*.jsp]", or "[uri:*:*.jsp]", but none of them has helped - it seemed that
Apache was just bypassing mod_jk2 and _ANY_ URI mappings when the Host header
contained an invalid port.

So as a temporary workaround I've prepared the following access control
mechanism in Apache:

--- BEGIN SNIP ---
# If the "Host:" header specifies a port, deny access to JSP files by setting a
custom env variable:
SetEnvIfNoCase Host \: HOST_PORT_DENIED=yes
# The ports 80, 443 and XXXX are valid, unset the custom env variable for them:
SetEnvIfNoCase Host \:80$ !HOST_PORT_DENIED
SetEnvIfNoCase Host \:443$ !HOST_PORT_DENIED
SetEnvIfNoCase Host \:XXXX$ !HOST_PORT_DENIED

# deny access to JSP based on custom env variable presence:
<Files "*.jsp">
  Order Allow,Deny
  Allow from all
  Deny from env=HOST_PORT_DENIED
</Files>
--- END SNIP ---

This, however, is only a workaround. Ideally, requests with "Host:" header
specifying a port on which Apache doesn't listen, should be denied (IMHO), or at
least passed through mod_jk2 and its URI mappings.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org