[Zope] unprotected VHM usage may facilitate cache poisoning

[Jamie Heilman]

With Virtual Host Monsters being all the rage these days, I'd like to
point out something that I have yet to see addressed in any of the
tutorials.

Letting anonymous clients send tainted requests to a VHM enabled site
is not a good idea, and should be guarded against.  A tainted request
in this case is one whose URI contains the substrings
"/VirtualHostBase/", "/VirtualHostRoot/", or "/_vh_".  For unprotected
sites using VHMs, letting an anonymous client send URIs containing
those substrings will result in the returned document rendered in the
context of an appropriately mangled traversal request name stack.
Usually if that mangling results in a bunch of broken URLs in the
document its no big deal.[1]  It is a big deal though, if you're using
a cache, and that request results in a cache miss--then that broken
document gets stored as the response for subsequent requests.  Oops.

I've verified this can be a problem when using RAM Caches, I haven't
tried external caches, depending on how they key the content it may
or may not be a problem.

Now, this isn't so much a problem with the VHM product, but rather
with sloppy configuration practices.  Which, as it happens, pretty
much every tutorial I've read demonstrates, with a uniformity
otherwise rare to the HOW-TO library.  As virtual host monsters may be
used in a variety of ways, there's no one-size-fits-all approach to
protecting your site.  If you use Apache with mod_proxy's directives,
for example, you can probably use any number of techniques ranging
from LocationMatch directives to perhaps even abusing mod_alias.  If
you use Apache with mod_rewrite (+ mod_proxy for the [P] flag), then
you can simply use RewriteCond patterns to ignore tainted URIs,
letting them fall through to their fate, or you could even catch them
and send 'em packing with a [F] flag or similar.  An example[2] of the
former is:

RewriteEngine on
RewriteCond %{REQUEST_URI} !/VirtualHostBase/
RewriteCond %{REQUEST_URI} !/VirtualHostRoot/
RewriteCond %{REQUEST_URI} !/_vh_
RewriteRule pattern substitution [P]

If you use VHM mappings and ZServer's HTTP service on a raw wire, then
you've probably already thrown out any notion of security, and this is
the least of your worries.  Fixing other front-end proxy server
configurations (squid, etc.) is left as an exercise for the reader.

I believe the 3 'magic' strings I've outlined here are the only ones
which are used by the VHM product, and as such, are the only ones
which need immediate attention for rectifying this particular problem.
If somebody wants to double-check my interpretation of the VHM code
I'd gladly welcome the peer review.

My knowledge of exactly what is used as key in a RAM Cache is hazy at
the moment - but it *may* be possible in some circumstances to exploit
acquisition to poison a RAM Cache as well.  I made a few half-hearted
attempts at doing this, but I wasn't successful; something to think
about though.  If anyone has evidence of why this can or can't work
I'd like to hear about it, if for no other reason than to set my mind
at ease.

-- 
Jamie Heilman                   http://audible.transient.net/~jamie/
"You came all this way, without saying squat, and now you're trying
 to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile?
 I liked you better when you weren't saying squat kid."	-Buddy

[1] Its no big deal with one huge proviso, that the resulting mangled
URLs in the document returned are properly escaped for the context in
which they appear so as to prevent cross-site scripting attacks and
such.  From my perusal of the VHM source, I'd say no escaping is done
to path elements prefixed by "_vh_".  Nevertheless, this is probably
fine, as I'm guessing all escaping is left until later in the
processing phase when the context of presentation is less of an
unknown.  Anyway, I think we're in the clear there, but if you're
sufficiently paranoid (good for you!) and you have some spare time you
may wanna investigate this further.

[2] I hate giving examples of how to configure Apache, because people
will inevitably blindly follow your advice without ever taking the
time to RTFM and learn what the hell they are doing.  I'll make an
exception for (what I've perceived to be) the most common mode of
usage though, in this case.