[Zope] issues of trust, why security via mod_rewrite fails

[Jamie Heilman]

Since February I've been railing on about the importance of protecting
your Zope installations and their Products with rewrite rules and URI
filters.  Well, unfortunately I was overlooking something rather
obvious--Zope's built in magical type coercion gets around most URI
matches entirely.  The rewrite rules I've suggested in the past aren't
enough.  If this style of filtering is to be continued it must be
augmented with filters that are capable of examining the request
resource, the query parameters, and basically anything that can
externally control Zope's traversal stack.

Couple of brief examples; whereas before you may have desired to
filter access to the HelpSys mechanism (a notorious leak of
information[1] about what products your zope service has installed as
well as a potential vector for other badness) by doing something like

RewriteCond %{REQUEST_URI} /(Control_Panel|HelpSys)(/|$)
RewriteRule .* - [F]

in your Apache configuration, now I realize its not enough.  Getting
around that restriction is as easy as http://examplehost/?HelpSys:method=
The type coercion hooks, :method, :action, :default_method, etc.
evidently alter the traversal stack.  Even stuff like
http://examplehost/?_vh_foo:method= will work, bypassing the URI
filters I've been extolling[2] for protecting Virtual Host Monsters.
Dylan had good reason to voice suspicion about type coercion back in
March[3], but the issue was skirted and ended up focusing on tainting
application data (which, of course, is also important).

So where do we go from here?  Its becoming evident to me that while I
can probably finagle a rewrite rule that looks for certain tainted
names in the GET and POST query variables, Zope has more avenues of
control than your typical web application.  There's still things like
WebDAV, XML-RPC, etc. to worry about, any of which may contain
additional hooks which allow frobbing the traversal stack.  Writing
filters for all those is going to be seriously trying.

I'll postulate that the path of least resistance is simply giving up
any hope of filtering requests for sanity, and instead focusing on
replacing the problem Products and establishing new, secure, paths of
configuration.  HelpSys should not allow non-authenticated access.
VirtualHostMonsters should not obtain their rewriting information from
the traversal stack, indeed the traversal stack should not be viewed
as a source of trusted information, much like the the request URIs
can't be viewed as trusted[4].  ... and so on.  This should be fun.

-- 
Jamie Heilman                   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."		-Rosencrantz

[1] http://marc.theaimsgroup.com/?l=zope-dev&m=103893600209090&w=2
[2] http://marc.theaimsgroup.com/?l=zope&m=104426779414836&w=2
[3] http://marc.theaimsgroup.com/?l=zope&m=104718222616059&w=2
[4] http://collector.zope.org/Zope/813   I should point out the VHM
    workarounds for bug 813 I mentioned are made moot by this latest
    realization, the only sane thing to do now is to patch, patch,
    and patch some more.