[Zope-dev] Re: Zope security alert and hotfix product...

[Brian Lloyd]

> >  The issue involves the fact that the getRoles method of 
> user objects 
> >  contained in the default UserFolder implementation returns 
> a mutable 
> >  Python type. Because the mutable object is still 
> associated with the 
> >  persistent User object, users with the ability to edit DTML could 
> >  arrange to give themselves extra roles for the duration of 
> a single 
> >  request by mutating the roles list as a part of the request
> >processing. 
> 
> OK, so I can exploit this with something similar to
> user.getRoles().append('A Role That I Dont Have')
> 
> But, why isnt the append method covered by the new
> inaccessible-by-default 2.2 security rules?

Back when we were considering how much tightening would 
be considered acceptable in one dose, we ended up not 
preventing access to methods of mutable python types 
([], {}). The main reason that we were aware of a fair 
number of people using this (including one or two internal 
things) for legitimate things:

  <dtml-var "REQUEST.set('some_stuff', [])">
  <dtml-in other_stuff>
    <dtml-call "some_stuff.append(_['sequence-item'])">
  </dtml-in>

etc. So we made the decision not to break those things. 
The real problem, of course, is that the Zope APIs (and 
the APIs of add on products) should not return references 
to mutable subobjects. If an API method must return a 
mutable Python type, it should return a copy rather than 
a direct reference:

  def myMethod(self):

    # self.stuff is a dict

    # dont do this!
    return self.stuff

    # do this instead
    return self.stuff.copy()

    # or if stuff is a list either do:
    return self.stuff[:]

    # or 

    return tuple(self.stuff)


Now - should methods of mutable types be off-limits in the 
future? I'm not sure that the jury is in yet on that. Consider 
that PythonMethods (that soon will be part of the core) play 
by basically the same rules as dtml. While it might be pretty 
easy to argue that the list-juggling in my DTML example above 
is bad practice, I think most people would expect to be able 
to do:

  mylist=[]
  mylist.append('one')
  return mylist

...in a PythonMethod and have it work. I don't think it would 
be acceptable for 'append' to be off-limits in this case, so 
the alternative is that the security machinery would somehow 
have to be able to distinguish mutables created by the user 
from those obtained from the secure environment. That would 
probably mean that API code would have to make some sort of 
security assertions about mutables they returned. Exactly 
how that would work I don't know...


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com