Untrusted code execution

Ian Kelly ian.g.kelly at gmail.com
Thu Apr 7 13:48:36 EDT 2016


On Thu, Apr 7, 2016 at 11:35 AM, Jon Ribbens
<jon+usenet at unequivocal.co.uk> wrote:
> Well, it entirely depends on how much you're trying to allow the
> sandboxed code to do. Most of the stuff in that script (e.g.
> _copy_module and safe versions of get/set/delattr, exec, and eval)
> I don't think is really necessary for most sensible applications
> of such an idea, I've just added it for completeness and to see
> if it introduces any security holes that weren't there originally.
>
> I could slim down the code again by simply removing all that extra
> cruft and the principle would still be the same - it's only the
> safe_compile() function that's adding anything interesting that
> I haven't seen done before (and half of the lines in that function
> are docstring or stuff to make nicer error messages).

Since you're now allowing exec I suppose you might as well allow type
also, since you could just use a class statement instead. safe_compile
prevents accessing magic methods, but it doesn't prevent defining
them. Not sure if there could be an exploit there or not.



More information about the Python-list mailing list