httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: security holes and other fun stuff
Date Sun, 14 Jul 1996 02:56:29 GMT
On 13 Jul 1996, Dean Gaudet wrote:
> While thinking on my VirtualHost syntax problem, and Cliff's request
> I think I've discovered several configuration-related security (and
> reliability) problems, one of which bypasses access controls.
> First, a serious one.  Suppose the same webserver has an internal vhost,
> an external vhost, 

(I'm presuming here you mean, two IP numbers, say X and Y?)

> and access to the internal vhost is restricted
> only by ip filtering (this is not unreasonable -- consider the use of
> private network numbers).  We now parse HTTP/1.1 requests using either
> "" URIs or Host: headers.  If you send a request to
> the public address with a URI or Host: header pointing at the private
> address the server will serve up the page.  I'm zoned at the moment,
> so someone else should follow the flow through read_request() and into
> read_request_line() and then into check_hostalias().  If I'm right,
> we've got a problem.

Hmm, I'm not so sure I buy that.  You can't expect the application to know
about security policies that sit at a layer below it - when your mapping
between those two layers dissolves, then you need to find another mapping.

The only thing I can think of is to be a little more conservative with the
vhost stuff and say, "If vhost Y maps to the primary IP address which I've
bound myself to, then it's a Host:-based host - if it maps to a secondary
IP address, then it's not Host:-based", but that would disallow certain
other expected functionalities, like letting two web sites share the same
secondary IP address. 

> Now on to some more mundane concerns.  Let "name-vhosts" refer to HTTP/1.1
> virtual hosts, and "ip-vhosts" refer to ip-based virtual hosts.
> Remember while reading this that it's common for ISPs to *not* be primary
> for some customers' DNS, while at the same time hosting websites for
> such customers.  Also remember that our docs all suggest the use of DNS
> names instead of IPs when configuring either name-vhosts or ip-vhosts.
> There are several reliability/denial-of-service possibilities involving
> the use of DNS names in <VirtualHost> statements.  If name-vhosts (or
> ip-vhosts) are configured in the manner described in the documentation
> (i.e. using DNS names) then the server won't boot if DNS isn't working.
> Furthermore, if any of the names used are in uncontrolled domains (i.e.
> secondary or no local authority) then a third party can cause denial
> of service.

So, the policy here should be, if DNS names fail to resolve correctly to
an IP address on the machine, then that particular vhost setting fails
but the rest of the server comes up.  I think we talked about it a few
weeks ago as something we should do, in the vein of "more tolerant config
file parsing".

> Another possibility involving uncontrolled DNS:
>     <VirtualHost>
>     ...
>     </VirtualHost>
>     <VirtualHost>
>     ...
>     </VirtualHost>
> Suppose is your "main server address" and maps to and
> you expect to map to, but you don't control
> Then the controller (or Evil Person) can force you to use
> name-vhosts just by mapping to

How is this a problem?  Oh, I suppose for clients which don't support
Host:, this might make the default host for that IP address, but I
don't know...

> Essentially, using DNS names in <VirtualHost> statements should be
> entirely avoided.  
> This is true in pre-apache-1.1 syntax as well, since
> could force denial of service for if their ip addresses
> match and appears first (last?) in the config file.
> Fortunately, I think we already have workarounds for all of the above.
> Always use ip addresses and ServerName, even when defining a name-vhost.
> For name-vhosts use ServerAlias to define the name your server responds
> to.

I'd prefer the name the vhost responds to should be a union of the
ServerName and ServerAlias settings, not just ServerAlias.  Ugh, but then
you get things like



hmm... slight semantic change, I suppose.

> So... do we want to rethink the syntax?  At the moment it's actually a bad
> thing to be forced into name-vhost mode because not all clients support
> it.  In the future this may not be an issue.

On the flip side, the current setup would allow ISP's who are currently
burning IP addresses with vhosts to allow those sites whose DNS is
controlled elsewhere to migrate without having to coordinate it with the
server authority; in other words, if I have a web site at using, and best currently gives me an IP number but want it back,
then I can change the IP mapping of "" at any time to the
"centralized" vhost IP number, and I won't need to coordinate
that with best's sysadmins.  So, what to some people is a bug, is a
feature to others. :)

> The documentation should be updated to at least mention this concern,
> and maybe some other DNS concerns:
> - Apache doesn't do double reverse lookup for DNS based authentication.
>     There's even a helpful example of how to do it wrong in the
>     access.conf-dist file for the status handler... which an "attacker"
>     can easily spoof by playing with their reverse map.  Naive users
>     (heck even HotWired's config had this problem when I arrived :)
>     will fall into this trap.
>     (I know there's the mention of MAXIMUM_DNS in the Configuration file.)

At least when I wrote about this for my book, I did mention that
host-based access control was unsafe unless used with MAXIMUM_DNS (time
to make this a runtime config?) or unless one used IP numbers.

> - If ServerName isn't set, apache does a reverse lookup in
>     default_server_hostnames to find it.  If DNS is down when the
>     server boots this will cause ServerName to be defaulted incorrectly.
>     Actually, default_server_hostnames will segfault if somewhere
>     between get_local_host and "main = gethostbyname..." there is a DNS
>     failure... or if the servername is bogus.  patch:
> +     if( main == NULL ) {
> +         fprintf(stderr,"httpd: cannot resolve main ServerName.\n");
> +         exit(1);
> +     }

Wouldn't it be saner to just set it to the IP number?

> P.S. People doing SSL for apache 1.1 should watch out for the "http://"
> comparisons in check_hostalias().


> P.P.S.  Hostnames such as "" are valid, yet find_allowdeny
> does not properly handle them.  This should be put on Known Bugs.  Be
> careful when fixing this because just removing the isalpha() check creates
> a security hole, consider the DNS map " IN PTR 2.2.2."
> if the user has a config line "allow from 2.2.2" it will allow in
> (unless -DMAXIMUM_DNS).  -- which is bad because it breaks people who
> understand double reverse lookup and are trying to avoid it by using
> only ip addresses on allow/deny statements.

Good one.  I've added it to the known_bugs page.

> P.P.P.S.  A response to the original article I was following up on:
> In article <>,
> Cliff Skolnick  <> wrote:
> >In your vitual host fixup, can you do one of the following:
> >
> >If a second virtual host directive is givin for an existing defined
> >virtual host, then:
> >
> >1) A warning that the first directive's information is lost is
> >output to the error log and/or stderr.
> >
> >2) The new values are merged into the existing virtual host.
> I think I'd rather see a warning... I'm not sure why merging would
> be useful -- unless you want to be able to define a virtualhost piecemeal,
> a bit here, a bit there spread all over the config file(s).

I'd agree.

> It's also a pain in the butt to solve considering you have to compare
> all possible methods of accessing each virtual server to even find it.
> Sure, pure ip comparison would have been easy... but now with ServerAlias
> and name-vhosts it's not fun.




View raw message