[ZCM] [ZC] 604/ 7 Resolve "dtml-tree == DoS -or- oh man, you trust eval?"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #604 Update (Resolve) "dtml-tree == DoS -or- oh man, you trust eval?"
 ** Security Related ** (Public)
 Status Resolved, Zope/bug medium
To followup, visit:
  http://zope.org/Collectors/Zope/604

==============================================================
= Resolve - Entry #7 by Brian on Jan 21, 2004 2:36 pm

 Status: Pending => Resolved

fixed for 2.6.3+ and 2.7.0b4+

-BL
________________________________________
= Comment - Entry #6 by ShaneH on May 2, 2003 10:30 am

Has the patch been applied to Zope yet?

________________________________________
= Comment - Entry #5 by htrd on Feb 10, 2003 1:36 pm

A similar question came up on zodb-dev regarding ZEO's use of pickles in its wire protocol. For that Guido recomends against using a subclass of the python unpickler (the approach used in this patch), and prefers to use marshal instead.

These two problems (zeo/dtml-tree) are different, but close enough that it would be nice to solve tham in the same way if possible.

This definitely needs more attention before the release of 2.7.


________________________________________
= Comment - Entry #4 by ajung on Feb 2, 2003 7:30 am

Can you apply the patch if the problem is still persistent?
________________________________________
= Comment - Entry #3 by htrd on Dec 16, 2002 3:51 pm

Waaah - collector wont let me add a patch
see:
http://www.zope.org/Members/htrd/tree.diff
________________________________________
= Comment - Entry #2 by htrd on Dec 16, 2002 3:47 pm

This patch pulls in some old code from another project to patch the obvious holes - the one mentioned below plus the zlib bomb.

Only lightly tested with the ZMI

Tree tag URLs are not compatible
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 6:06 pm

Whilst writing ExpansionTree I stumbled across several potential DoS attacks against Zope.  This is the first.

The dtml-tree tag uses eval on data supplied by the web client.  The attempts to untaint this data beforehand
are not sufficient.  Using eval on untrusted code is dangerous, that's obvious, thinking you can defang eval enough to outsmart an attacker is even more dangerous.
The code filters out obvious uses of the * operator. It doesn't filter out list comprehensions.  Consider:

http://example.com/page/with/dtml-tree/?tree-s=eJyLztTOVEjLL1LIVMjMU4ge5Q1CnlJmplIsXgAAMQ6PHw

Which equates to:

eval(
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  [i+i for i in [i+i for i in [i+i for i in [i+i for i in [i+i for i in \
  "ii"]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
)

Can ya feel the love?  Memory exhaustion has never been
so easy.  Or has it?  As clever as the above is, the sad truth is that you don't even have to try so hard, using the results of:

>>> s="a,"*50000
>>> s=s[:-1]
>>> encode_seq(s)

Will eat memory like its going out of style as well.

Now, obviously the most fundamental approaches to sane system administration will protect against these attacks.  Zope, like any daemon, should be run with resource limits in place.  (I can only assume NT and friends provide resource limits? I'd be somewhat surprised if they didn't.)  When run with resource limits in place the try/except wrapped around the eval will nicely catch the MemoryError and Zope will happily continue running like nothing happened.  The problem is that I'm betting almost nobody actually uses resource limits with Zope because it has such an annoying memory footprint to get a handle on.  Ofcourse, so far these
"explosive" data structures just eat memory, they might
be able to eat CPU in the future, I dunno; point is, eval is dangerous.

I'm not sure what the best way to fix this in a backwards compatible manner is.  ZTUtils' code doesn't suffer from this malady (it's got different problems, that bug is next), so in the long term I'd simply phase the dtml-tree tag out in favor of more extensible systems like ZTUtils and <plug>ExpansionTree</plug>.
In the short term though, I dunno, parsing the list data structure by hand doesn't sound fun, but I don't
know any other way.
==============================================================