httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Dean Gaudet)
Subject Re: security holes and other fun stuff
Date Mon, 15 Jul 1996 08:35:05 GMT
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".

D> Now, competitor changes their DNS so that maps to
D>'s address.  Take a boo at virtualhost_section() and
D> you'll see that it places BEFORE in the
D> virtual host searchlist.  Bingo, any hit to's address will
D> be served out of the configuration.  

B>*Well*, any hit which doesn't contain the Host: header.  If everyone used
B>the Host: header, how would get a hit from

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). is set to the same IP as for the duration of the attack, and both are ip-vhosts.  The
order of the definitions in the config file lets steal all
the traffic for

D> The ISP probably
D> won't notice ('cause of the thing Cliff reported and I said was hard to
D> figure out in general with http/1.1 to consider).
B>This is another valid instance where a "No1.1VHostSupport" could be
B>used, so long as concern about supporting Host-less clients was important.
B>Secondly, I'd support making the chain created by virtualhost_section() go
B>in the opposite order - should be easy to do, no?  Hmm, perhaps we could
B>also have a "EnforceHTTP1.1" directive which rejects requests without a
B>full URI or Host: header.

Searching in the opposite order might be more intuitive... but doesn't
eliminate the exploit I gave.  EnforceHTTP1.1 would eliminate the

D> - can only do HTTP/1.1 stuff with the "main" server address
B>Eh?  I can do a telnet 80 and say "GET
B>" and it works fine... is the "main server address" of that machine... the address
returned by gethostname().  As I said, the docs aren't clear.

D> Best needs to know about the change anyhow -- since they'll want to know
D> that you've freed up the number.  It isn't hard for them to move your
D> vhost to another spot in the config file.
B>But it requires exact timing (or at least, coordination of two events
B>within close proximity - adding a second entry to their config files for
B>you, and then after your switch removing your old entry).  Yes, eventually
B>I tell them the old IP address is gone, but only after I'm sure no one's
B>using it.

You can't change DNS in less than 2 weeks.  It doesn't matter what any of
your timeouts are set to -- you'll still see traffic on the old addresses
after two weeks.  I've done this dozens of times and seen it in action.  I
don't think that it's all broken DNS clients either -- netscape never looks
up anything twice, and many people leave their netscape (and everything
else) running when they "leave" work.  My netscape has been going for 3
days now, so I won't see any DNS changes until I restart it (i.e.  'cause
it crashed ;).  So... no matter what you do, you have to use two config
file entries for a while or you lose traffic.

D> [<Map> syntax]
B>Hmm... personally, I'm not convinced.  The above is not necessarily more
B>readable or intuitive or less error-prone than the existing config files -
B>that's for me, and I admit I may be biased by being too close to the
B>problem.  I won't even mention the political cost of asking people to
B>totally change config files.  And while us computer scientists like adding
B>layers of indirection, it might be somewhat confusing for the average
B>webmaster. :)

Oh they don't have to convert, because the <Map> stuff can be generated
implicitly.  You're entirely right, the existing config files can be used
to generate hash tables and everything -- that is, AFTER we specify an
ordering for them explicitly (presently it's reverse order specified in the
config file).  The <Map> stuff is more how I think the mapping from request
-> virtualhost should be made... and given enough primitives the present
config can support it as well.

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.


P.S. There is a DNS exploit involving multihoming that can't occur right
now because we don't allow multihomed addresses in <VirtualHost>
statements... but that's exactly what I want to add and why I started to
dig through this code.

View raw message