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

Joachim Werner joe@iuveno.de
Thu, 13 Mar 2003 14:27:36 +0100


Christian Tismer schrieb:
> 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.
> 
> thanks so much in advance -- chris

I think to be fair here we should compare Zope's security to the 
security of other similar tools, not only point out that there still are 
issues in Zope.

It is extremely difficult to write secure web software that is at the 
same time highly interactive. If you want people to be able to do a lot 
with your system you will also have to open it up to some degree.

My basic oppinion is that Zope is one of the most secure solutions for 
dynamic web applications.

Some of the issues that have not been talked about in the previous postings:

- Products that let you access the file system:

There is a number of products (like LocalFS) that let you access the 
file system directly. While this is not always a problem one has to be 
extremely careful with those because they circumvent Zope's access 
limitations to the file system. Of course you are still restricted to 
the user Zope is running at ...

- Products or methods that can use up a lot of resources:

I can think of a couple of ways of using up most of the resources on a 
Zope system:

   - Using PIL (Python Imaging Library) without care: Let's say you offer
     an automatic image scaling tool to your users that can be called via
     a URL. Then it is relatively easy for an attacker to let PIL create
     huge images that might take several seconds to render and use up
     tens of megabytes of RAM. Doing this in a massive way will bring the
     server to a halt. There are similar exploits using other resource-
     intensive software, so this is just an example.

     Note that this is not a Zope design flaw, but a potential danger
     when being too careless in extending Zope.

   - Uploading huge files: This can effectively be handled by a proxy
     server (Apache can also limit most other DOS-related parameters
     quite efficiently)

   - Doing things that are perfectly allowed too frequently, like
     hammering the over-the-web registration tool with a robot: This
     has to be taken care of by the programmer. I'd guess that most of
     the servers out there (Zope or non-Zope) are not perfect in that
     respect. Again, Apache might help here.

   - Writing malicious code that "loops forever" etc. This is a part
     where Zope's security works quite well, but it is not perfect.
     There are no "infinite" loops or recursions because you'll
     eventually get stopped by Zope or Python. But I remember that I
     was able to write a three-liner in a (Script) Python that had a
     flaw and caused an enormous system load before it was terminated.
     The only way to stop this is careful coding. In a very public
     environment I'd limit the scripting available to site visitors to
     very simple tools like structured text. As soons as somebody
     untrusted can write code there is no way of preventing DOS-type
     attacks. Powerful tools are powerful. It's like guns: They can not
     be built to only kill the bad guys ...

- Cross-scripting issues:

I guess that some of those are still in the Zope Management Interface 
(which is not meant to be used by untrusted users in most cases), but 
Zope offers a lot of tools to make sure that it is hard to post 
malicious code in forums, attack Zope via URLs etc.

For example there are quoting mechanisms in place, either automatic or 
easily applicable, that can be used to protect SQL strings, URLs, and 
text that is displayed on the site. The majority of exploits in PHP- or 
Perl-based solutions is in this domain.

It is safe to say Zope is more secure than most other web application 
servers (protection against buffer overflows, limited access to the 
system's resources, very limited file system access, quoting mechanisms, 
secure SQL database access, very sophisticated internal security model), 
but Zope is not a firewall. If you don't take care there is some chance 
of DOS attacks. On the other hand I am quite positive that Zope is very 
secure in terms of preventing unauthorized access to the system (root 
exploits etc.).

Joachim


-- 

iuveno AG

Joachim Werner

_________________

Wittelsbacherstr. 23b
90475 Nürnberg

joachim.werner@iuveno.de
www.iuveno.de

Tel.: +49 (0) 911/ 9 88 39 84