To: new-httpd@apache.org
Path: dgaudet
From: dgaudet@hotwired.com (Dean Gaudet)
Newsgroups: hot.mailing-lists.new-httpd
Subject: Re: security holes and other fun stuff
Date: 20 Jul 1996 23:20:22 GMT
Organization: HotWired Ventures
Lines: 82
Message-ID: <4srpjm$hh8@re.hotwired.com>
References: <4scvrp$5i2@re.hotwired.com>
 <hot.mailing-lists.new-httpd-Pine.SGI.3.93.960720121153.326G-100000@fully.organic.com>
NNTP-Posting-Host: get.wired.com
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

In article <hot.mailing-lists.new-httpd-Pine.SGI.3.93.960720121153.326G-100000@fully.organic.com>,
Brian Behlendorf  <new-httpd@hyperreal.com> wrote:
>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.

Yep that explains the name-vhost access to ip-vhost problem quite well.

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

Hrm... yeah this would avoid most of the problems because the ip
www.victim.com and www.fakename.com would fall under name-vhost rules.
It still is a (milder) denial of service because not all browsers
support name-vhosts yet.  The bug would still exist in 1.0, but we're
not committed to supporting that.

There's still the issue of explaining the problems associated with
putting DNS names in <virtualhost> directives.  I'll try to write the
DNS issues down clearly (and/or add patches) in a few weeks after I'm
done with a load of work.

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

m4 is nice.  I've been using it for several months to generate
<virtualhosts> for a half dozen similar but somewhat different servers
(at different stages of our production).

My largest beef with the config file format is that the directory
merge/override behaviour is not intuitive.  For example I'd like to
be able to restrict access to an entire server by ip... and in some
cases I need to further restrict some subdirectories.  The only way
to do this now is to specify the restrictions in each <Directory>.

I'd like to be able to specify:

<Directory />
allow from 10.0.0.
deny from all
</Directory>

and have it die immediately if it's not from 10.0.0. instead of going
further down in the tree to see if it's really allowed somewhere
lower on.

But I can't imagine a nice syntax that allows us to both restrict
lower parts of the tree from overriding configuration options, and
allow them to override others.  At one extreme you could control all
access through perl routines that get passed all the relevant
structures and decide yay or nay on override/merge issues.  But that's
a little overkill.

Maybe it's good enough to define "soft" and "hard" directory
configurations.  soft auth stuff can be overriden by later auth
directives.  Hard stuff causes immediate failure.

Dean