Bug 37439

Summary:	Virtual Host selection across Services?
Product:	Tomcat 5	Reporter:	Robert Nice <rnice>
Component:	Unknown	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P2
Version:	5.5.9
Target Milestone:	---
Hardware:	Other
OS:	Linux

Description Robert Nice 2005-11-10 07:03:13 UTC

I have a TC 5.5 fronted by Apache2/mod_jk.
Two SSL sites on different ips, one for users, one for admins. The admin one is
apache password protected. Each apache ip virtual host uses a different worker
to talk to TC on a different port in a different service. for example

<Service name="User">
 <Connector scheme="https" secure="true" address="127.0.0.1" port="10004"
debug="0" useURIValidationHack="false" protocol="AJP/1.3"/>
 <Engine name="Standalone" defaultHost="User" debug="0">
  <Host name="User" debug="0" appBase="webapps/SomethingUser" unpackWARs="false">
   <Context blahblah/>
  </Host>
 </Engine>
</Service>

<Service name="Admin">
 <Connector scheme="https" secure="true" address="127.0.0.1" port="10005"
debug="0" useURIValidationHack="false" protocol="AJP/1.3"/>
 <Engine name="Standalone" defaultHost="Admin" debug="0">
  <Host name="Admin" debug="0" appBase="webapps/SomethingAdmin" unpackWARs="false">
   <Context blahblah/>
  </Host>
 </Engine>
</Service>

The problem, and it may be intended behavior, is that if you connect to ip1 and
spoof your Host header as 'Admin', apache correctly routes the request (jk in
debug says it connects via 10004) to TC via the User worker, but then TC appears
to match the virtual host name in a different service and serves admin content
getting around Apache's password protection.
Via browsing a lot of bugs tonight I'm aware of the useIPVHost element which I
could probably use to lock each host to the host apache intended, but this can't
be intended behaviour. Can it? Across Service tags? Why would you ever need more
than one service or connector then?

Hopefully at the very least this will spur a note in the docs. if it is
intended, as this is potentially dangerous. LMK if you need anything else to
reproduce.

Comment 1 Yoav Shapira 2006-04-13 19:55:12 UTC

If you have suggested text for the note in the docs that you want, please attach
it to this item and I'll gladly look at it, commit it as relevant.

Comment 2 Robert Nice 2006-04-13 20:06:21 UTC

Note in the docs? This has to be a bug, no?

Should a connector of a service be able to access a host in another service? If
yes, this is insane, if not you've got a bug.

Comment 3 william.barker 2006-04-13 20:16:26 UTC

(In reply to comment #2)
> Note in the docs? This has to be a bug, no?
> Should a connector of a service be able to access a host in another service? 
If
> yes, this is insane, if not you've got a bug.

Well, I guess it's insane then ;-).

Multiple <Service /> tags is deprecated.  However, if you don't name your 
Engines the same name, then the mapping should work as you expect it to.

Comment 4 Robert Nice 2006-04-13 20:30:47 UTC

(In reply to comment #3)
> (In reply to comment #2)
> > Note in the docs? This has to be a bug, no?
> > Should a connector of a service be able to access a host in another service? 
> If
> > yes, this is insane, if not you've got a bug.
> 
> Well, I guess it's insane then ;-).
> 
> Multiple <Service /> tags is deprecated.  However, if you don't name your 
> Engines the same name, then the mapping should work as you expect it to.

So are you saying that Engines across different services end up merged or
visible to each other if they have the same name? If so I'd put that in the manual.

I only ask because it causes a bit of a security problem. If you connect via
Apache-httpd and think you can rely on a connector/engine either matching a host
defined inside it, or defaulting to the default host inside it, you get a nasty
shock if it happens to find a match on a totally different application somewhere
else, especially if you thought that application was secured. :(

Thanks for the prompt reply.

Comment 5 Mark Thomas 2006-10-29 19:58:32 UTC

I have updated the docs. The update will be in 5.5.21 onwards.