[Zope-dev] Re: [Zope3-dev] How (in)secure is Zope?

[Tres Seaver]

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