issues of trust, why security via mod_rewrite fails
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.
Jamie Heilman wrote:
Since February I've been railing on about the importance of protecting your Zope installations and their Products with rewrite rules and URI filters.
And let me thank you for that, IMO you do a very important service for the zope community. Unfortunately it seems that unless there is a major flaw found, there's not much interest in this kind of security analysis.
[snip]
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.
At least with VHM, I think the solution is straightforward. Abandon the path for forwarding information to zope, and use custom http-headers instead. VHM then would delete these headers on traversal (to hide that information from not-so-trusted code inside zope). This solution would not only be more secure, it would also simplify the VHM code alot, and it would certainly be faster. cheers, oliver
Oliver Bleutgen wrote:
And let me thank you for that, IMO you do a very important service for the zope community. Unfortunately it seems that unless there is a major flaw found, there's not much interest in this kind of security analysis.
Thanks! I have to say I too don't understand the perfunctory attitude towards security in Zope. I've pointed out numerous avenues for cross site scripting, which even when patched, thanks to the misplacement of trust, allow poisoning of caches with false hostnames, URIs, etc. Even finding out if a page uses a cache manager is trivial, thanks to the unprotected method of ZCacheable_getURL in the ZCacheable mix-in. (which is fixed in my reworked version see bug 911) My point is, you combine enough of these things together and you can start to build a pretty effective attack against a Zope host.
At least with VHM, I think the solution is straightforward. Abandon the path for forwarding information to zope, and use custom http-headers instead. VHM then would delete these headers on traversal (to hide that information from not-so-trusted code inside zope).
This solution would not only be more secure, it would also simplify the VHM code alot, and it would certainly be faster.
Yeah I think you're right, the extra header occured to me too, I haven't hammered out any code yet (too busy updating the patchwork for 813) but its on my list. Now, while I think a new header is a good stop-gap I don't think its a permanent solution. The probablem of no canonical host name is still source of pain in zope and I have a hunch a long term solution will solve both problems at once, as well as be safe to use on a multi-user machine with potentially hostile accounts. I don't yet know what that solution might look like though. -- 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
Jamie Heilman wrote:
At least with VHM, I think the solution is straightforward. Abandon the path for forwarding information to zope, and use custom http-headers instead. VHM then would delete these headers on traversal (to hide that information from not-so-trusted code inside zope).
This solution would not only be more secure, it would also simplify the VHM code alot, and it would certainly be faster.
Yeah I think you're right, the extra header occured to me too, I haven't hammered out any code yet (too busy updating the patchwork for 813) but its on my list.
I had a look at it, too, and as far as I see most of the code is about juggling with the traversal stack.
Now, while I think a new header is a good stop-gap I don't think its a permanent solution. The probablem of no canonical host name is still source of pain in zope
Could you elaborate that a little bit? Are you referring to what is talked about in 813 or is there something else?
and I have a hunch a long term solution will solve both problems at once, as well as be safe to use on a multi-user machine with potentially hostile accounts. I don't yet know what that solution might look like though.
cheers, oliver
Oliver Bleutgen wrote:
Jamie Heilman wrote:
Now, while I think a new header is a good stop-gap I don't think its a permanent solution. The probablem of no canonical host name is still source of pain in zope
Could you elaborate that a little bit? Are you referring to what is talked about in 813 or is there something else?
Yep, 813 is a two pronged problem. The first prong are the cross-site scripting vulnerabilties due to poor contextual escaping. Thats what what my patch tackles. The second prong is the issue of zope's decision to always trust the client provided hostname. That problem hasn't been solved yet, the workarounds I mentioned in 813 are no longer adequate as they depend on the VHM which obtains its information from an untrustworthy source. The only workaround for the cross site scripting issue is to patch zope. The problem of client provided hostnames is only a problem if you use caching and your cache doesn't use the hostname as a cache key. If your cache allows you to add the hostname to the cache key then you're safe - provided that doesn't open your cache up to abuse. (see my previous posting about caching) Cache users should be aware that adding hostname alone isn't enough, to prevent poisoning the path info should also be added to the key as VHMs combined with type coercion let untrusted users change that too, and possibly the protocol... though I haven't dug that far into it yet to see just how much can be exploited by beating up a VHM. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
participants (2)
-
Jamie Heilman -
Oliver Bleutgen