Bug 51709 - ServerName/ServerAlias don't work if Host: header from HTTP request matches VirtualHost address
Summary: ServerName/ServerAlias don't work if Host: header from HTTP request matches V...
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.19
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://mail-archives.apache.org/mod_m...
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2011-08-23 08:14 UTC by Micha Lenk
Modified: 2017-06-25 12:46 UTC (History)
0 users



Attachments
Fix for function check_hostalias() (1.77 KB, patch)
2011-08-23 08:52 UTC, Micha Lenk
Details | Diff
Fix for function ap_matches_request_vhost() (1.54 KB, patch)
2011-08-23 10:06 UTC, Micha Lenk
Details | Diff
Fix for function check_hostalias() (1.70 KB, patch)
2011-09-17 14:30 UTC, Micha Lenk
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Micha Lenk 2011-08-23 08:14:03 UTC
As discussed on the mailing list, the following issue was found:

Short summary:
If it matches, the parameter from VirtualHost overrides any ServerName or ServerAlias directive. Under some rare conditions, content for the wrong virtual host is delivered.

Detailed description:
I have configuration with two virtual hosts v1 and v2, both listening on
the same IP address. Assuming that v1.local and v2.local both resolve to the IP address 10.0.0.1, the configuration for the virtual hosts basically
looks like this:

Listen: 10.0.0.1:80 http
NameVirtualHost 10.0.0.1:80
<VirtualHost v2.local:80>     # <-- this is NO typo!
    ServerName v1.local
    DocumentRoot /srv/v1
</VirtualHost>
<VirtualHost v2.local:80>
    ServerName v2.local
    DocumentRoot /srv/v2
</VirtualHost>

For HTTP requests with the request header 'Host: v2.local:80', the
request always ends up on virtual host v1, delivering the content from
/srv/v1.

Reading the code (version 2.2.19) I discovered, that in the function check_hostalias() defined in server/vhost.c the host header is
matched against the parameter from the VirtualHost container first,
before it is then matched against any ServerName or ServerAlias
directive. And as soon as the first VirtualHost seems to match, no
ServerName or ServerAliases are checked. So, essentially any name or IP
literal specified as parameter to VirtualHost seems to have precedence
over all ServerName or ServerAlias directives.

I've already consulted the SVN history. Apparently this code flow didn't
change since the NameVirtualHost directive was added (SVN Rev. 79345)
back in October 1997, and maybe is even older.
Comment 1 Micha Lenk 2011-08-23 08:52:23 UTC
Created attachment 27423 [details]
Fix for function check_hostalias()

Please find attached my patch for check_hostalias(). I tried to stick to
the idea to do the ServerName and ServerAlias check only once for each
server. Also for this reason the result is in the end merely a rewrite
of this function. I hope though that it is clear enough how it is
intended to work.

However, I believe the fix is yet incomplete. The function
ap_matches_request_vhost() used by modules like mod_proxy seems to
implement the virtual host check in the wrong order too.

See the dev mailinglist for more comments.
Comment 2 Micha Lenk 2011-08-23 10:06:38 UTC
Created attachment 27424 [details]
Fix for function ap_matches_request_vhost()

This is the suggested patch for ap_matches_request_vhost()
Comment 3 Micha Lenk 2011-09-17 14:18:48 UTC
Comment on attachment 27424 [details]
Fix for function ap_matches_request_vhost()

As discussed on the dev mailing list, the patch for ap_matches_request_vhost() is obsolete.
http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3C4E69DCA4.6070701@lenk.info%3E
Comment 4 Micha Lenk 2011-09-17 14:30:06 UTC
Created attachment 27520 [details]
Fix for function check_hostalias()

Updated the proposed fix for function check_hostalias(), based on SVN trunk, rev. 1171988.
Comment 5 Ruediger Pluem 2011-09-17 15:08:38 UTC
Fixed in trunk as r1172002.
Comment 6 Eric Covener 2017-06-25 12:46:11 UTC
Was fixed by 2.4.0