httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@organic.com>
Subject Re: security holes and other fun stuff
Date Sat, 20 Jul 1996 20:14:37 GMT

Sorry for the delay in responding, I've been out of touch for the last
couple of days.  I'm also going to be out of touch until Thursday after
today....

On 15 Jul 1996, Dean Gaudet wrote:
> B = Brian, D = Dean
> 
> B>I can't believe that if you're clued enough to use private network
> B>addresses, you wouldn't also know that vhosts can be requested via the
> B>Host: header.
> 
> Because apache 1.0 didn't do this and it's not documented as a "feature"
> of upgrading?  The docs say [paraphrased] "if you configure it using
> CNAMEs to the main server address it'll use the Host: header"  they don't
> say "the server always looks at the Host: header on the main server
> address and dispatches to any virtualhost, regardless of whether that
> host is served by the main server address".

Okay, I think I've added a pretty approachable and understandable example
to the docs; check out http://www.apache.org/docs/host.html.  If that's
alright then virtual-host.html should probably also be updated.

> D> Now, competitor changes their DNS so that www.fakename.com maps to
> D> www.victim.com's address.  Take a boo at virtualhost_section() and
> D> you'll see that it places www.fakename.com BEFORE www.victim.com in the
> D> virtual host searchlist.  Bingo, any hit to www.victim.com's address will
> D> be served out of the www.fakename.com configuration.  
> 
> B>*Well*, any hit which doesn't contain the Host: header.  If everyone used
> B>the Host: header, how would www.fakename.com get a hit from
> B>www.victim.com?
> 
> My example was with ip-vhosts, and is a hole in 1.0 and 1.1 (1.1 doesn't
> care what Host: crap says on non-"main server address" vhosts -- it does
> respect http:// though).  www.fakename.com is set to the same IP as
> www.victim.com for the duration of the attack, and both are ip-vhosts.  The
> order of the definitions in the config file lets www.fakename.com steal all
> the traffic for www.victim.com.

Ah, okay, I understand now.  So thereis one bug here we should write
down and clarify and make sure we fix:

  If we're going to allow Host: headers to be used for ip-vhosts against 
  the main server address, then we should be consistant and allow such
  Host:  header functionality on the other ip addresses too.

The ordering problem is no longer a problem if the above bug is fixed.

> There's nothing a little perl won't handle either.  We're not 100% locked
> into a particular config file syntax... we're only, say, 50% locked in.
> How many people use m4 or other macro sets to generate their configs?  I'd
> wager it's few.  The rest have plain configs that can be munched into a new
> format.  Not that we'd ever go that way, I would expect -1 on this fast.

Actually, I was thinking about this the other day, when I was thinking
about how crappy our config file syntax is sometimes. :)  We have just
started using m4 here, thanks to Alexei.  If we had a need we could
justify, I think asking people to modify their config files for Apache 2.0
(aided with perl, perhaps) would not be an impossible political feat.  But
we better have a good reason :)

And after thinking about your issues for awhile, I think the best solution
to your concerns and problems would be a directive like "NoBleedVHosts",
which means that Host: header requests would only be answered on those IP
addresses to which they were assigned.  That seems to basically be the
security issue here.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS


Mime
View raw message