[Zope-dev] Re: [Zope3-dev] How (in)secure is Zope?
Tres Seaver
tseaver@zope.com
12 Mar 2003 21:39:02 -0500
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