On Wed, 2003-03-12 at 19:54, Christian Tismer wrote:
Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"?
And, pondering more on security, are these issues, if they exist, bounded to Zope itself, or becomes a system generally more "open" to attacks, after Zope was installed?
I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
I think the problem is that the question isn't really "simple", because the different configurations in which Zope is used vary so much. For instance, let me describe a configuration which is in production todday: - Zope is configured such that it listens for requests only on a single, non-routed interface. - Public access is mediated by a caching "reverse" proxy. - The user and group as which Zope runs in this setup hass extremely reduced privilegss: it has read access to Python, the standard Python libraries, the Zope sofware, and its configuration files; it has write access only to the "var" directory in which it keeps its database, PID, and log files. - Anonymous users in this Zope instance have only one permission, which allows them to view published content. They cannot create objects in the ZODB at all. - Content managers never log into this Zope instance at all; instead, they use a separate instance, behind the company's firewall, with an entirely different set of permissions; yet, the content is shared directly with the "public" site, via "mounted" storages. In this scenario, the Zope process itself has a very small vulnerability set: - The proxy shields Zope from most forms of DoS attacks (cleverly constructed query strings might still be able to get through). - Because the Zope instance uses Python's string handling facilities, it is not vulnerable to many of the "buffer overflow" attacks which plague C-based daemons. - If a user could gain control of the Zope process, the only scope for damage would be the ZODB itself. Now let me describe another configuraton, running in production now for years (one process in the cluster had an uptime of 400 days at a recent hardware-induced reboot): - Two Zope application servers run behind a load balancer and an Apache proxy (non-caching), serving requests against data in a shared storage server. - The server permits through-the-web registration, with minimal identity check (only a valid e-mail address. As of this writing, there are 18000+ user accounts. - Users of the site get a "member folder" where they can create templates, Python scripts, and content within the ZODB. Some minimal workflow exists, controlling basically whether the user's content is included in site searches. This configuration is perhaps the most vulnerable I can think of: nearly-anonymous users can create applications, using as much of Python as the through-the-web Python scripts allow. Yet, in the years this site has been running, it has suffered from only mild forms of abuse: - Malice-free templating triggered DoS-like bursts of activity (looping, or pathologically-nested acquisition). - Warez r00erz were using the site to serve ripped-off tarballs, before the site added upload filters which made the practice unprofitable. - Some users used the templating features to construct sub-sites which violated the terms of use for their accounts, which were eventually terminated. - Occasionally, the site sees bursts of DoS-like activity (which may be malicious, or may simply be incompetently-written spiders). The normal defense to such attacks is to block packets from their IPs (or ranges) at the border router. How could such a site not have been wrecked? I can offer a couple of hypotheses: - Trashing it hasn't been attractive enough to sufficiently determined blackhats. - Zope's restrictions on through-the-web code are mostly successful: in particular, such code can see only "white-listed" library modules, and has limited access to attributes and methods of objects in the object database.
thanks so much in advance -- chris
There *are* add-on products which can potentially increase the vulnerability of a Zope application, by expanding access to the kinds of modules which allow an attacker to "springboard" from Zope (Python's urllib, os, etc.). Zope has issued a number of "security advisories", accompanied by installable "hot-fix" products: http://www.zope.org/Products/Zope/hotfixes Note that almost all of these advisories relate to issues with "through- the-web" scripting / templating. Of the remaining set, one hotfix patched an underlying Python vulnerability (in cgi.py). Sites which do not permit untrusted users to authenticate have, by and large, not been exposed to these issues. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com