use of exec in products considered harmful?
I'm considering doing something in the LocalFS product that seems like a potentially huge security risk, which is calling exec on a string submitted through a form. The reason is that I want to allow users to customize the object class associated with different content-types when the product constructs a Zope object from a local file. I need a way for them to specify the arguments to the object constructor from the management interface. The solution I came up with is rather awkward but I can't think of a better one. Suppose 'c' is a string containing, for example, "OFS.DTMLMethod.DTMLMethod(data, __name__=id)". This is the code to construct the object: try: # this should hopefully avoid executing # malicious python code if ';' in c: raise ValueError m = c[:string.rindex(c, '.')] exec('import ' + m) exec('ob = ' + c) except: pass I'm hoping that by disallowing ';' in the string I can avoid malicious code like: OFS.DTMLMethod.DTMLMethod(data, __name__=id); print "Hi. I've got control of your server now. Have a nice day." Can anyone else think of how this code can still be exploited? Can anyone think of a better, safer way to do this altogether? Is any of this making sense? Thanks, -jfarr
On Fri, 10 Mar 2000 15:54:36 -0800, "Jonothan Farr" <jfarr@real.com> wrote:
I'm considering doing something in the LocalFS product that seems like a potentially huge security risk, which is calling exec on a string submitted through a form.
Yeah, thats a big hole.
The reason is that I want to allow users to customize the object class associated with different content-types when the product constructs a Zope object from a local file.
Would something like the Brains class that can be set for SQL methods do the job? Toby Dickenson tdickenson@geminidataloggers.com
Would something like the Brains class that can be set for SQL methods do the job?
Brains classes always have the same constructor arguments (namely: (self)). What makes this problem difficult is that the constructors of Zope objects which map to local files can have virtually any signature. Image(id, id, data) DTMLMethod(data, __name__=id) ???(???) I really need help with this. I don't want to create a huge security risk but I really want to add this feature. -jfarr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi! I'm a signature virus. Copy me into your .sig to join the fun! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Mon, 13 Mar 2000 12:32:05 -0800, "Jonothan Farr" <jfarr@real.com> wrote:
Would something like the Brains class that can be set for SQL methods do the job?
Brains classes always have the same constructor arguments (namely: (self)).
That doesn't need to be true for _your_ brains classes.
What makes this problem difficult is that the constructors of Zope objects which map to local files can have virtually any signature.
Let your brains classes __init__ take a REQUEST parameter. They can extract the properties it needs, before calling the base class __init__. You need one brains class for each class that you want to wrapper. Is this a problem? Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
On Mon, 13 Mar 2000 12:32:05 -0800, "Jonothan Farr" <jfarr@real.com> wrote:
Would something like the Brains class that can be set for SQL methods do the job?
Brains classes always have the same constructor arguments (namely: (self)).
That doesn't need to be true for _your_ brains classes.
What makes this problem difficult is that the constructors of Zope objects which map to local files can have virtually any signature.
Let your brains classes __init__ take a REQUEST parameter. They can extract the properties it needs, before calling the base class __init__.
Note also that your brains class can acquire REQUEST using self.REQUEST. -Michel
On Tue, 14 Mar 2000 09:18:30 -0800, Michel Pelletier <michel@digicool.com> wrote:
Toby Dickenson wrote:
On Mon, 13 Mar 2000 12:32:05 -0800, "Jonothan Farr" <jfarr@real.com> wrote:
Would something like the Brains class that can be set for SQL methods do the job?
Brains classes always have the same constructor arguments (namely: (self)).
That doesn't need to be true for _your_ brains classes.
What makes this problem difficult is that the constructors of Zope objects which map to local files can have virtually any signature.
Let your brains classes __init__ take a REQUEST parameter. They can extract the properties it needs, before calling the base class __init__.
Note also that your brains class can acquire REQUEST using self.REQUEST.
Normally thats true, however we need these parameters in a __init__, and constructors run with an empty acquisition context. (Unlike many acquisition problems, I think this one makes sense - things don't have a context until they have been created.) Toby Dickenson tdickenson@geminidataloggers.com
Let your brains classes __init__ take a REQUEST parameter. They can extract the properties it needs, before calling the base class __init__.
Note also that your brains class can acquire REQUEST using self.REQUEST.
Normally thats true, however we need these parameters in a __init__, and constructors run with an empty acquisition context.
Actually, this will work because the LocalFS object is calling the constructor so I can acquire REQUEST from the LocalFS object's context. This sounds like a great idea. I'm going to give it a try. Thanks! Actually, I don't need REQUEST at all, though because I can define a 'brain' class to have a standard constructor then return the actual object through, say, the __call__ method. --jfarr
participants (3)
-
Jonothan Farr -
Michel Pelletier -
Toby Dickenson